OpenAI Agents API: Codex's skeleton is up for rent

Most developers who set out to build an AI agent complain about the same thing: calling the model is easy, everything else is hard. Keeping track of which step the agent is on. Deciding what gets thrown out and what stays when the context window fills up. Picking up a job that died halfway at the point where it died. Running code without setting anybody's machine on fire... None of this is the model's job, but all of it lands in your lap. On 10 September 2026 OpenAI opened a product to general beta that offers to carry that load for you: the Agents API. A month and a half has passed since the launch, and the first wave of headline excitement has died down. Now we can look at what's actually on sale with a cool head.

Let me show my sources: all I have to go on is OpenAI's developer documentation and the news stories written after the launch. We didn't set up the API and run it for this feature. Everything I say below that it "does" is something the docs say it does.

What's on sale?

Short version: OpenAI is opening up the harness that runs behind Codex as an API, and running it for you. (Think of the tack you put on a horse: the skeleton that wraps the model, drives the loop, calls the tools and feeds the results back in.) OpenAI takes on the sessions, the orchestration, context compaction (trimming the old conversation down to make room) and recovery from errors. You supply the tools, and you also choose where the agent runs.

That distinction matters. Until now, what you got from OpenAI was really a model. You wrote the loop yourself, and you picked whatever library you liked to put on top of it. Now the loop itself has become a service. That's why the developer press (MarkTechPost, AI Weekly and a few developer blogs) reads the product as a big platform move for OpenAI. The writers agree on one thing: the days of every team rewriting orchestration, compaction and recovery its own way may be coming to an end.

The beta label isn't there for decoration. On the REST side you have to add the OpenAI-Beta: agents=v1 header to every request, and in the SDKs everything lives under client.beta.agents. In other words, this interface can change. And if it does, nobody's going to send you a letter of apology.

Four concepts, plus a sandbox

The docs split the system into four pieces:

Agent: The agent's definition. Which model, which instructions, which tools and which MCP servers it uses all go here.

Environment: An optional sandbox or computer. This is where the agent works with files, reads its skills and runs its commands.

Session: A persistent instance of the agent. It keeps its state between turns and, when it's interrupted, carries on from where it left off.

Events/items: Everything that goes in and everything that comes out.

The design is pretty clean. "The agent" and "the agent's current run" are kept apart. You can open as many sessions as you like from the same definition.

What the harness can do sits in the docs as a long list. It runs commands and code inside the sandbox. It connects to MCP servers over HTTP. It lets you cut in and steer the agent while the job is running (steering: if the agent wanders down the wrong road, you don't have to start the whole job over). It manages context by gathering up past work and shortening it. It can hand work out to subagents: with the multi_agent setting and the max_concurrent_subagents inside it, you decide how many subagents run at once. You can get the result as a stream. If you want, you can also get a webhook telling you when the job is done or when the agent is waiting for input from you. The example in the docs also shows programmatic_tool_calling and web_search tools.

Let me open a small parenthesis on context compaction. You know that programs once had to fit into 64 kilobytes. Today a model's context window is thousands of times that memory, and a long-running agent still fills it up. When it does, somebody has to decide: what do we forget? In the old days the programmer made that call by drawing a memory map. Now another model makes it. Is that progress, or the same old headache blown up to a bigger size? I'll leave that one for you to chew on. Anyway, back to the subject.

Where does the agent run?

There are three options. The first is the sandbox OpenAI hosts: no setup to fuss with, and you pay the standard container price for it. The second is an environment you host yourself. Here, with the workspace_directory and capability_directories settings, you tell the agent which folder to look at and where its skills live. The third is sandboxes from partner companies. The launch page reportedly names Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel. We know this list not from the launch post itself but from what search results quote of it. Before you bet the farm on any one company, check OpenAI's page for yourself.

There's one more detail on the ecosystem side: OpenAI's docs link to "Bedrock Managed Agents", described as an AWS service built on top of the Agents API. So the harness isn't only sold through OpenAI's own front door. The sample applications in the docs also make it plain what they're aiming at: an incident response agent, a Slack bot, a data analyst, a GitHub issue researcher, a document reviewer. All of them in-house, long-running, tool-using jobs. Nobody who wants to write a chatbot comes here for one.

SDK support is broad. The docs have examples in JavaScript, Python, Go, Java and Ruby, with raw cURL thrown in for good measure. As for models, every example uses a model called gpt-6-astra, but a list of supported models has NOT been published. Some news pieces write that versioned access to new capabilities is promised with each new model, but the docs we read have no sentence confirming it. A page on Product Hunt also claims the harness is open source. No OpenAI source says so, so let's file that under rumour.

How much?

The docs list no separate fee for the Agents API itself. Model usage is billed at the API price of the model you choose. OpenAI's own tools are paid at their standard prices, and the sandboxes OpenAI hosts at standard container prices. At first glance that looks fair: no extra money for the harness. Fine, but what's going to make your bill balloon? When you push the subagent count up to four, every time a summary is called for compaction, every time a web search runs, the meter is ticking. Knowing in advance how many of those calls the harness makes on its own initiative isn't easy. So treat max_concurrent_subagents not just as a speed knob but as a budget knob too.

The real issue: data

Now for the two lines that will leave a lot of companies standing at the door. According to the docs, data residency is US only. Zero Data Retention, the option where OpenAI doesn't keep your data at all, isn't supported. And this doesn't change even if you host the sandbox on your own machine!

Read that last detail carefully, because your gut tells you the opposite. You think: "If I run the code on my own server, the data stays with me." It doesn't. OpenAI holds the session, OpenAI does the orchestration, OpenAI summarises the context. Every scrap of every file the agent sees passes through that loop. If you're a company obliged to keep customer data in Europe or in your own country, then in its current state you shouldn't let this API anywhere near that data. It's no surprise that, next to the beta label, these are the two flaws the developer press brings up most.

And some homework: the docs say sessions and artifacts can be deleted. ALWAYS delete a session once its job is done. If your agent has been rummaging through a customer's files, don't let those artifacts sit there forgotten. A delete button existing doesn't mean anyone ever pressed it.

Verdict

The Agents API is the most ambitious thing OpenAI has sold to developers so far. And it goes at it from the right end: it offers to replace the part everyone writes badly on their own (the loop, recovery and context management) with a skeleton that's been battle-tested in Codex. The four-concept model is simple, the choice of sandbox is flexible, and not charging separately for the harness is honest. For teams building in-house tools whose data isn't sensitive (an issue researcher, an internal document reviewer), building your own orchestration from scratch is now a hard sell.

But it comes with two conditions, and neither is up for negotiation. One: you're building a production system on an interface with a beta header. Two: your data will sit in the US, with no guarantee that it won't be kept. Your own server doesn't change that. Until those two lines get fixed on paper, the Agents API can only be a practice board for the big enterprise jobs the product is really aimed at.

If you've built your own agent, write in and tell me where you got stuck. When the beta label comes off or data residency widens, I'll reopen this file. That's it for now, see you next time.