From model to agent: Equipping the Responses API with a computer environment

OpenAI has quietly been turning the Responses API from a chat endpoint into something closer to an operating system for agents. The latest piece is a shell tool paired with hosted containers, which lets a model actually execute commands, write and read files, and hold onto state across a session instead of just spitting out text and hoping a developer wires up the rest.

The pitch here is pragmatic. Building agents that do real work, not just answer questions, means giving them a place to operate. Up until now, most teams rolling their own agent stacks had to build that environment themselves: spin up a container, expose a shell, manage security boundaries, handle cleanup. OpenAI is folding that entire chore into the API, so a developer calls Responses, the model decides it needs to run a script or inspect a file, and the shell tool executes it inside a container OpenAI hosts and secures.

What's notable is the emphasis on running this at scale without turning every session into a security incident. Hosted containers isolate execution, and the runtime is built to persist across multiple turns, so an agent working through a multi-step task can come back to files it created three steps ago rather than starting from a blank slate every call. That statefulness is the part that's been missing from a lot of agent demos that look impressive for one turn and fall apart the moment context needs to carry forward.

This also signals where OpenAI wants developers building. Rather than treating the model as a component you glue into your own infrastructure, the company is positioning the API itself as the infrastructure: model, tools, filesystem, and execution environment bundled together. It's a bet that most builders would rather rent a fully equipped agent runtime than assemble one from Docker files and shell scripts.

The obvious tradeoff is lock-in. The more of the stack that lives inside OpenAI's hosted containers, the harder it becomes to port an agent elsewhere or swap in a different model mid-project. That's a fine deal for teams that want to ship fast, less so for anyone trying to keep options open.