Models

Saxeo 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) and an open_weight flag. These are the prices you are charged: the deployment's margin is already included, so the figure you compute from them is the figure in your signed receipt. See Cost & metering.

The tables below are generated from the gateway's own catalog at the default 20% margin. A deployment can set a different margin, so GET /v1/models on the gateway you actually call is the authoritative sheet — it applies that deployment's margin to the same figures.

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: saxeo, sable-fast, sable-max

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

saxeo is the id to use when you want "the best model Saxeo 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 Saxeo 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 saxeo-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 Saxeo's own upstream account. The vendor sees Saxeo'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 saxeo-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 is the stricter per-response claim and reads false today — see the confidential tier). 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 → Saxeo → Venice → vendor. The vendor is two hops from your identity; Venice sees only Saxeo's identity, never yours; Saxeo never persists content. No single party outside Saxeo holds who and what together, and Saxeo 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 Saxeo'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 Saxeo 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 Saxeo-verified enclave. Two do today: saxeo-confidential-qwen3.6-35b and saxeo-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 Saxeo id is a contract, so we don't delete one when its upstream goes away. saxeo-confidential-24b originally mapped to a model the backend has since retired; it is now a compatibility alias for saxeo-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.