The OpenAI Agents SDK put out three releases in five days, and the one that matters is the easiest to miss. Buried in v0.18.2 (July 11, 2026), between GPT-5.6 request controls and a stack of sandbox cleanup fixes, is a single line: feat: add hosted multi-agent beta support. That line is a strategic move dressed as a changelog entry.

What actually shipped in 0.18#

Five days, three versions, one direction of travel:

If you pin models explicitly, the GPT-5.6 default swap is a non-event. If you rely on defaults, your new agents now reach for GPT-5.6 — worth knowing before you diff a cost report and wonder what changed.

The headline: orchestration moves off your runway#

The Agents SDK has always given you two ways to compose agents: handoffs (agent A passes control to agent B) and agents-as-tools (agent A calls agent B like any other tool). Until now, the runtime for that fan-out was yours — your process, your server, your job to keep alive, retry, and observe.

"Hosted multi-agent" changes where that orchestration runs: against OpenAI-managed infrastructure instead of your own. For a solo builder or a small team, the pitch is obvious — one less runtime to stand up, monitor, and page yourself about at 2 a.m.

The appeal of hosted orchestration isn't that it's faster. It's that the pager stops being yours. That's worth real money to a team of one — and worth scrutiny before you hand over the part of your system that's hardest to get back.

Two honest caveats, because the changelog is one line and the docs haven't caught up:

  1. It's a beta. Capabilities, pricing, and limits are unsettled. Don't design a launch around undocumented behavior.
  2. It's coupling. Moving orchestration onto OpenAI's infra is a portability decision, not just an ops convenience. The exit cost is real and it compounds.

The decision it forces#

This is the same fork every agent builder eventually hits — managed runtime vs self-host — with a new, cheaper managed option on the OpenAI side of the table.

Lean hosted if: you're already OpenAI-native, your agents use OpenAI models end to end, and you'd rather ship features than operate an orchestration layer. The whole point is to delete infrastructure.

Stay self-hosted if any of these is true:

There's no universal winner here, and anyone selling you one is selling. Match the runtime to the constraint that actually binds you: ops time, model flexibility, or control. For most OpenAI-native teams doing straightforward fan-out, hosted multi-agent is now worth a spike. For anyone with a portability or multi-model requirement, the self-hosted stack is still the answer — the beta doesn't change your calculus, it just adds an option you can decline.

Don't skip the boring fixes#

The sandbox/PTY changes in 0.18.2 read as housekeeping, but they matter if you run the SDK's code-execution sandboxes. Owning the Daytona PTY worker tasks, Docker deferred cleanup, and Unix PTY fd close are all teardown-correctness fixes — the class of bug that doesn't crash cleanly but leaks under load and surfaces as flaky sandbox behavior three weeks later. If your agent runs generated code in a sandbox, take the upgrade for these alone. (On why the sandbox boundary is the part you least want leaking, see your container is not a sandbox.)

Bottom line#

0.18 is a small version bump carrying a big directional signal: OpenAI wants to run your agents' orchestration, not just answer their model calls. For the OpenAI-native team, that's a genuine offer worth trying the week it stabilizes. For everyone with a portability, on-prem, or multi-model requirement, it's a reminder to keep the orchestration layer somewhere you can still reach it. Upgrade for the sandbox fixes regardless; adopt hosted multi-agent deliberately, with the exit cost priced in.