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.

Buried in there, note you can opt to self-host your sandbox

https://developers.openai.com/api/docs/guides/agents-api/env...

That makes this much more enticing, and potentially eases transition between providers.

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.

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

I think the line between regular LLM "endpoints" and agents/harnesses is going to become more and more blurry until it's a meaningless distinction.

When you're using ChatGPT/Claude/Gemini etc. you're basically already interacting with some backend harness with tools etc., not a raw LLM. Just give it a computer and be done with it.

I already find myself using Claude Code / Antigravity (via web) instead of Claude / Gemini, even for tasks unrelated to coding. Why use a limited version?

This idea of remotely hosting the agent harness is honestly backwards to what I need.

In so many cases, all the friction is about how to provision access to local data so the agent can work. So you started with the problem of how do I integrate an agent that is running locally with data that is hosted locally, and you have to deal with a bunch of security, data sensitivity and management issues around that. Now you moved the agent to a remote host - pretty much all your problems are worse: now I have a remote agent reaching into my infrastructure to deal with.

I'd much rather the inverse of this: let me run the agent local but provide secure remote hosted sandboxes. That actually solves a real problem because the sandbox running locally means breaking out of it directly intersects your local infra, whereas if it runs in a managed hosted environment I can leave the provisioning and management of that to someone else.

I actually have a good use case for this. For my project, I run a lot of Codex sessions in parallel (via Codex SDK[0]), because they are solving self-contained tasks (building crawlers for websites) and in theory I could scale it to hundreds or thousands of parallel sessions. But my VPS can handle maybe 10 parallel sessions max.

Btw, the crawlers are for classical music websites, the project is https://classicalbot.com/ .

[0] https://learn.chatgpt.com/docs/codex-sdk

I believe is not a good idea for the model providers provides a Agent Infrastructure or hosting service.

This area should be open source and supported by the cloud providers. Because I don't really want to be locked to a model provider when I am building my agents.

Actually this is happening, I found couples:

- https://flueframework.com from Astra - https://eve.dev from Vercel - https://fastagent.sh looks more independent, cloud neutral

There should be more and more options, the OpenAI Agent API may be another GPTs

I launched Epho a few weeks ago as an API like this but for all harnesses: https://epho.io

I built it primarily for ourselves: we are building an AI data engineer, and we need a way to run many of them in parallel securely. An API for this seemed like the most obvious path forward. It makes it trivial to bring agentic capabilities into any product surface without having to deal with sandboxes, reliability issues, compatibility problems, and more.

I think it also makes sense from OpenAI's perspective to do this, but also we did find ourselves needing to change models and harnesses quite a bit, which is why I think this needs to be a layer of its own above the labs. It also needs to be a layer above the sandboxes, since many of them are quite brittle.

Overall, I expect a lot of the agent implementations to move in this direction. I think this is a lot saner for engineers to implement and maintain, and it makes it trivial to build agentic stuff into products.

Though I'm not surprised by this offering, I feel like I need some time to absorb it. It feels like the stepping stone to the next big thing.

It's going to destroy a lot of startups which were monetizing this exact idea. But clearly it's a low-hanging fruit so it makes sense that OpenAI would do it.

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

I've had great success with the OpenAI agents SDK [0]. This way I've been able to build the sandbox + slack + knowledge-bank integrations independently and be very strict with what I expose to OpenAI.

Looking at the Agents API, it seems like it offers similar capabilities, but reduces the need for hosting? So I get it from a business standpoint, but hosting a python service is very easy now a days, so I don't see the point as a consumer.

[0]: https://openai.github.io/openai-agents-python/

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.

I think in time people will realize harness is essentially a more complicated .vimrc or .zshrc;

And yes, you can install gigantic plugins in those places - e.g. Codex; but the point is everyone will have exactly what they have customized towards. The more atomic a building block is, the easier it can be adapted into any kind of configuration.

I think the pain of selling a harness is if your target market understand what a harness is, then they can build it to exactly how they'd like it without much effort. If they don't, then the harness wouldn't be very useful to them in the first place.

Their showcase examples[0] link to GitHub but the links 404. Like this one for the Slack agent: https://github.com/OpenAI-Early-Access/agents-api-python-pre...

Guessing this an early release not quite ready for the public? Interesting that there's a 'OpenAI-Early-Access' GitHub user, though of course with no public repos. Presumably when its actually public they'll move the example agent repos to another GitHub user.

[0] https://developers.openai.com/showcase/agents-api-slack-bot

edit: Maybe someone from OAI saw my comment because the links are now fixed! And they point to a public repo under the openai org: https://github.com/openai/openai-cookbook/tree/main/examples...

It's interesting to me that the agents comparison page[0] doesn't list codex's app-server as an option.

I've found the app-server to be the most flexible, compared to the raw Responses API or Agents SDK.

Certainly seems like everyone is still figuring out the right interface here.

Also of note, since GPT-5.5 or so, Codex doesn't even use the Responses API as intended, but instead a "lite" version where they manage the context more manually (like sending the full transcript or using a custom web.run tool instead of the provided `web_search` tool).

If you follow the docs, it will lead you down a lot of well-intended functionality, but most of it is thrown away in their most successful harness.

[0]https://developers.openai.com/api/docs/guides/agents#compare...

I think this is an important direction: managed agents that control compute.

For those who are interested in a self-hosted version of the same concept, I've been working on something like this here: https://github.com/smartcomputer-ai/lightspeed

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

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.

Six months into customizing my own Claude Code harness, I've settled on assuming Anthropic and OpenAI will just handle all of it, except turning my own flows into skills.

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.

so this is basically a massive competitor to langgraph?

would love if it would be possible to allow suer and signing with the open ai account and use exiting subscription.

anyone knows how to do that and implement agent api with user actual account?

Pretty good abstraction. Setup your sandbox with dependencies, build plugins - agent works. Tested it with OpenAI for the last month while it was in preview

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.

Is this the same "sandbox" that the agents escaped to hack HuggingFace?

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.

This was sorely needed.

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

Hey guys AAAAAH WE ARE ABOUT TO DESTROY THE PLANET anyway heres an API reference so you can build durable codex harnesses OMG WE WILL KILL ALL HUMANS ITS GONNA HAPPEN GUYS let us know if you spot any issues IMMANTISE THE ESCHATON, ALL HAIL THE BASILISK ok guys?

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

Now you, too, can ripoff mathematicians worldwide!

[flagged]

[dead]

[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.

Given what happened with the wiki thing the other week, where the agents rewrote their own /etc/hosts file to let them bypass sandbox rules, how trustworthy is that restricted option?

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[dead]

[flagged]

[flagged]