Choosing Where the Work Runs
Choosing a route in OpenClaude is a decision about the work a model must sustain, not a beauty contest among model names. This chapter compares direct vendors, aggregating gateways, and local runtimes by control, credentials, capability, discovery, and operational dependence. It then shows how saved profiles, delegated agents, and smart routing turn that choice into a layered control surface.
Three route decisions, not one ranking
Start with the task rather than the provider list. Suppose a developer wants OpenClaude to inspect a private repository, change a small section, run tests, and explain the result. The important questions are not only “Which model is strongest?” They are also:
- Must inference stay on the machine, or is a hosted route acceptable?
- Does the task need vision, reasoning controls, dependable function calling, or a large context window?
- Is the user choosing a model from one vendor, or from a gateway that exposes several upstream models?
- Which credentials, endpoint, and request contract will the route require?
- How much operational responsibility can the user accept when the task fails?
These questions produce three broad choices inside OpenClaude. They are not mutually exclusive product tiers; they are different ownership arrangements for the same coding-agent workflow.
A direct vendor route connects OpenClaude to the service that owns or directly serves the selected model. The route's catalog and transport rules can be curated around that vendor's API. This can make capability and authentication easier to reason about because fewer systems sit between the client and the model. It does not make the route simple by definition: native APIs may have their own message formats, reasoning behavior, context limits, or authentication flows, and a direct vendor can still require dedicated handling.
An aggregating gateway places another service between OpenClaude and one or more upstream models. The gateway can offer model variety behind one endpoint and may maintain a live catalog. That is useful when a user wants to experiment with models without adopting a separate client for each one. It also creates another boundary to understand. The gateway owns its endpoint contract, credential policy, model aliases, availability, and sometimes pricing or retry behavior. A model listed by the gateway is not automatically the same route as the direct vendor model with a similar name.
A local runtime serves a model on the user's machine or on a local network endpoint. OpenClaude documents local paths such as Ollama, LM Studio, and Atomic Chat. A local route can reduce dependence on hosted inference and avoid a cloud API key for some configurations. It also shifts responsibility to the user: the service must be running, a model must be loaded, the hardware must sustain the request, and the model must be capable of participating in a multi-step tool loop. Local does not mean frictionless, and it does not mean every tool or external service is local.