openai-python v3.28.0 adds agent environment suspension and expiration

OpenAI’s Python SDK shipped v3.28.0 on October 9, and the release notes are almost aggressively thin. One feature line: “api: add agent environment suspension and expiration” (pull request #4046, commit 6aa25a9). Three chores: bump astral-sh/setup-uv from 10.1.0 to 10.2.0 (#4026), bump CodeQL init and analyze to 4.38.2 (#4025), and tighten the PyJWT security constraint to 2.14.0 (#3991). That is the whole changelog.

The dependency bumps are housekeeping. The PyJWT constraint is the kind of thing you do when a transitive auth library needs a floor, not a ceiling. The uv and CodeQL updates are CI hygiene. None of it deserves a story on its own.

The feature line does.

What “suspension and expiration” actually implies

Read the phrase carefully. An agent environment can now be suspended and can expire. Those are two different verbs and they describe two different lifecycle states. Suspension suggests a reversible pause: the environment still exists, its state is preserved, and something can resume it. Expiration suggests a hard stop: the environment is gone, or about to be, and anything holding a reference to it needs to handle that.

For anyone who has run agents in production, this is not an abstract API nicety. It is the difference between an agent that can be parked overnight and an agent that leaks. Every team building on the OpenAI platform has, at some point, written their own reaper: a cron job or a background worker that walks a table of active agent sessions and kills the ones nobody is talking to anymore. The reason is money. A suspended environment that nobody resumes is a suspended environment you are still paying for, whether in reserved capacity, in sandbox minutes, or in the storage that holds its filesystem.

OpenAI moving this into the API means the platform is willing to own that lifecycle. That is a meaningful shift in what the SDK is for.

The SDK is becoming a control plane

For most of the openai-python project’s life, the library was a thin client. You constructed a client, you called chat.completions.create, you got text back. The interesting decisions lived in your application code. The SDK’s job was to serialize a request and deserialize a response without getting in the way.

Agent environments change that. An environment is not a stateless call. It has a filesystem, it has running processes, it has network state, and it has a bill attached. Once you are managing something stateful, the SDK stops being a transport layer and starts being a control plane. Suspension and expiration are control-plane verbs. They belong in the same category as “create,” “list,” and “delete,” and their presence in the changelog tells you OpenAI expects developers to be running many of these things at once, for long enough that lifecycle management matters.

There is a second reading, and it is less flattering to the “just a thin client” story. If the API now exposes expiration, then environments can expire without the client asking. That means client code has to handle the case where an environment it believes is alive has been reaped by the server. Any team that has written retry logic against a service that silently drops idle sessions knows how much error-handling surface this adds. The feature is a convenience and a new failure mode in the same commit.

What is not in the release

The changelog does not say what the default expiration window is, whether suspension preserves the full filesystem or just a snapshot, whether there is a cost difference between a suspended and a running environment, or whether expiration is configurable per environment or fixed by the platform. None of that is in the release notes, and none of it is in the linked PR description as fetched. Those are the questions that determine whether this is a genuinely useful primitive or a thin wrapper around a timeout.

{/* TODO: verify default expiration window and whether suspension preserves filesystem state, per OpenAI API docs or the #4046 PR description */}

The PyJWT bump to 2.14.0 is worth a footnote for a different reason. Auth libraries in agent SDKs are load-bearing in a way they are not in ordinary REST clients, because the credential often has to be handed to a sandboxed process that is running model-generated code. Tightening a JWT constraint is routine, but it lands in a release where the headline feature is about giving that sandbox a defined lifespan. The two changes are unrelated in the diff and related in spirit.

Why this matters for builders

The practical takeaway is that if you are running agents on OpenAI’s platform, you should expect the platform to start managing their lifetime for you, and you should design your own code to assume environments can vanish. Do not hold a long-lived reference to an environment ID and assume it is valid. Do not assume a suspended environment resumes for free. Do not assume the default expiration matches your workload’s actual cadence.

OpenAI is not shipping a feature here so much as admitting that agent environments are long-lived, expensive, and need a reaper. The interesting question is who writes the reaper.

The larger pattern is that the agent stack is consolidating upward. A year ago, “agent infrastructure” meant a startup selling you a sandbox and a session manager. Now the model provider is shipping suspension and expiration in its own SDK, which means the sandbox vendor’s differentiation has to move somewhere else: better isolation, better observability, better pricing, or a workflow the provider will not bother to build. The thin-client era of model SDKs is ending, and the control-plane era is starting with a changelog entry most people will scroll past.

Watch the next few releases. If suspension and expiration are followed by listing, querying, and cost-attribution endpoints, OpenAI is building a full environment manager and the sandbox startups should be nervous. If the next release is three more dependency bumps, this was a single primitive and nothing more. The diff will tell you which.

For now, the honest read is that v3.28.0 is a one-line release with a two-paragraph implication, and the two paragraphs are the part that matters.