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, and SHIP encrypts them at rest. SHIP shares nothing between organizations, so the spend, the rate limits and the terms for your data are all yours.
On the Connect your AI providers step of onboarding, add one or more providers:
| 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 |
When you save a key, SHIP verifies it with a live call to the provider. A typo or a key from the wrong account fails at that point, not on your first mission. Anthropic also accepts a subscription credential in addition to an API key.
One credential is enough
By default, every role uses the claude-code harness on Opus: the Planner, the Builder, the Reviewer and QA. Opus here means the opus alias, which is now Opus 5.5. So a single Anthropic credential runs a complete mission, from the plan to the merged pull request.
This default is deliberate. The Reviewer once used a second provider by default. An organization could then have a valid key for one provider and no valid key for the other. That organization onboarded, planned and built without a problem, and then the mission failed at review with a credential error. A mixed agent team is a good idea for many teams, but you should choose it, not discover it at the last gate.
Mixing providers
When you connect more than one provider, you configure which agent runs each role:
# ship.yml
agents:
builder:
harness: claude-code
model: claude-opus-5
reviewer:
harness: codexThat setting applies to every mission of the project. For one mission, the CLI overrides the setting and does not change the file:
ship delegate pr SHIP-412 --harness codex
ship delegate plan SHIP-412 --file docs/plan.md --model opusUse that flag to compare two harnesses or two models on the same work. SHIP records cost, duration and outcome per stage, so you can read the comparison afterwards and do not have to rely on an impression.
Cost
SHIP measures spend from the list prices of the model that served each call, not from what a harness reports about itself. SHIP assigns the spend to each mission and each stage.
Two limits control the spend:
- Per mission. A single mission stops at $5 by default.
- Credits per mission. A mission pauses at 2 credits, or 6 agent-hours. It continues when a member of your organization approves more, and each approval adds 1 credit.
If you move a role to a larger model, that role can cost about 5 times as much. The mission breakdown on each mission is the fastest way to see whether the change paid for itself.
How the keys are handled
Your credentials never reach the sandbox an agent runs in.
SHIP starts the agent's container with a placeholder instead of the real key. When the agent calls the provider, SHIP puts the real credential on the outbound request, outside the container. The key is never in the container's environment or on its filesystem. So the agent cannot read the key, even if someone tricks it.
This design fails closed. If SHIP does not replace the placeholder, the provider gets the placeholder and rejects the call. A call with no real credential never succeeds silently.
How is this page?