[cli] Move openapi urls to /openapi

[redwyre]

as discussed in #774

My proposed change is something like this:

api	previous	new	proposed
foundry	/openai/status	/status	foundry/v1/status
foundry		/shutdown	foundry/v1/shutdown
foundry	/openai/loadedmodels	/models/loaded	foundry/v1/models/loaded
foundry	/openai/load/{name}	/models/load/{name}	foundry/v1/models/load/{name}
foundry	/openai/unload/{name}	/models/unload/{name}	foundry/v1/models/unload/{name}
openai		/v1/models	openai/v1/models
openai		/v1/models/{name}	openai/v1/models/{name}
openai	/v1/chat/completions	/v1/chat/completions	openai/v1/chat/completions
openai	/v1/audio/transcriptions	/v1/audio/transcriptions	openai/v1/audio/transcriptions
openai		/v1/embeddings	openai/v1/embeddings
openai		/v1/responses	openai/v1/responses
openai		/v1/responses/{id}	openai/v1/responses/{id}
openai		/v1/responses/{id}/input_items	openai/v1/responses/{id}/input_items

When using an openai compatible client you would then use http://localhost:xxxx/openapi/v1 as the base url
This also leaves a path for non-breaking upgrades to foundry api, and adding other rest apis like ollama or anthropic.

[samuel100]

Thanks for the detailed proposal @redwyre — really appreciate you laying it out as a table, makes the trade-offs much easier to think about.

Quick context on why the routes changed in the SDK

When we re-designed Foundry Local to be SDK-first — embeddable in applications rather than "just a CLI" for experimentation — we took the chance to tidy up the REST surface:

The old /openai/download/ etc. routes had nothing to do with OpenAI, and some operations (like download) have native SDK methods that don't really need a REST equivalent. As called out in Is Foundry Local a web server and CLI tool?, the REST server is there to enable experimentation — the core product is the local AI runtime + SDK that you integrate directly into your application.

What I think your proposal gets right

• Versioning headroom. /status, /models/loaded, /models/load/{name} have no version prefix today, so we can't evolve them non-breakingly. That's worth fixing.
• Room for other compat surfaces. If we ever add Ollama- or Anthropic-shaped APIs, /v1/* is implicitly OpenAI's namespace today and would collide. A /{vendor}/v1/* pattern leaves a clean path.

Where I'd lean a bit differently

• I'd keep OpenAI-compatible routes at /v1/* rather than /openai/v1/*. The OpenAI compat surface exists specifically to help 3rd party apps integrate with Foundry Local, and most of those apps already assume the /v1/* convention.
• I'd skip the /foundry/... prefix on the native routes — the server is Foundry, so it feels redundant. /status, /models/loaded, /models/load/{name} etc. at root read fine, and they're a small surface.

So the shape I'd suggest

• /status, /shutdown, /models/loaded, /models/load/{name}, /models/unload/{name} — Foundry's own routes, at root.
• /v1/* — OpenAI compat (implicit, drop-in for 3rd party apps).
• /{vendor}/v1/* — reserved pattern for any future non-OpenAI compat APIs (e.g. /ollama/v1/*, /anthropic/v1/*).
• Update documentation to reflect changes as per [cli] Rest API server in local foundry cli-preview-0.10.0 #774

That picks up the extensibility win you're after without another disruptive rename in the SDK layers and without losing the OpenAI drop-in ergonomics.

Does that land roughly where you were aiming, or is the explicit-namespace consistency the thing you care most about?