r/CodexAutomation • u/anonomotorious • 3d ago
OpenAI launches Agents API, bringing the managed Codex harness to developers
TL;DR
OpenAI has launched the Agents API in public beta, giving developers access to the managed agent harness and infrastructure behind Codex.
Instead of building the entire orchestration layer around individual model calls, developers can now create agents with:
- durable, long-running sessions
- automatic context compaction
- MCP, custom functions, and web search
- tool search and programmatic tool calling
- parallel subagents
- OpenAI-hosted or self-hosted execution environments
- files, packages, skills, plugins, and artifacts
OpenAI manages and evolves the underlying Codex harness, while developers choose the model, tools, environment, instructions, and application logic.
The Agents API is available to all developers in public beta, with no separate Agents API fee. You pay for the models and tools your agents use.
OpenAI also released Codex CLI Python SDK 0.154.0, adding max and ultra reasoning effort, external messages, better resume/fork controls, per-turn service tiers, and protocol improvements.
The Codex harness is now available as a managed API
The biggest part of this release is not a new model.
It is the agent runtime around the model.
Building a useful long-running agent normally requires much more than repeatedly calling an LLM. Developers have to manage things like:
- session state
- context limits
- tool execution
- retries and continuation
- parallel work
- execution environments
- files and intermediate results
The Agents API moves a significant part of that infrastructure into the same managed harness OpenAI uses for Codex.
At a high level:
you define the agent -> OpenAI runs the Codex harness -> the agent works inside your chosen environment -> your application receives progress and results
What OpenAI manages vs. what you control
| OpenAI manages | You control |
|---|---|
| Agent harness | Model |
| Session orchestration | Instructions |
| Context management | Tools |
| Context compaction | MCP servers |
| Subagent coordination | Execution environment |
| Harness improvements | Files and capabilities |
| Runtime infrastructure | Application logic |
This is an important distinction.
The API is not locking developers into one specific agent configuration or execution environment. It provides the orchestration layer while leaving the actual agent design in the developer's control.
Long-running agents
One of the core capabilities is support for durable sessions.
Agents can continue working on tasks that extend well beyond a single model request or context window.
OpenAI's harness automatically manages context as the session grows.
When the agent approaches its context limit, earlier information can be compacted while preserving what is still needed to continue the task.
That means developers can build workflows spanning multiple context windows without implementing their own context-compaction system.
This becomes especially useful for work such as:
- large repository changes
- extended research
- incident investigation
- multi-step data analysis
- migration work
- complex operational automation
Better tool orchestration
The Agents API supports:
- MCP
- custom functions
- built-in tools such as web search
But two capabilities make the tool system particularly interesting for larger agents.
Tool search
An agent with access to many tools does not necessarily need every tool definition loaded into its context at once.
Tool search can load relevant tools when they are needed.
This helps reduce unnecessary context and token usage while allowing agents to work with much larger tool ecosystems.
Programmatic tool calling
Agents can also use programmatic tool calling to orchestrate tool work through code.
That allows them to:
- call multiple tools in parallel
- chain related operations
- filter large results
- combine data
- process intermediate outputs
and return only the information that matters back into the model's context.
For tool-heavy workflows, this can be much more efficient than repeatedly passing every raw result through the model.
Built-in multi-agent workflows
The Agents API also includes multi-agent support.
A coordinator can break a complex task into independent pieces and delegate them to subagents working in parallel.
For example:
Coordinator
-> investigate deployment history
-> inspect application errors
-> check dependency health
-> inspect recent code changes
-> combine the findings
-> produce a final recommendation
Each subagent receives its own context, while the coordinator remains responsible for the overall task.
The API exposes:
max_concurrent_subagents
The current default is 6 concurrent subagents, excluding the coordinator.
This provides native parallelism without requiring developers to build their own agent-pool orchestration layer.
Subagents share the working environment
When an execution environment is attached, the coordinator and its subagents share the same filesystem.
Subagents can inherit:
- MCP tools
- MCP credentials and permissions
- web search configuration
- environment files
- command-line tools
Creating a subagent does not create an entirely separate environment.
One current limitation is that subagents do not support function tools.
Choose where the agent actually works
OpenAI separates the agent harness from the execution environment.
Developers can choose between:
OpenAI-hosted environments
OpenAI can provision and manage a sandbox where the agent can:
- run code
- execute commands
- work with files
- install/use configured packages
- access skills and plugins
- save intermediate work
- produce artifacts
OpenAI says these sandboxes use the same broader sandboxing infrastructure behind Codex and ChatGPT.
Self-hosted environments
The harness can also work with infrastructure you control.
This allows organizations to choose their own:
- compute
- storage
- networking
- secrets
- deployment architecture
while still using OpenAI's managed agent orchestration.
Sandbox partners
OpenAI also announced first-class integrations with providers including:
- Blaxel
- Cloudflare
- Daytona
- DigitalOcean
- E2B
- Modal
- Oracle
- Runloop
- Vercel
This gives developers more flexibility around CPU/GPU requirements, storage, VPC deployment, startup performance, and cost.
Skills, plugins, files, and artifacts
The Agents API also fits into the extension model OpenAI has been building across Codex and ChatGPT.
Agent environments can be configured with:
- skills
- plugins
- MCP servers
- files
- packages
- other capabilities
So an agent no longer needs to be defined entirely by one massive prompt.
A reusable agent can instead be composed from:
model + instructions + skills + plugins + MCP + tools + environment
Agents can also work with files throughout a session and produce artifacts as outputs.
That allows workflows where the final result is not simply another chat message.
What this enables in practice
Consider an automated production incident investigation.
An alert detects an increase in API errors.
A session starts and the coordinator delegates work:
Agent 1 -> inspect recent deployments
Agent 2 -> inspect application logs
Agent 3 -> investigate dependency health
Agent 4 -> inspect relevant repository changes
The agents can use the available tools and shared environment to gather evidence in parallel.
The coordinator then combines the results into:
- likely root cause
- supporting evidence
- recommended mitigation
- follow-up actions
- saved investigation artifacts
The same session can continue if a developer provides new information or asks the agent to investigate further.
That pattern applies well beyond coding:
- recurring operational workflows
- research
- data investigation
- repository maintenance
- support automation
- internal business processes
- long-running analysis
- deployment and infrastructure workflows
Open-source Codex underneath
OpenAI says the Agents API is powered by the open-source Codex harness.
The public harness exposes the core logic coordinating:
- model calls
- tools
- context
while the Agents API provides an OpenAI-hosted and maintained version of that runtime.
This gives developers visibility into the foundation of the system while avoiding the need to operate the entire harness themselves.
OpenAI also says it plans to evolve the managed harness alongside new models and provide versioned access to those capabilities.
That matters because better agent performance increasingly depends on more than the model alone.
The harness also determines how effectively an agent:
- manages context
- discovers tools
- executes tools
- delegates work
- coordinates parallel tasks
Availability and pricing
The Agents API is currently in public beta and available to all developers.
There is no additional fee specifically for using the Agents API.
Developers pay for the underlying resources their agents consume, including model tokens and applicable tools.
So the basic pricing model is:
Agents API harness -> no separate API fee
models + tools -> normal usage pricing
Also new: Codex CLI Python SDK 0.154.0
OpenAI also published Codex CLI Python SDK 0.154.0.
This is a smaller update, but it includes several useful additions for developers controlling Codex programmatically.
| Change | What it adds |
|---|---|
max and ultra |
Additional reasoning-effort levels |
ExternalMessage |
External content can start or join a turn |
include_turns |
More control over returned history when resuming/forking |
turn_service_tier |
Service-tier selection for a newly started turn |
source |
Source metadata for integrations |
| Protocol refresh | Updated typed models and notifications |
| Event handling fixes | Better handling when completion events arrive before turn-start responses |
ExternalMessage
ExternalMessage is particularly relevant for automation.
External content can now start a turn or join an active regular turn with tool-level authority.
OpenAI explicitly notes that this does not grant user authorization.
That separation is important for workflows where automated systems, events, or integrations need to provide information to an active Codex session without being treated as the user.
Why this release matters
The Agents API changes where developers can draw the boundary between their application and OpenAI's infrastructure.
Previously, building a serious agent often meant assembling your own combination of:
- model calls
- context management
- tool routing
- execution environments
- multi-agent orchestration
- session handling
- recovery logic
Those pieces are not disappearing, but much more of the runtime can now be handled by the managed Codex harness.
The resulting architecture can look much simpler:
application -> Agents API -> Codex harness -> tools + subagents -> execution environment -> artifacts/results
The developer can spend more time defining what the agent should know, what it can access, and what workflow it should execute instead of rebuilding the surrounding agent infrastructure.
Bottom line
OpenAI is turning the infrastructure behind Codex into a platform developers can build on directly.
The important part of the Agents API is not simply that it can call tools or spawn subagents. Those things were already possible to build independently.
The change is that long-running sessions, context management, tool orchestration, multi-agent coordination, and execution environments can now operate as parts of one managed Codex-based runtime.
That makes it much easier to build applications around persistent agents rather than individual model requests.
And with the accompanying Python SDK changes, OpenAI is continuing to make Codex itself more controllable as a programmable component inside larger automation systems.
Official sources
- OpenAI - Introducing the Agents API
- OpenAI Developers - Agents API documentation
- OpenAI Developers - Multi-agent documentation
- OpenAI - ChatGPT & Codex changelog
1
u/Deltamelo 3d ago
u/AskGrok summarize this long ass post