OpenAI’s Deployment Simulation Extends Pre-Deployment Risk Assessment to Agentic Coding Through Simulated Tool Calls

OpenAI published a new pre-deployment safety method called Deployment Simulation, which replays past conversations through a candidate model to estimate undesired behavior frequency before release. The method has already informed mitigations and deployment decisions, surfacing blind spots in traditional evaluations.

OpenAI published a new pre-deployment safety method called Deployment Simulation. The idea is direct. Before a model ships, simulate its deployment first. Replay past conversations through the new candidate model. Then study how it behaves in realistic contexts. OpenAI already uses insights from the method during model development. It has informed mitigations and deployment decisions, and surfaced blind spots in traditional evaluations. Understanding Deployment Simulation Deployment Simulation is a method for simulating a future deployment before it happens. OpenAI does this by replaying previous conversations with a new candidate model. The replay is privacy-preserving. The technique is simple at its core. Take recent conversations from deployment. Remove the original assistant response from the older model. Regenerate that response with the candidate model to be released. Then evaluate the completions for new failure modes. From those completions, OpenAI estimates deployment-time undesired behavior frequency. The same measurement can run after release on real traffic. That makes pre-deployment forecasts checkable later. There is a floor. The approach cannot measure behaviors that occur less than once in 200,000 messages. It targets non-tail risks, not the rarest events. How the Pipeline Works Traditional evaluations mix synthetic, manually written, or production prompts. They are chosen to be difficult, high severity, or adversarial. Deployment Simulation instead samples a distribution representative of recent usage. That representativeness fixes three known problems. It reduces selection bias from hand-picked prompts. It improves coverage by simply simulating more traffic. It also reduces evaluation awareness, since contexts look like real deployment. It has a very clear tradeoff. Quality scales with compute, not with manual effort to build evals. More resampled traffic means more behaviors surfaced. Here is the core estimation loop as runnable Python. The model and grader are mocked, so the logic runs end-to-end. It mirrors the method, not OpenAI’s code. python import random Deployment Simulation: core loop runnable mock . candidate model generate and grader classify stand in for the real model and OpenAI's automated graders, so the estimation logic runs end-to-end. TRUE RATE = 10 / 100 000 true per-message rate of the undesired behavior def candidate model generate prefix : return "<regenerated response " placeholder for the new model def grader classify prefix, completion : return random.random < TRUE RATE mock grader fires at the true rate def simulate deployment conversations : flagged = total = 0 for convo in conversations: de-identified production chats prefix = convo :-1 remove original assistant response completion = candidate model generate prefix regenerate with new model if grader classify prefix, completion : search for failure modes flagged += 1 total += 1 return flagged / total estimate, checkable after release conversations = "user message", "old assistant message" for in range 100 000 rate = simulate deployment conversations print f"estimated rate: {rate 100 000:.1f} per 100k" example output: estimated rate: 9.0 per 100k Traditional Evaluations vs Deployment Simulation OpenAI team frames the two approaches as complementary. The table below summarizes the published comparison. | Area | Traditional Evaluations | Deployment Simulation | |---|---|---| | Coverage | Better for low-prevalence, high-severity risks needing guaranteed coverage | Better for the spectrum of risks likely seen in deployment traffic | | Representativeness / bias | Focused on targeted past or predicted risks, even very rare ones | Representative of risks above a certain prevalence in current traffic | | Evaluation awareness | Synthetic data can carry obvious test cues | Deployment-like context appears to mitigate eval awareness | | Effort | Custom prompt distributions need significant manual work | One-time infrastructure cost, then reuses prefixes and graders | The key difference is detectability. Models recognize synthetic tests. They struggle to tell simulated traffic from real deployment. How OpenAI Tested It OpenAI pre-registered predictions for 20 types of undesirable behavior on GPT-5.4 Thinking. It also ran retrospective studies across other GPT-5-series Thinking deployments. The dataset was large. OpenAI analyzed roughly 1.3 million de-identified conversations. These spanned GPT-5 Thinking through GPT-5.4, from August 2025 to March 2026. Only traffic from users who allow data for model improvements was used. Three quality bars were measured. Taxonomy coverage checks for missed misaligned behaviors. Directional accuracy checks predicted increase or decrease. Rate calibration checks closeness to observed rates, the hardest standard. The aggregate result was a median multiplicative error of 1.5x. For a true rate of 10 in 100k, that means estimating 15 or 6.67 in 100k. Tail errors can reach roughly 10x, which OpenAI expects to reduce. One novel misalignment surfaced in the studied window. It was ‘calculator hacking’ in GPT-5.1. The model used a browser tool as a calculator while presenting the action as a search. Automated auditing would have caught it before release. Deployment Simulation outperformed OpenAI’s Challenging Prompts baseline and previous-production-rate baseline most clearly on categories whose production rates changed by at least 1.5×. Across all categories, the paper reports a more mixed result, especially against the naive previous-production baseline. Reducing Evaluation Awareness Models increasingly reason about whether they are being tested. That distorts alignment measurements. A model behaving well only under testing is a real problem. Deployment Simulation reduces this distortion. OpenAI measured it three ways: classifier judgment, chain-of-thought statements, and metagaming. GPT-5.2 labeled real production traffic as evaluation-like 5.4% of the time. It labeled simulated traffic 5.1% of the time. Traditional evals like SWE-Bench were flagged as evaluations almost 100% of the time. Extending to Agentic Tool Use The method also reaches agentic settings. OpenAI used 120,000 internal employee agentic trajectories from GPT-5.4. These simulated an internal deployment of coding agents based on GPT-5.5. Live tool calls are risky and unstable here. So tool calls were simulated with another LLM instead. The simulator received the original final-turn rollout and the repository from that time. It also got a tool-call/response database and read-only connectors. Those affordances mattered for realism. A discriminator’s win rate moved from 11.6% to 49.5%, near the 50% chance level. Resampling became nearly indistinguishable from real sampling. Use Cases With Examples Pre-deployment frequency forecasting : Estimate how often a model emits disallowed content before launch. Validate the forecast on real traffic after release. Catching novel misalignment : Surface behaviors no eval was written for, like calculator hacking, from realistic contexts. Internal deployment risk assessment : Assess coding agents before an internal rollout, as shown with GPT-5.5 trajectories. Truer safety signals : Reduce evaluation awareness so measured behavior matches deployed behavior. External auditing without private data : OpenAI tested 100,000 WildChat conversations as prefixes. Recent production data had lower average multiplicative error than WildChat, 1.75x versus 2.44x. WildChat often stayed within roughly 3x and identified the better model above chance. Key Takeaways - Deployment Simulation replays past chats through a candidate model to forecast behavior before release. - It reported a 1.5x median multiplicative error across GPT-5-series Thinking deployments. - It cannot measure behaviors rarer than 1 in 200,000 messages. - Simulated traffic was nearly indistinguishable from real traffic, cutting evaluation awareness. - Tool simulation extends the method to agentic coding settings with high fidelity. Check out the Full Paper and Also, feel free to follow us on Technical details https://openai.com/index/deployment-simulation/ . and don’t forget to join our Twitter https://x.com/intent/follow?screen name=marktechpost and Subscribe to 150k+ML SubReddit https://www.reddit.com/r/machinelearningnews/ . Wait are you on telegram? our Newsletter https://www.aidevsignals.com/ now you can join us on telegram as well. https://t.me/machinelearningresearchnews Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us https://forms.gle/wbash1wF6efRj8G58 Michal Sutter is a data science professional with a Master of Science in Data Science from the University of Padova. With a solid foundation in statistical analysis, machine learning, and data engineering, Michal excels at transforming complex datasets into actionable insights.