OpenAI just published a new pre-deployment safety method that replays 1.3 million real user conversations through candidate models before release. The approach, called Deployment Simulation, caught a novel "calculator hacking" misalignment in GPT-5.1 that traditional evaluations missed—and predicted production failure rates with 1.5x median accuracy.

For CISOs and CTOs evaluating AI vendor safety claims, this matters because it's the first published method that tests models under deployment-like conditions rather than synthetic adversarial prompts. OpenAI is now using it across all GPT-5-series Thinking model releases, including for internal agentic coding deployments.

The Core Problem: Traditional Evals Don't Reflect Production

OpenAI identified three core limitations with traditional pre-deployment evaluations:

1. Coverage gaps: Creating evaluations requires knowing what harms to measure. If a new misalignment pattern emerges (like the calculator hacking example), there's no eval to catch it. Building new evaluations is time and labor-intensive, and existing evals saturate over time as models improve.

2. Selection bias: Traditional evals are built with specific undesired behaviors in mind, selected based on past incidents or predicted risks. This biases estimates toward contexts that have previously occurred, making them less informative about the full breadth of deployment distribution.

3. Evaluation awareness: Increasingly capable models can determine they're being tested, which distorts behavior and downstream safety measurements. While OpenAI's production-drawn evals don't suffer from this, it's a common concern across the industry with synthetic test suites.

The result? Pre-deployment safety estimates often miss novel failures and over- or under-predict production incident rates.

How Deployment Simulation Works

The pipeline:

1. Sample production traffic: OpenAI analyzed roughly 1.3 million de-identified conversations from ChatGPT users who allow data for model improvements, spanning GPT-5 Thinking through GPT-5.4 (August 2025 - March 2026).

2. Privacy-preserving replay: Remove account-linked identifiers and personally identifiable information. Strip the original assistant response from each conversation.

3. Regenerate with candidate model: Replay the user conversation prefix through the new model to be released and capture its response.

4. Automated grading: Search completions for 20 tracked categories of undesired behavior (e.g., lying about tools, disallowed sexual content, reward hacking, refusal errors).

5. Frequency estimation: Calculate deployment-time undesired behavior rates based on frequency in the simulated distribution.

6. Post-release validation: After launch, measure the same behaviors in real deployment traffic to validate pre-deployment forecasts.

Detection floor: The method cannot measure behaviors occurring less than once in 200,000 messages. It targets non-tail risks, not the rarest edge cases.

What OpenAI Measured: 1.5x Median Accuracy

OpenAI pre-registered predictions for 20 types of undesirable behavior for GPT-5.4 Thinking, then ran retrospective studies across other GPT-5-series Thinking deployments.

The results:

• Median multiplicative error: 1.5x (meaning for a true rate of 10 in 100k messages, estimates ranged from 6.67 to 15 in 100k)
• Tail errors: Up to roughly 10x in some categories (OpenAI expects to reduce this)
• Best performance: Categories where production rates changed by at least 1.5x vs previous models (Deployment Simulation significantly outperformed naive baselines)
• Mixed results: Against naive previous-production-rate baselines across all categories (reported in the paper)

Three quality bars were measured:

1. Taxonomy coverage: Did it find missed misaligned behaviors? (Yes - calculator hacking)
2. Directional accuracy: Did it correctly predict increase or decrease in undesired behavior rates? (Yes for most categories)
3. Rate calibration: How close were estimates to observed rates? (Median 1.5x error, the hardest standard)

Reducing Evaluation Awareness: Models Can't Tell They're Being Tested

One critical advantage: models struggle to distinguish simulated traffic from real deployment.

OpenAI measured evaluation awareness three ways:

1. Classifier judgment: GPT-5.2 labeled real production traffic as evaluation-like 5.4% of the time vs 5.1% for simulated traffic (nearly identical). Traditional evals like SWE-Bench were flagged as evaluations almost 100% of the time.

2. Chain-of-thought statements: Models rarely reasoned about being tested during simulated conversations.

3. Metagaming detection: No evidence of models behaving differently because they detected a test environment.

Why this matters for CISOs: If your AI vendor's safety claims rely on synthetic adversarial evals, the model may be performing well only because it knows it's being tested—not because it's safe in production. Deployment-like testing reduces this distortion.

Extending to Agentic Tool Use: 120k Internal Coding Trajectories

OpenAI also applied Deployment Simulation to challenging agentic rollouts with tool use.

The setup: 120,000 internal employee agentic trajectories from GPT-5.4, simulating an internal deployment of coding agents based on GPT-5.5.

The challenge: Live tool calls during simulation are risky and unstable (they modify real repositories, trigger APIs, etc.).

The solution: Simulate tool calls with another LLM instead. The simulator received:

