OpenAI Agents API

I think we’re still figuring out the right abstraction for offering agents as a product.

- LLMs are a great foundation but building your own harness is a huge undertaking, a deep rabbit hole.

- There are harnesses available as open source libraries but that’s still coupled to an environment. Where does the state persist? Like maybe I’m a Cloudflare worker and don’t even have a file system.

Agent as a service like this lets you plug in the tools it needs to be whatever kind of agent you want. But they still get to encapsulate and continue to iterate on the really deep parts of the harness that all agents need like memory and context management.

That said, my money right now is not on the offerings from OpenAI and Anthropic because they’re stuck using their own proprietary frontier models and those aren’t actually the best choice for most agents right now. A competitor who is not an LLM lab gets their pick of the market at any given moment. Like you’d want to be using GLM 5.3 Flash right now for most things agentic.

Instead of this push for more vendor lock-in, give us the reasoning tokens we pay for. Thanks.

I've recently had great success running codex in a regular qemu VM and using codex remote control to talk to it from my phone.

Honestly works extremely well as a personal assistant.

I can see why turning it into an API makes sense, just be aware you might not need to lock yourself in if you can setup your own VMs.

This is pretty interesting in a lot of non-surface-level ways.

I can see OpenAI pushing for this as a sort of more durable moat compared to the now huge number of agentic harnesses that run on your own machine.

This might be getting the foot into some sort of bundling as well. Like unrestricted models or custom fine tuned agents inside this and not providing direct APIs to those endpoints.

That being said I don't see a lot of reasons for people to jump on this if it doesn't bundle something killer. Like to me the fact that GPT Work runs on your own machines and all the artifacts and work in progress there for you to look at is sort of the whole point. I don't just want a final artifact.

Perfect for when you want your data to be stolen programmatically.

It's actually a really great idea, but it doesn't have to go beyound existing Responses or Chat Completions APIs.

We built that in my current company and it works wonders to just script entire persistent workflows with a simple SDK.

What I want (which I don’t think exists?) is a way to trigger turns that the user can monitor in the codex application. I.e., when event X happens, my application triggers Codex to take a turn with input Y, which the user can monitor through codex. Right now the only way to get close to this is with polling or essentially rewriting a codex-like frontend.

Why would you choose api vs sdk . Sdk in a sandbox feels much better .

well im shit out of ideas now this was literally what i was working on for the past few months

The pricing on this is a bit confusing. Does each execution of an agent session create a new environment? And is that environment then billed for at least a full hour (despite prices being quoted per 20 minutes), after which it naturally expires? Is there a way to deliberately shut down an environment so you don't have to keep paying for it?

Likely benchmaxed.

you can't use your subscription with this so it's likely the largest companies in the world that can truly use this

Since a week or so everything I ask codex to do, no matter how small, uses at least 1% of my weekly limits and like 5% of my 5h limit. It's getting so bad I'm thinking of just canceling my OpenAI subscription, because this has no use anymore.

This was sorely needed.

Hopefully this kills the need to use the CLI and we can just use the API instead.

Now you, too, can ripoff mathematicians worldwide!

[flagged]

[flagged]

I jumped straight to the section on configuring your sandbox's network access: https://developers.openai.com/api/docs/guides/agents-api/env...

It offers three settings:

  enabled:    Allow outbound access. This is the
    default unless you inherit a template policy.
  disabled:   Block outbound access.
  restricted: Allow only the hosts listed in allowed_domains.