If you have ever shipped an LLM agent past the demo stage, you have written the same three pieces of plumbing: something to compact context before the window fills up, something to keep a long task alive across restarts, and something to fan work out to sub-tasks and merge the results back. None of that is your product, all of it breaks in interesting ways, and a model upgrade usually means rewriting it.
On September 10, 2026, OpenAI put that plumbing behind an API. I went deeper on the launch details and full pricing table in a longer writeup on DevToolLab, but here's the short version of what it manages, what it costs, and when it's worth switching to.
What's actually new here
The Agents API is a managed version of the harness that already powers Codex. OpenAI's own framing: it manages sessions, orchestration, context compaction and recovery, while your app supplies the tools and picks where the agent runs.
Four concepts make up the model: an agent (model, instructions, tools, MCP servers), an environment (an optional sandbox for files, skills and commands), a session (a durable instance that works on tasks and takes input), and events/items (what you send in and what comes back out). The word that matters most is "durable" - OpenAI says sessions are built to keep running reliably for days, not minutes.
The four things you stop writing yourself
- Context compaction. The API compacts earlier context automatically as a session nears its limit, so a workflow can span multiple context windows without you hand-rolling summarization logic.
- Tool search. Instead of stuffing every tool definition into the prompt, relevant ones load on demand, cutting token usage while keeping the model's cache intact.
- Programmatic tool calling. Agents run calls in parallel, chain them, and filter results in code before anything hits the context window, which matters when you're working through large volumes of data.
- Subagents. Multi-agent support splits a task and hands pieces to parallel subagents, each with its own context, while a main agent merges the output. The config is genuinely two lines:
"agent": {
"model": "gpt-6-astra",
"multi_agent": { "enabled": true, "max_concurrent_subagents": 3 }
}
OpenAI published a customer number from Ciridae's CTO: an eval score moving from 0.71 to 0.85 with a 4x latency drop after adopting subagent flows. That's a vendor quote, not an independent benchmark, but directionally it's what you'd expect from parallelizing work that used to run sequentially.
Where the agent actually executes
You pick the compute: an OpenAI-hosted sandbox, your own infrastructure, or one of nine launch partner sandboxes (Cloudflare, Modal, E2B, DigitalOcean, Vercel, Oracle, Daytona, Runloop and Blaxel among them). The hosted option runs on the same infrastructure behind Codex and ChatGPT. The self-hosted and partner routes exist for the reasons that usually kill a managed service: your own VPC, your own secret storage, specific hardware profiles.
The billing model is simpler than the marketing
"No additional fees for the Agents API" is technically true and also not the whole story. There's no line item that says "Agents API," but you still pay standard model rates for gpt-6-astra tokens and standard container rates for the hosted sandbox. Containers bill per 20-minute session, from $0.03 for 1 GB up to $1.92 for 64 GB, with a five-minute minimum. That's cheap per hour and easy to leave running, which is exactly the invoice surprise this shape produces. The tokens, not the container, are where the real spend goes - the full rate table is in the original post.
It shipped, it didn't just get announced
The fastest way to tell if a beta is real is to check the published client rather than the blog post:
import OpenAI from "openai";
const client = new OpenAI({ apiKey: "sk-not-a-real-key" });
let cur = client, trail = "client";
for (const p of ["beta", "agents", "sessions", "create"]) {
cur = cur?.[p];
trail += "." + p;
console.log(`${trail.padEnd(38)} ${cur === undefined ? "MISSING" : typeof cur}`);
}
On the version released alongside the announcement, every step resolves - client.beta.agents.sessions.create is a real function, not a stub. Calls need the OpenAI-Beta: agents=v1 header (added automatically by the SDKs) and a key scoped to api.agents.read, api.agents.write and api.responses.write. Keep that key out of the agent's own sandbox.
Framework or managed runtime?
The harness underneath is openai/codex, Apache-2.0, written in Rust, sitting at 123,764 stars as of September 13, 2026. That's inspectable in a way a fully closed managed runtime isn't, and you can read the orchestration loop even though you can't modify the one OpenAI runs for you.
The tradeoff that decides it for most teams is model portability. A framework like LangGraph or CrewAI abstracts over providers. The Agents API is OpenAI's runtime for OpenAI's models, full stop. Picking it is a provider decision, not a library decision.
Should you actually switch
- New agent, already committed to GPT-6 Astra: start here. You skip writing compaction and subagent code, and there's no service fee for it.
- Framework already in production and working: stay put, but read the harness source. The beta is days old and migration isn't free.
- Multi-provider by requirement: keep your abstraction. This is OpenAI-only by design.
- Regulated or VPC-bound: the self-hosted and partner sandbox options are the actual reason to look twice. Confirm your provider is on the supported list first.
Before building on any of this, ask what happens when a session dies six hours in. If the answer is "the harness handles it," test that assumption during the beta instead of after you've shipped on it.
References
- OpenAI Agents API: What You Actually Get - the original DevToolLab writeup, with the full pricing table and framework comparison
- Agents API overview, OpenAI developer docs
- openai/codex on GitHub
- AI Token Counter - estimate a session's prompt cost before leaving a long-running agent unattended
- Webhook Receiver - inspect the completion/input-needed payloads the Agents API docs suggest wiring up
Top comments (0)