OpenAI Deployment Layer: The Assistants API Precedent

OpenAI announced the Assistants API at DevDay on 6 November 2023. Sixteen months later, in March 2025, it shipped the Responses API and said the Assistants API would be deprecated, with a target sunset in the first half of 2026. Sixteen months from launch to a deprecation notice, on the developer-facing product whose entire pitch was that you would no longer have to hand-roll orchestration.

That number is the one to hold onto while you read anything about OpenAI’s new deployment initiative.

Here is our boundary, stated up front. We did not test the new offering. We could not verify its pricing, its regional availability, its SLA, whether it exposes a genuinely new API surface or repackages existing endpoints, or whether it is a hosted service or a library you run. We are also not going to paraphrase the launch post — it takes four minutes to read, you are capable of reading it, and a summary of it is worth nothing to you. What follows is the part the announcement will not contain: how to price the switching cost before any of those numbers exist.

The number the launch post cannot give you

A launch post is written before the first customer has been through a deprecation cycle. It can tell you the ceiling — what the thing does when it works. It cannot tell you the floor, which is what happens to your codebase when the vendor’s roadmap moves.

For a managed deployment layer, the floor is decided by three things, and only one of them shows up in a pricing page:

• How much of your state the vendor holds. Not tokens. Rows.
• How stable the interface is — measured in deprecation notices per year, not in changelog entries.
• Whether an equivalent exists elsewhere that speaks the same wire protocol.

You can measure all three on OpenAI’s existing surface area today, without knowing a single detail about the new product. That is a better basis for a decision than the announcement is.

The Assistants API is the precedent, not the exception

The Assistants API held state server-side. Your conversations lived in OpenAI thread objects. Your messages lived in message objects attached to those threads. Your execution history lived in run objects. Your retrieval corpus lived in vector stores on their side. Your application kept an ID and asked for the rest.

That design is exactly why migrating off it cost real engineering time. Porting prompts was the easy half — prompts are text and you already have them in your repo. The other half was exporting months of thread state into a schema you now had to design yourself, backfill, and verify, while production kept writing to the old system.

Contrast /v1/chat/completions, which is stateless. You resend the full message array on every call. That is more tokens on the wire and more work for you, and it is also the reason the endpoint has outlived two orchestration products layered on top of it. There is nothing to migrate. Your history is already in your database, because it was never anywhere else.

The rule that falls out: the more state a managed layer holds on your behalf, the higher your exit cost, and it does not scale linearly. Six months of stored runs is not twice the migration of three months — it is the same migration plus more data to reconcile under more load.

The portability test, in three questions

Before you put a managed deployment layer on your critical path, answer these. They take an afternoon.

1. Can your production path get the same result from /v1/chat/completions? That endpoint is implemented by vLLM, Ollama, LM Studio, Groq, Together, and OpenRouter, among others. If your inference call only speaks it, changing providers is a base URL and an API key. If it speaks a proprietary orchestration surface, changing providers is a project with a Jira epic.

2. Where does your state live? Open your database. If your run history, tool-call transcripts, and retrieval index are not in tables you own, your exit cost is a data export project you have not scoped and cannot estimate.

3. What are you actually buying? Some things a vendor sells are measurable: the Batch API’s 50% discount against a 24-hour completion window is a number you can put in a spreadsheet. Prompt caching, which kicks in on input prefixes at roughly the 1,024-token mark, discounts the repeated part of your prompt and shortens time-to-first-token — also measurable. “Ship AI applications faster” is not a number. If the value proposition doesn’t reduce to a figure you can check after a week in production, treat it as unpriced.

One asymmetry worth noting: OpenAI’s Agents SDK is open source and runs inside your process. A library you can vendor and fork is a different risk class from a service you rent, even when both carry the same logo. We do not know which category the new deployment offering falls into, and that is the single question we would want answered first.

What we would do, and the condition that flips it

Default: keep the boundary at chat completions. Put every model call behind one module with a Provider interface, and write the second implementation on day one — a local vLLM instance or a competing hosted model. The second implementation is the only thing that proves the boundary is real rather than aspirational, and it costs you about a day. Everything above that module stays yours: history in your Postgres, retrieval in your vector store, retries and rate-limit handling in your code.

The condition that flips it: the managed layer is the only path to a capability you genuinely cannot rebuild. A model that isn’t exposed through the raw API. A latency tier you have measured yourself and cannot hit. A compliance certification you would otherwise be buying separately at higher cost. Those are real reasons, and in those cases lock-in is simply the price of the capability — pay it. But keep the dependency inside the same one module, and write the export script before you have data worth exporting. The export script written at month one is an hour. Written at month eighteen, under a deprecation deadline, it is a sprint.

What we did not test, and would want before revising any of this: actual throughput and cost of the new offering at production volume, and whether OpenAI’s own Assistants-to-Responses migration tooling turned out to be as painless in practice as it read on paper. If someone has run that migration end to end, their write-up is worth more than the launch post and this article combined.