OpenAI announced last week that a new reasoning model called Astra can find zero-day vulnerabilities and execute exploit chains against real systems. The blog post says it outperforms previous models on cybersecurity benchmarks, can autonomously discover and exploit software flaws, and has been placed under enhanced safety controls including restricted access and internal usage pauses during red-teaming. Good. That is the correct response to a capability jump this sharp.
Here is what my API client sees when it calls that model: a model ID string, a token count, a finish reason, and the generated text. The response does not carry a flag that says this model can break into systems. It does not include a capability tier, a risk enum, or a header I can check before I let the output leave the sandboxed layer. The safety work is happening on OpenAI's side. The capability signal is not making it to mine.
The model ID changes but the contract does not
Production systems that call LLMs do not hard-code model names. They use fallback lists, rotation logic, and cost tiers. estimate.pro routes between three providers depending on load and rate limits. When a new model appears in the rotation my retry logic does not know it crossed a capability threshold that three other models on the list have not. The model ID changed; the risk profile changed; the error-handling strategy should probably change. But the API does not surface that so my code does not react to it.
The construction ERP does not know what tier it is calling
The 120-route construction ERP at coenconstruction.com calls OpenAI to summarize site notes, extract line items from PDFs, and generate the first draft of change-order descriptions. The prompts are narrow and the review gates are hard: a human superintendent reads every output before it goes into the database or out to a client. But the model doing the drafting just became capable of something my safeguards were not designed around.
If Astra ends up in the default rotation maybe I update to the newest model ID because the deprecation notice says the old one sunsets in sixty days and nothing in my guardrail layer knows the new model can do offensive security research. The capability shifted under the call stack. The log shows the same request shape, the same token count, the same finish reason, and a model name that differs by a date stamp.
I have monitoring on latency, on token cost, on error rates, on output length. I do not have monitoring on can this model execute an exploit chain. Because that is not in the API contract and I cannot gate what I cannot see.
Deprecation notices do not mention capability upgrades
Here is the other edge: if I do not upgrade and the old model gets deprecated I lose capability I was depending on. If I do upgrade I gain capability I was not expecting and my security posture has not accounted for. Three model IDs died in one release cycle earlier this month and my ERP did not notice because I had fallback routing. That fallback works for availability. It does not work for capability boundaries.
A deprecation notice tells me the old ID stops working. It does not tell me the new ID can do things the old one could not and that some of those things are considered critical-tier cybersecurity risks by the vendor who built it. The API shape is forward-compatible. The safety profile is not.
The temperature parameter stays the same
If I want the model to be more or less creative I set temperature. If I want it to avoid certain content I can try a system prompt or use the moderation endpoint. But if I want to programmatically verify that the model I am about to call cannot autonomously find and exploit zero-days there is no parameter for that, no header to check, no capability manifest to parse.
The safety work is happening. OpenAI paused internal use, added sandboxing, required hardware security keys for high-access accounts, and implemented monitoring across agentic applications. All of that is good, necessary, and completely invisible to my API client.
The model can find zero-days. My request sees a model ID and a 200 OK. The gap between those two facts is every production system that routes between providers.
I am not asking for OpenAI to publish exploits. I am asking for the API to carry a capability signal so that code written to call these models can make decisions that match the risk. A boolean. An enum. A header. Something. Right now the capability threshold is documented in a blog post and a framework PDF and my error-handling middleware does not read blog posts. It reads JSON. And the JSON does not know that the model just learned to break in.