A job id that never goes stale. Fallback across providers.

A lane is a model id that names a job, such as bb/extraction, rather than one model. You can still call any measured model by its own id. When you call a lane, Cruise picks for each request among the lane’s models that can serve that request, using the lane’s selection policy — the cheapest by default, and a single request can override it. Change the lane’s models and every caller follows with no code change. Every response names the model that actually served it.

Every provider that may receive your requests is listed on our Sub-processors page. A model is routable only after Cruise has measured it within the last 30 days, and a model without a known price is refused rather than guessed at. With your key, GET /v1/models lists the models and lanes that key may call.

Yes: each request is forwarded to the provider that serves it and handled under that provider’s terms. What a provider does with prompts is disclosed per model — not retained, retained, may train on it, or unrecorded. Models that may train, and unrecorded ones, are available by default; a lane that requires no-training-on-data excludes both. Cruise’s own ledger keeps tokens, cost, the model, the key prefix and a digest of the request body — not the prompt or the completion. If you turn caching on, answers are stored for the cache window, at most 30 days.

It is off by default. An owner or admin switches it on for a project, or for one of your own lanes, which then compresses for every project that calls it. Where it is on, Cruise shrinks the tool outputs in each request before the provider sees them: compact JSON, tables for uniform arrays, and long arrays and repeated log lines shortened behind [cruise: …] markers that say what was removed. The provider bills the smaller request. It is lossy — the model does not see what was elided — and the system prompt and the user and assistant messages are never changed. The same tool output compresses to the same bytes every time, so prompt caching keeps working. A request can opt out with the header x-cruise-compress: off, and every response reports the bytes before and after.

When a provider refuses a request — a rate limit, a timeout or a server error — Cruise tries the next candidate, up to the lane’s fallback limit. Fallbacks help most when the candidates sit with different providers, because models on one provider account are usually rate-limited together. Each fallback starts only after the failed attempt, so a longer chain means a longer worst-case wait, not more reliability.

Each project can have a daily or monthly budget: a soft threshold warns, and a hard cap refuses requests until the period ends. Spend is reserved before a request is sent, so a looping agent stops at the cap rather than at the invoice. Separately, the workspace balance stops at $0, and requests are refused until you top up. The two refusals carry different codes, budget_exhausted and wallet_exhausted, so an agent can tell them apart.

From prepaid credit, which never expires. The credit you buy is added to your balance in full, and each request is deducted from it as you use it: the provider’s list rate plus our 3% markup by default, or a different rate agreed with us in writing for your workspace. An answer served from the cache costs 20% of list. Any fee for the way you pay depends on the method you choose and is shown before you pay. Unused credit from a top-up in the last 30 days is refundable on request, minus that fee; spent credit is not. The Terms of Service are the binding version.

Not on Cruise Cloud, which routes requests to third-party providers on our accounts. Cruise Enterprise is a separate deployment on your own infrastructure, with your own provider keys and models, such as AWS Bedrock or self-hosted endpoints. It is arranged with us directly rather than bought on this page.