Bring Your Own Model Without Losing the Boundary

Codewhale’s provider choice is a routing decision, not a second permission system. The practical question is not simply which model name sounds strongest. It is which exact provider and endpoint should receive this task, which wire protocol and credential source that route requires, what capabilities are actually evidenced, and whether the choice fits the task’s locality, compatibility, context, and cost constraints. Keeping those facts separate lets a developer bring a hosted, gateway, native, or local model into the same Runtime without silently changing what the Runtime is allowed to do.

A route is more than a model name

A Codewhale request has several identities. The provider identifies the route family. The model identifies the requested model within that route. The base URL identifies the service endpoint. The wire protocol determines how requests and tool calls are encoded. The credential source determines which authority is used to authenticate. Capability metadata describes what the exact route is known to support.

These facts often look like one choice in a simple model picker, but they can diverge. A provider may speak OpenAI-compatible Chat Completions for one route and Anthropic Messages or Responses for another. A generic gateway may accept a familiar model ID while applying its own routing semantics. A local runtime may use an OpenAI-compatible interface without being the same service as the hosted provider whose model name it resembles. A model string with a vendor prefix does not switch the active provider by itself.

This separation protects the Runtime boundary. Selecting a local model can change where inference happens, but it does not grant shell access. Selecting a hosted model can expose a feature that a local model lacks, but it does not widen the workspace path policy. Selecting a gateway can change billing or upstream routing, but it does not transfer Codewhale’s approval decisions to the gateway.

It also makes failures more intelligible. A request can fail because the provider route is unresolved, because the model ID is not accepted by that endpoint, because the wire adapter cannot represent a capability, because credentials are missing, or because the account is not entitled to the catalogued model. These are not one generic “model error,” and choosing the right remedy depends on preserving the distinction.

Choosing by constraint, not by a universal winner

There is no single route that dominates for every Codewhale task. The decision depends on what the task requires and what the operator is willing to manage.

A hosted provider may be the practical choice when the developer needs a particular model capability without maintaining local inference hardware. The relevant checks are still exact: which provider entry is active, which endpoint will receive the request, which model ID it accepts, and which features the route metadata supports. A provider’s catalog or marketing description does not automatically prove that the current account can use every listed model.

A generic compatible gateway can be useful when an organization already has an inference service or wants one endpoint to front several models. Its benefit is integration reuse, not automatic equivalence.