Choosing routes in the Tresor API just got simpler. You can now use shorter canonical selectors like gpt-oss-120b, eu/gpt-oss-120b, or tresor/gpt-oss-120b more consistently across requests, failover lists, and model discovery instead of reaching for a fully pinned route every time.

The practical benefit is better availability with less route bookkeeping. If you only care about the model family, or the model plus one region or provider, Tresor keeps more eligible concrete routes available behind that selector.

Use the shortest route that fits

• Shorter selectors are now the clean default - The same canonical route forms now show up consistently in model, chat failover, tresor.requested_route, and the published model catalog.

• Availability stays higher when you do not over-pin - A bare model key gives Tresor the most room to keep requests moving, while region or provider selectors let you narrow the route only when you actually need to.

• Model discovery is easier to reason about - GET /v1/models?detail=true now publishes logical, region, provider, and concrete routes in one flat catalog, and route_id filters accept canonical as well as compatibility IDs.

Read our new Routing Docs to find out more.

Pin deliberately when it matters

You can still pin a full route when pricing, residency, prompt caching, or reasoning behavior needs to stay fixed. The difference is that the contract is clearer now: shorter routes buy flexibility, fully pinned routes buy control.

We also refreshed the docs and model catalog views around this behavior, including a new Routing concept page and clearer failover guidance, so it is easier to understand what the router may still choose on your behalf.

Compatibility: This does not change compatibility with our previous modelID schema. So routes like eu/auto/gpt-oss-120b continue to work and you can migrate to the new schema when you are ready.

You can now control reasoning the same way across supported Tresor routes. Instead of learning provider-specific flags for each upstream, send one reasoning value and Tresor translates it behind the scenes for the route that actually serves the request.

This is the main upgrade: reasoning effort is now unified at the Tresor layer. That makes it easier to move between providers, use automatic routing, and keep failover plans without rewriting request logic whenever a model sits behind a different upstream contract.

One request shape, clearer control

• One public reasoning knob — Prefer "reasoning": "high" or "reasoning": "off" instead of provider-native controls. The object form still works for compatibility.

• One shared effort ladder — Tresor accepts the same public reasoning-effort values across supported routes and maps them route by route.

• Route-aware discovery — GET /v1/models?detail=true now shows each route's verified supported_efforts and default_effort, so you can see what is actually available before you send traffic.

• Safer routing — When one route cannot satisfy the requested reasoning setting, Tresor can still choose another compatible route for the same logical model.

Reasoning text now comes back in the new reasoning fields: message.reasoning for non-streaming responses and delta.reasoning for streaming responses.

reasoning_content still works as a compatibility alias for now, but it will be deprecated on 2026-09-01. If you read reasoning traces today, switch to reasoning now and you will not need another migration later.

Learn more at docs.tresor.co/guides/reasoning-controls

Kimi K3 is now available

The second big update in this release is Kimi K3. It is the latest open-source frontier model in the API, and it gives you another top-tier option when you want strong general intelligence without moving away from the OSS side of the model landscape.

• A new high-end OSS option — Kimi K3 is now available in the Tresor API model lineup.

• Frontier-level intelligence — In practice, it belongs in the same conversation as the latest Anthropic and OpenAI models on hard, multi-step work.

• Same API ergonomics from day one — Kimi K3 fits into the same routing layer, receipts flow, and unified reasoning controls described above.

As always, the privacy model does not change with any of this. You get the same zero-access guarantees, with a simpler API contract on top.

Tresor now runs across five providers in total, with broader overlap on several of the most used models. That gives the platform more room to recover when one upstream slows down, rate-limits, or has a bad day.

The benefit is simple: more overlap means better fallback. Instead of a popular model depending on a single route, Tresor can now keep more requests moving through alternative routes while maintaining the transparency you are used to.

More ways through

• Broader model overlap - More of the popular models now exist on more than one provider, which reduces single-route risk.

• Stronger fallback behavior - When one upstream has trouble, Tresor has more chances to route around the issue before your app feels it.

• Better availability in practice - This wider provider layer helps improve the consistency you see in day-to-day use, not just in theory.

Built for production workloads

This matters most for products and agents that need steady behavior under real traffic. With five providers in the pool, Tresor is better positioned to absorb isolated provider problems while keeping the same private, attested execution model.

Privacy: Expanding fallback does not change the zero-access design. Your requests stay inside the same sealed, confidential path.

If you rely on Tresor for live features or long-running agents, this is the kind of infrastructure change that quietly pays off every day.

Tresor now supports prompt caching across multiple providers and models, including GLM 5.2 and Kimi K2.6. If your workflow sends the same large context over and over, you no longer have to pay full price every time.

That matters a lot for agentic coding. Coding agents tend to resend the same repository map, instructions, diffs, and tool state on every turn. With caching on supported routes, that repeated context becomes much cheaper, which makes confidential coding workflows far more competitive on price.

Big context, smaller bills

• Reuse repeated context - Large prompts, repo summaries, and long instructions can be treated as cached input instead of billed like brand-new input every turn.

• Run longer coding loops - Refactor, test, fix, and retry cycles become much easier to justify when the shared context is cheaper to carry forward.

• Keep model choice open - You can get the pricing benefit on more than one route, instead of tying your workflow to a single model or provider.

Better economics for private agents

Private workflows usually need more context, not less. Prompt caching helps you keep that context inside Tresor's sealed environment without turning every follow-up into a full-price request.

Privacy: Cached context keeps the same zero-access, sealed-environment path as the rest of the Tresor API.

