How model access works

The model router

cmdop agents reach models through one place: the cmdop model router, a standalone gateway served at router.cmdop.com. It presents an OpenAI-compatible API, so any tool that speaks that shape can talk to it:

• Chat completions — plain, streaming, and structured (response_format) output.
• Web search — backed by Serper, returning structured results.
• Image generation — text-to-image.
• Model listing — the resolvable models and tier aliases.

Putting a router in front of providers means one place to pick a default, resolve an alias to a concrete model, and route a turn to the right backend — without every agent hard-coding a provider endpoint.

The default path — cmdop supplies the keys

The default path is the one you get out of the box, with nothing to configure:

1. Your agent presents your platform API key to the router as an X-API-Key header.
2. The router validates that key against the cmdop account store (the control plane). An invalid, inactive, or revoked key is rejected.
3. The router brokers your request to the provider using platform-supplied provider keys — you never hold or configure them.

On this path the router routes to a fixed set of upstreams:

So on the default path, cmdop holds the provider credentials and brokers the call. That is what your platform API key buys: model access without managing provider keys yourself.

The escape hatch — bring your own key

If you would rather use your own provider account — or a model the router doesn’t broker, or a local LLM — add a custom provider. A custom provider is any OpenAI-compatible endpoint, configured with your own key:

cmdop provider add          # add a custom provider (preset or custom URL)
cmdop provider set <id>     # make it the active chat provider
cmdop provider default      # switch back to the cmdop default

When a custom provider is active, chat is routed to your endpoint with your key — it bypasses the router for chat completions. Search, vision, and CDN still go through the cmdop model router on the default path. This is the bring-your-own-key escape hatch: you opt out of the brokered chat path without losing the rest. Custom-provider keys are stored locally (mode 0600), never sent to the control plane. See Custom LLM providers for the full setup, and cmdop models for how aliases resolve under each path.

Two credentials, two jobs

A cmdop agent holds two independent credentials, on purpose — they are not one identity to reconcile:

The model router validates its key against the same account store the control plane owns, so your accounts are unified even though the two services are separate. The router has read-only access to that store — it can check your key, but it is not a write path into your account. This is a clean security boundary: the gateway that brokers model access cannot mutate your account, and a model call never transits the live execution path.

Who pays, and what’s metered today

Be clear-eyed about maturity here, because it matters:

• On the default path, cmdop supplies the provider keys, so cmdop currently foots the upstream provider bill.
• There is no per-user metering or billing today. The router does not meter usage against your key and does not bill — that machinery is planned, not live. Do not read the default path as a metered, paid plan you can buy right now.
• On the custom-provider / local-LLM path, you supply the key (or run the model yourself), so you pay your provider directly and there is no router dependency for chat.

This matches the honest framing in Pricing: the managed, metered offering is on the roadmap, not shipping. When metering lands, the router is the surface it will land on — until then, treat model access as access, not as a billed product.

Related

• Backend architecture: the three planes — where the model router sits.
• Custom LLM providers — the bring-your-own-key escape hatch.
• cmdop models — aliases, concrete ids, and switching.
• AI chat — the user-facing chat surface.
• Pricing & editions — the honest billing picture.

TAGS: model-access, model-router, custom-provider, llm-gateway DEPENDS_ON: [architecture/backend-services, cli/custom-providers, cli/models]