Skip to main content

​
crewship provider

Reads the LLM provider registry compiled into the binary, and — with check — dials a provider once to prove the wiring end to end.
Every subcommand is local. There is no server route behind them: the registry, the model catalog and the sidecar’s routing table are all compiled in, so they work with no config file, no token, no workspace and no reachable server. check reaches the provider directly from the machine you run it on, which means it can test a local backend the server itself cannot see. Background on what these tables are: Multi-provider LLM configuration.

​
Subcommands

​
list

Flags: Example:
Rows are in registry declaration order, which is also the order the admin console’s provider picker renders. Columns: --all appends the catalog-only providers (amazon-bedrock, deepseek, google, mistral, openrouter, xai), sorted, with a dash in every column but PROVIDER, NAME and MODELS. That dash is the point: deepseek is listed because the catalog prices it, not because an evaluator slot can select it. --format json adds registered, key_required, key_set and catalog_id per row, which is the shape to script against:

​
route

list answers the other half of the provider question. provider list says which providers this binary can construct and whether their key is in your environment; route list says how an agent’s CLI reaches a provider through its sidecar — the path it dials on 127.0.0.1:9119, where the sidecar forwards it, and which header or query parameter the credential is written into on the way out. The two tables are deliberately different sets. A provider here does not have to be one crewshipd can call, and vice versa. Example:
show prints one route in full, including every auth branch:
A provider with more than one token shape lists each branch — provider route show anthropic prints an Auth (token sk-ant-oat…) line above its Auth (default) one, which is how an OAuth token ends up in Authorization and an API key in x-api-key without either being a special case in the router. Like list and unlike check, both are local and read-only: the descriptor table is compiled in, nothing reads the credential vault, and no server is contacted. An unknown provider exits 3:
Bedrock is not in that list and is not supported: it authenticates with SigV4 request signing, which the sidecar does not do. To create a credential for one of these providers, see crewship credential create — and for a from credential upstream, an OpenAI-compatible endpoint.

​
check

Builds the provider for real, sends one completion, and prints the endpoint it dialled, the latency, the token counts the backend reported and what paymaster will bill for them. Flags: Example — a local backend, no key:
pricing key is the line to read twice. It is Provider.Name(), not the preset key you passed — ollama-openai bills as ollama and vllm bills as local, which is how a self-hosted backend lands on a free rate row.
Zero tokens on a backend that clearly did work is the finding. It means the response carried no usage block, and every call through that backend will be priced at $0. On a streamed OpenAI-compatible endpoint the usual cause is a config without IncludeUsage — see Multi-provider LLM configuration.
Exit codes follow the usual CLI contract. The two you will meet:
The vocabulary in the first message is generated from the registry and the preset table, so it cannot drift from what the command accepts. The second is the upstream’s own refusal, preserved verbatim rather than flattened into “provider error”.