LLM credentials
Connect your own provider accounts. One credential is enough to run a whole mission.
Overview
SHIP runs agents on your provider accounts. You connect the credentials, they are encrypted at rest, and nothing is pooled across organizations, so the spend, the rate limits and the data handling are all yours.
On the Connect your AI providers step of onboarding, add one or several:
| Provider | Used by |
|---|---|
| Anthropic | The claude-code harness, which is the default for every role |
| OpenAI | The codex harness |
| OpenRouter | The open-model harnesses pi, kilo-code and open-code |
| Z.ai | Open models served directly |
Each key is verified with a live call to the provider when you save it, so a typo or a key from the wrong account is caught there rather than on your first mission. Anthropic additionally accepts a subscription credential alongside an API key.
One credential is enough
Every role, from planner through builder and reviewer to QA, defaults to the claude-code harness on Sonnet 5. So a single Anthropic credential runs a complete mission from plan to merged pull request.
That is deliberate. The reviewer used to default to a second provider, which meant an organization with a working key for one and a missing key for the other onboarded fine, planned fine, built fine, and then died at review with a credential error. A mixed fleet is a good idea for plenty of teams, but it should be something you chose, not something you discover at the last gate.
Mixing providers
Once more than one is connected, which agent runs each role is configuration:
# ship.yml
agents:
builder:
harness: claude-code
model: claude-opus-5
reviewer:
harness: codexThat is the project's standing setting. For one mission, the CLI overrides it without changing the file:
ship delegate pr SHIP-412 --harness codex
ship delegate plan SHIP-412 --file docs/plan.md --model claude-opus-5Comparing two harnesses or two models on the same work is the point of that flag. Cost, duration and outcome are recorded per stage, so the comparison is readable afterwards rather than a matter of impression.
Cost
Spend is measured from list prices for the model that actually served each call, not from what a harness reports about itself, and is attributed per mission and per stage.
Two limits bound it:
- Per task. A single mission stops at $5 by default.
- Per organization, per day. A daily cap, $50 unless you change it, set from Settings or the API. Work already running finishes; new dispatches are refused with a message naming the cap and when it resets, rather than failing obscurely.
Bumping a role to a larger model is roughly a 5x decision on that role's burn. The per-stage breakdown on each mission is the fastest way to see whether it paid for itself.
How the keys are handled
Your credentials never reach the sandbox an agent runs in.
The agent's container is started with a placeholder in place of the real key. When it calls the provider, the platform rewrites the credential on the way out, from the outside. The key is never in the container's environment and never on its filesystem, so nothing the agent does, and nothing it is talked into doing, can read it back.
This fails closed by construction: if the rewrite does not happen, the placeholder goes to the provider and the call is rejected. There is no path where a missing credential quietly becomes a working one.
How is this page?