If you're building coding agents, background automations, or long multi-step analysis flows, this is one of the most practical API upgrades yet.

Two useful upgrades just landed in the Tresor API. You can now choose a custom timeout for each request, and you can now use GLM 5.2, a model that feels genuinely competitive for coding-heavy work.

If you build user-facing products, both updates matter for the same reason: you get more control over how your product feels, and more choice in how strong the output can be.

Set the pace for each request

The new custom timeout option gives you more control over the experience you want to deliver.

• Fail faster when speed matters — For interactive features, you can stop waiting sooner and move to the next path instead of leaving users hanging.

• Be more patient when the task is worth it — For deeper or longer-running work, you can allow extra time when better output matters more than immediate speed.

• Tune the API to the job — The same API can now feel tighter for live experiences and more flexible for background workflows.

A serious new model for code

GLM 5.2 is now available in the API, and it is a strong addition for teams that do a lot of coding, refactoring, and debugging.

• Strong coding capability — On coding-heavy tasks, GLM 5.2 feels in the same league as GPT 5.4 xhigh.

• More choice without compromise — You have another high-end model to reach for when code quality is the priority.

• Useful across mixed tasks — It also holds up well when a request needs code, reasoning, and a clear written explanation in the same response.

If you want a third-party snapshot of where it sits, Artificial Analysis has a useful comparison.

🔒 Privacy: Like every model and API feature on Tresor, these upgrades keep the same zero-access, sealed-environment design.

If you want tighter control over response timing or a new top-tier coding model to test, both are ready to use now.

You can now send audio to the Tresor API and get back clean transcripts. That makes it easier to turn meeting recordings, voice notes, and interviews into text you can store, search, review, or feed into your own workflows.

For now, this is an API-only capability. Audio upload is not in the chat workspace yet, but it is something we're already thinking about as we plan the next layer of the product.

Audio in, transcript out

• Built for existing API workflows — If you already use the Tresor API, transcription fits into the same product with the same API keys, dashboard, receipts, and usage tracking.

• Useful for real-world audio — Send voice notes, call snippets, or longer recordings and get text back in a format that's easy to work with.

• Clear operational visibility — Transcription requests show up in usage and billing like the rest of your API activity, so they are easier to monitor and reconcile.

🔒 Privacy: Your audio files are encrypted and processed inside the sealed environment — Tresor never sees the contents.

If transcription belongs in your workflow today, you can use it through the API now. If Drop us a line, if you need it in chat ASAP, we’ll see what we can do. ;-)

This is a big milestone for Tresor, and an important one for customers who want to build on private AI without lowering their standards. You can now build directly on top of Tresor with an OpenAI-compatible API, while keeping the privacy, sealed execution, and proof that make the product different.

OpenAI-compatible from day one

Point your existing OpenAI client at Tresor, use a tr- API key, and start making requests. The API supports streaming out of the box, and newer capabilities like tools and reasoning content are there from the start.

🔒 Privacy: The API keeps the same zero-access design people expect from Tresor.

A proper product, not just an endpoint

The new API dashboard gives you the basics you actually need on day one:

• API keys — Create and revoke keys from the dashboard, with clear prefixes and last-used visibility.

• Usage tracking — See spend over time, break it down by model, inspect individual rows, and export usage as CSV.

• Billing — Add credits, save payment methods, download invoices, and turn on auto-recharge.

• Operational emails — Get clearer alerts for low balance, depleted balance, payment failures, and API key activity.

Verifiable by default

Every API response can be tied to a signed receipt you can fetch and verify later. That receipt freezes the routed model, cryptographic fingerprints of the request and response, and the attestation trail behind the call.

If you want a stronger guarantee than TLS, tresor-attest lets your client verify it's talking to the genuine Tresor workload before any payload leaves your process.

Also in this launch

• OpenAI SDK examples — Quick-start docs for curl, Python, Node.js, and Go.

• Receipts in the dashboard — Usage entries make it easier to inspect verification details and timestamps.

• First-release polish — Better invoice empty states and fewer rough edges when creating new API keys.

This is the first release of the Tresor API, and it sets the baseline for what we want this product to feel like: easy to adopt, easy to operate, and much easier to trust.

Getting into Tresor now feels more dependable, and the proof behind each conversation is clearer once you're in. This release focuses on the first-run experience, verification, and everyday chat reliability.

Faster signup and email verification

• Cleaner email confirmation — Password setup and redirects now work more reliably after you verify your email.

• Better recovery when verification gets interrupted — If signup stalls, Tresor is better at getting you back on track instead of leaving you in a dead end.

• Invite-aware verification — Joining a workspace from an invite now completes more reliably and lands you in the right workspace.

• Lightweight bot protection — Signup and resend flows now include better abuse protection to keep the experience fast for real users.

• More reliable sign out — Leaving Tresor is less likely to get stuck in an awkward half-signed-in state.

Clearer proof in Private by design

The Private by design panel now does a better job surfacing the full verification path, including router and downstream checks where available.

If you stop a response early, Tresor is also better at preserving the proof behind what was generated instead of dropping into an unclear verification state.

🔒 Privacy: These improvements add clearer evidence, not more collection. Your messages and uploads stay private.

Improvements & fixes

• Better file uploads — Attachments are handled more robustly, with clearer failures when something goes wrong.

• Sidebar updates immediately — New chats now appear more reliably in the sidebar.

• Better stop behavior — Stopping a reply mid-stream is more reliable and less likely to leave verification in an odd state.

A smoother path from signup to first conversation, with stronger evidence all the way through.