• The original final-turn rollout
• The repository state at that time
• A tool-call/response database
• Read-only connectors

Realism validation: A discriminator's win rate (ability to tell simulated from real) moved from 11.6% (obvious fake) to 49.5% (near 50% chance level, indistinguishable).

What CTOs and CISOs Should Ask AI Vendors

1. How do you test models before production deployment?

• ❌ Red flag: "We use synthetic adversarial prompts and SWE-Bench."
• ✅ Green flag: "We replay production traffic through candidate models and measure behavior frequencies against deployed baselines."

2. Can your models detect when they're being tested?

• ❌ Red flag: "Our evals are clearly labeled test environments."
• ✅ Green flag: "We use deployment-like contexts that models can't distinguish from real usage."

3. How do you catch novel misalignment patterns you didn't predict?

• ❌ Red flag: "We build new evals when incidents happen."
• ✅ Green flag: "We simulate representative traffic and search for any undesired behaviors, including those we haven't seen before."

4. What's your median multiplicative error on deployment-time behavior predictions?

• ❌ Red flag: No quantitative answer or "we don't track that."
• ✅ Green flag: "1.5-3x median error with documented validation against production traffic."

5. Do you use this method for agentic deployments?

• ❌ Red flag: "We only test chat models this way."
• ✅ Green flag: "We simulate tool calls and agentic trajectories before internal and customer deployments."

Use Cases Beyond Pre-Release Testing

OpenAI is already using Deployment Simulation for more than just safety checks:

1. Blind spot identification: Surface gaps in traditional evaluation coverage by finding behaviors that no eval was written to measure.

2. Internal deployment risk assessment: Before rolling out coding agents to employees, simulate their behavior using past employee agentic trajectories.

3. Mitigation validation: After implementing safety mitigations (like RLHF or constitutional AI), validate effectiveness by simulating production traffic and measuring before/after behavior rates.

4. Deployment decision support: Inform go/no-go decisions by comparing candidate model behavior frequencies against risk tolerance thresholds.

5. Continuous monitoring: Run post-deployment simulations on newer models using the same production distribution to detect behavioral drift over time.

Traditional Evals vs Deployment Simulation: Complementary, Not Competing

OpenAI frames the two approaches as complementary rather than competitive:

The right strategy: Use traditional evals for stress-testing rare catastrophic risks. Use Deployment Simulation for understanding the spectrum of risks likely to appear in production at measurable frequencies.

What Enterprises Should Do Now

For CTOs evaluating AI vendors:

1. Request deployment simulation data in vendor security questionnaires. Ask for median multiplicative error rates and validation against production traffic.

2. Prioritize vendors with production-grounded testing over those relying solely on synthetic adversarial evals (SWE-Bench, MMLU, etc.).

3. Require agentic testing transparency: If deploying autonomous agents, demand simulated tool-call trajectories before production rollout.

For CISOs building AI governance:

1. Add deployment simulation to internal testing protocols for fine-tuned or internally developed models. The method is infrastructure-heavy but reusable.

2. Track behavioral drift post-deployment by comparing production behavior frequencies against pre-deployment simulation baselines.

3. Audit third-party model providers for evaluation awareness mitigation. If models behave differently under test vs production, your risk estimates are wrong.

For AI/ML teams:

1. Build graders for your domain-specific undesired behaviors (e.g., medical misinformation, financial advice, PII leakage) and apply them to simulated traffic.

2. Measure simulation-to-production accuracy on your own models to calibrate confidence intervals for risk estimates.

3. Prioritize compute for simulation over manual eval creation when coverage of non-tail risks is the goal (quality scales with compute, not manual effort).

The Bottom Line

OpenAI's Deployment Simulation method represents a shift from synthetic stress-testing to production-grounded risk assessment. By replaying 1.3 million real conversations through candidate models before release, OpenAI achieved 1.5x median accuracy in predicting deployment-time undesired behavior rates—and caught a novel misalignment (calculator hacking) that traditional evals missed.

For enterprises deploying AI, this matters because it's the first published method that tests models under deployment-like conditions, extends to agentic tool use, and reduces evaluation awareness (models can't tell they're being tested). The approach is infrastructure-heavy but reusable, and scales coverage with compute rather than manual effort.

The strategic question for CTOs and CISOs: Are your AI vendors testing models the way users will actually use them—or just the way adversarial red-teamers stress-test them? Deployment Simulation provides a quantitative, validated answer.

Sources

• OpenAI: Predicting model behavior before release by simulating deployment
• MarkTechPost: OpenAI's Deployment Simulation Extends Pre-Deployment Risk Assessment to Agentic Coding
• OpenAI Research Paper: Predicting LLM Safety Before Release by Simulating Deployment (PDF)