Models

Sable exposes a curated catalog under stable identifiers so model upgrades don't break your agents. List them at runtime with GET /v1/models. A model id outside the catalog is refused with 400: the gateway never forwards an unknown id to an upstream.

Each entry carries pricing (prompt_usd_per_mtok and completion_usd_per_mtok, in USD per 1M tokens, the deployment's billing margin is applied on top at metering time, as with everything else; see Cost & metering) and an open_weight flag.

The catalog is organized in three lanes plus the confidential tier. Where a model runs (and what its host can see) differs by lane; the privacy ladder is the full picture.

The flagship lane: sable, sable-fast, sable-max

Three ids, each kept pointed at a strong frontier engine.

sable is the id to use when you want "the best model Sable serves" without tracking model churn yourself; sable-fast is the cheaper, lower-latency variant, and sable-max is the deepest engine on the catalog. All three carry the same contract: a stable name, a disclosed engine, and the freedom for Sable to repoint the id to a better engine over time without breaking callers: that indirection is the point of having them. The engine is disclosed, not hidden: this page names what each id resolves to, and the signed receipt on every response records the engine that actually served that request.

How the flagship routes

Each flagship id carries an ordered engine chain, not a single engine. If the primary engine's upstream fails (a 5xx or a network error) the request retries on the next engine in the chain. A 4xx never fails over: no engine fixes a malformed request, so a client error comes straight back.

Routing is never a black box, because two things hold on every flagship response:

• The receipt names the engine. Flagship receipts always carry an engine field: the upstream engine that actually served the request. If a failover happened, the receipt says so by naming the engine that ran, not the one you'd have expected.
• Billing prices the engine that ran. A request served by a fallback engine is metered at that engine's rate, not the primary's.

The privacy dial. A flagship id called with sable_privacy_tier: "confidential" is not refused: it routes to the TEE-attested confidential models (currently sable-confidential-qwen3.6-35b) instead of the closed engine chain: one id, one privacy slider. The receipt keeps the requested id and carries the engine plus the full attestation block. On a deployment with no attested backend configured, the tier stays Phase-1 advisory and the request serves on the standard path.

Frontier slate: anonymized access

Closed vendor models, reached through Sable's own upstream account. The vendor sees Sable's identity, never yours: not your identity, not your API key, not your payment details. The vendor's infrastructure does see the prompt: this is anonymized access, not the confidential tier.

Anonymized is not confidential. Anonymized access hides who is asking from the vendor; confidential (TEE) hides what is asked from the host. On this lane the vendor cannot tie a request to you, but its servers still process the plaintext prompt. Only the sable-confidential-* models below carry the hardware guarantee that the host provably cannot read the request, and they are the only models allowed to carry the word "confidential". The privacy ladder spells out the difference rung by rung.

Open-weight workhorses

Public-weight models served on the standard path. The serving host sees the prompt (see the privacy contract), but because the weights are public, these are the models that can follow the confidential pair into an attested enclave over time.

Confidential: TEE-attested

The two models served inside an attested Intel TDX enclave, with the attestation stamped into the signed receipt (verification: "tee-attested", response_bound: true). These are the only models the confidential tier accepts: requesting any other model on that tier fails closed with 400, never a silent downgrade.

Private lane: double-blind routing

The private lane is rung 2 of the privacy ladder: these models are pinned to a second intermediary (Venice), so the request travels caller → Sable → Venice → vendor. The vendor is two hops from your identity; Venice sees only Sable's identity, never yours; Sable never persists content. No single party outside Sable holds who and what together, and Sable itself keeps only metadata.

Two properties are enforced, not promised:

• The route is the product, so it never falls back. A pinned model hard-fails when its route is down rather than silently serving through a path with a different privacy posture.
• No hidden vendor prompt. The intermediary's default system prompt is disabled at Sable's egress shim, so you are not billed for tokens you never sent and no unseen instructions shape the reply. (Pass your own venice_parameters object to override.)

Whether the lane is active on a deployment is visible in GET /v1/models: a model pinned to a route the deployment has not configured is omitted from the listing entirely: an advertised model that cannot serve would be a lie.

This lane hides who from every party past Sable and narrows what to parties two hops from your identity. It is not the confidential tier: the vendor's infrastructure still processes the plaintext to run the model.

Embeddings

Embeddings bill on input tokens only.

Open-weight vs. vendor-hosted

/v1/models marks every model open_weight: true or false. It matters for the privacy roadmap:

• open_weight: true means the weights are public (Llama, DeepSeek, Mistral, Qwen, Gemma, Nomic), so the model can run inside a Sable-verified enclave. Two do today: sable-confidential-qwen3.6-35b and sable-confidential-gemma4-26b. The rest are served on the standard path for now.
• open_weight: false means the model only runs on its vendor's servers (the flagship lane's current engines, the frontier slate, and the text-embedding-3 models). The vendor's infrastructure sees the input, and it will never be confidential beyond encrypt-in-transit plus anonymized access. We'd rather tell you that than ship a closed model under a privacy banner, so these stay standard tier only. (The flagship ids are names, not weights: the privacy dial above moves them to attested open-weight engines, it never puts a closed engine in an enclave.)

Provider pinning

A catalog model can be pinned to a single named upstream provider, and a pinned model never fails over to another provider: if its provider is down, the request fails rather than being served somewhere else. The private lane is pinned this way: a double-blind route (see the privacy ladder) only means something if the request provably cannot leak to a different upstream. A deployment that lacks a pinned model's provider omits that model from GET /v1/models rather than advertising a route it cannot serve.

Retired ids stay resolvable

A published Sable id is a contract, so we don't delete one when its upstream goes away. sable-confidential-24b originally mapped to a model the backend has since retired; it is now a compatibility alias for sable-confidential-qwen3.6-35b. Existing callers keep working, and it is deliberately omitted from GET /v1/models so nobody builds against it fresh. Name a model from the tables above in new integrations.