OpenAI Python SDK v3.33.0 adds safety identifiers to image requests

OpenAI shipped openai-python v3.33.0 on October 16, and the changelog is two lines long. The first is the one that matters: “api: add safety identifiers to image requests and responses” (PR #4093). The second, “share Decisions cache breakpoint parameter type” (PR #4092), is housekeeping. A release this thin would normally pass without comment. This one shouldn’t, because the first line is not a feature so much as a seam opening in the API surface.

Here is what the release actually says. Image requests now carry safety identifiers, and image responses return them. That is the whole of the public description. There is no blog post, no parameter reference in the changelog, no explanation of what an identifier identifies or who assigns it. The commit is signed by the openai-sdks bot and timestamped 17 Oct 00:29 UTC against a 2026-10-16 release date. Everything past that is inference, and we should be careful about which parts are which.

What an identifier in the request buys OpenAI

The structural move is the interesting one. A safety identifier that appears in both the request and the response is a correlation key. It lets a caller tag an image generation with a stable handle, and it lets OpenAI hand the same handle back on the output. That is the plumbing you build when you want to trace a generated image to the request that produced it, across retries, across batches, across whatever the caller does downstream.

Compare the older pattern. A moderation filter sits between the prompt and the model, returns a pass or a block, and leaves the caller to log whatever it wants. The provider sees the request; the customer sees the verdict. Nobody shares a namespace. Once a safety identifier round-trips, both sides can talk about the same image by the same name. That is a precondition for anything resembling accountability: disputes, audits, abuse reports, law-enforcement requests, enterprise procurement reviews that ask “can you show us what happened.”

The obvious read is that OpenAI is building for the enterprise and compliance buyer, not the hobbyist. A startup generating cat pictures does not need a correlation key. A bank, a hospital, or a media company running image generation at volume does, because its own risk team will ask for one. The SDK change is the client-side half of a server-side contract that OpenAI has not yet documented in public.

The cache breakpoint line is not noise

The second commit, sharing the Decisions cache breakpoint parameter type, sounds like a type-hygiene chore and mostly is. But the word “Decisions” is doing work. It implies an internal or semi-public surface where cached decisions, presumably moderation or policy verdicts, are keyed by a breakpoint parameter. Sharing that type across the SDK means the same parameter shape now appears in more than one place. Read together with the safety identifier, a picture forms: OpenAI is standardizing how policy outcomes get keyed and reused.

We cannot verify what “Decisions” refers to, and the changelog does not say. Treat the connection as a hypothesis, not a fact. What we can say is that a cache breakpoint type and a request/response identifier are the two halves of a system that wants to remember a verdict and attach it to an artifact. That is a moderation architecture, not a moderation checkbox.

Why this lands in the SDK and not a blog post

OpenAI has a habit of shipping policy through the client libraries. The Python SDK is the most-installed surface the company controls, and a parameter added there reaches every integrator on the next pip install -U openai. A blog post gets read by the press. A parameter gets read by every codebase that calls the API. When the company wants behavior to change quietly, the SDK is the lever.

That is a defensible engineering choice and a frustrating editorial one. Developers integrating image generation this week will see a new field in their type stubs and have to guess at its semantics from the name. The docstring, if there is one, is not in the release notes. Anyone building a compliance story around “we tag every generation” needs to know whether the identifier is caller-supplied, provider-assigned, or both, and the changelog does not say. {/* TODO: confirm whether safety identifiers are caller-supplied, provider-assigned, or both, and link the API reference */}

The honest position is that v3.33.0 is a small release pointing at a large unannounced design. The identifier is real. Its meaning is not yet public.

A parameter in the SDK reaches more integrators than any blog post ever will. That is exactly why OpenAI ships policy there.

What it means for builders

If you run image generation in production, the practical advice is unglamorous: pin your SDK version, read the diff for #4093 before you upgrade, and decide now whether you want to populate the new field. If the identifier is optional, leaving it empty keeps your integration identical to yesterday’s. If it becomes required, an empty field is a broken request. The release does not tell you which, which is itself the finding.

For the broader industry, the direction is clear enough. The big labs are converging on the same posture: generation and its safety record travel together, keyed by a shared handle, so the provider can answer questions about an output months later. Anthropic, Google, and Meta all face the same procurement pressure. Expect the same round-trip identifier to show up in their SDKs, under different names, within a couple of release cycles. The mechanism is boring. The consequence is that “we don’t keep records of individual generations” stops being a credible answer to a regulator.

The thing to watch is the API reference page for image generation, not the changelog. When OpenAI documents what a safety identifier is and who sets it, the policy behind PR #4093 becomes legible. Until then, v3.33.0 is a two-line release with a one-line tell, and the tell is that the identifier exists at all.