OpenAI exposes the Codex harness through a managed Agents API
- The Agents API gives applications access to the Codex harness through an OpenAI-managed API, with OpenAI handling sessions, orchestration, context compaction, and recovery.
- Applications provide their own tools and choose the execution environment, while agents can run code, edit files, connect to MCP servers, and produce artifacts inside a sandbox.
- Usage is billed at the selected model's API rates; OpenAI tools use standard tool rates and OpenAI-hosted sandboxes use container rates.
- The documentation includes examples for a directory-tree script in an OpenAI-hosted sandbox and a multi-agent release-note comparison that combines subagent findings.
- OpenAI links complete applications for incident response, Slack requests, warehouse SQL analysis, GitHub issue investigation, and document review.
Hacker News opinions
I do not see why I would choose the API over the SDK. The SDK in a sandbox feels much better.
This looks like another layer of vendor lock-in to me, though I may be wrong about how easily it can sit inside a broader agent system.
I would use the API to avoid running and securing my own sandboxed VM.
I assume I would develop with the SDK, then deploy through the API.
I want my app to trigger a Codex turn after event X and let the user monitor it in the Codex app. Today I would need polling or a Codex-like frontend of my own.
This sounds similar to Cursor Cloud Agents.
I built a small VR harness with Astra that did this over a weekend. It mentioned an SDK for it, but I did not review the code because it was an experimental personal project, and I think non-personal use may violate the ToS.
I would give the agent a tool or shell script that waits for an event. The agent calls it, the tool sleeps until the event occurs, then returns control to the agent.
I went straight to the sandbox network policy docs. restricted permits only listed domains, but after recent reports of agents changing /etc/hosts to bypass rules, I am not sure I trust that setting.
The obvious curl http://example.com/ test was blocked with Domain forbidden. I did not try an alternate hostname plus a Host: example.com header because that would be an attempt to bypass the domain restriction.
An agent inside a container might ask an outside agent to update its network permissions. That request could even be smuggled through an API response header.
Every Codex task now seems to cost me at least 1% of my weekly limit and around 5% of my 5-hour limit, even small ones. I am considering cancelling my OpenAI subscription.
Check the model setting. Astra is the new default and it is also the most expensive.
I see the same behavior: after it thinks briefly and answers, my 5-hour allowance drops 5% to 10%, whether it reviewed a large codebase or changed one config value.
My new account returned to the old usage behavior even after a lot of Astra work. My older account burns through 20% unusually fast, so token accounting does not look equal across accounts.
I would rather get access to the reasoning tokens I pay for than another push toward vendor lock-in. There are vendor-neutral options such as chatbotkit/platform.
Subscription users cannot use this, so it seems aimed at the largest companies. codex -p is the subscription equivalent, or ACP if you want that setup.
I can see this becoming a more durable moat than local agent harnesses, especially if OpenAI bundles unrestricted models or fine-tuned agents that have no direct API. I still want artifacts and work in progress on my own machine, not only a final output.
I have been successful with Codex in a normal QEMU VM and remote control from my phone. I can get much of this convenience without locking into a managed service.
I run long-lived Claude Code or Codex sessions on a server, so I can close my laptop and resume from any device. A Docker container also gives me control over configuration and keeps AWS SSO tokens and SSH keys off the agent's host.