1 Introduction↩︎

Pre-deployment evaluations used across the industry generally consist of a mix of synthetic, manually written, or production prompts intentionally selected to be difficult, high severity, or adversarial. These evaluations generally serve two intertwined goals: assessing how the model responds when stress-tested in situations that have a very small chance of occurring in production traffic, and helping characterize model misbehaviors, including novel undesired behaviors and their deployment-time frequencies.

While traditional evaluations remain crucial for stress-testing and capturing tail risks, we show how deployment simulations can be a significant improvement over traditional evaluations in pursuit of the second goal by sidestepping three central limitations of traditional evaluations. First, pre-deployment evaluation suites may be too narrow: they may not sufficiently cover the full breadth of uses that could induce misbehavior with a new model. Second, current evaluations often measure behavior on prompts drawn from a deliberately distorted slice of possible inputs: handcrafted prompts, synthetic scenarios, or adversarial examples selected because they are likely to elicit failures. Finally, models sometimes infer that they are being evaluated, leading them to behave differently, which may distort our risk assessments [1]. As a result of these three factors, traditional evaluation results may not be well-correlated with model behavior in deployment. They may also fail to surface new misbehaviors introduced by the candidate model, leaving developers surprised by safety failures only once it has already been deployed.

By simulating the candidate model’s deployment as realistically as possible, we aim to enable pre-deployment risk assessment that alleviates concerns about coverage, unrepresentativeness, and evaluation awareness. The method is simple: starting from de-identified production conversations from a recent deployment, we hold fixed the initial conversation prefix—which may include multiple user and assistant turns—and then resample the next model response using the “candidate model” to be released.

Deployment simulation avoids the unrepresentativeness problem of traditional evaluations: because we use a representative distribution of production conversations, the simulated conversations are also representative of the contexts in which we expect the model to operate at deployment time. This way, deployment simulation largely decomposes coverage into a sample-size problem (that is, simulating enough data points) and an auditing problem (that is, having a method with sufficient sensitivity to find misbehavior of interest in the simulated data). Finally, by evaluating models on production contexts, we side-step most evaluation awareness cues.

In practice, we use the simulated conversations in two ways before deployment: first, to identify novel forms of misalignment introduced by the candidate model; and second, to estimate deployment-time misbehavior prevalence. The incidence of a given misbehavior in the simulated distribution can be treated directly as a prediction of deployment-time prevalence. Using the same measurement procedure after release also allows these predictions to be validated against the observed realized rates in production after release.

We show that deployment simulation generally outperforms traditional evaluations (3.1), demonstrate its benefits for evaluation awareness (3.2), and show promise in addressing the challenges of resampling agentic settings with heavy tool use (3.3). We also investigate whether public chat data can make deployment-grounded auditing more accessible to external researchers (3.4). Our findings suggest that deployment simulation can support accountable pre-deployment risk assessment: it enables developers to make predictions not only about what might go wrong, but also about how often we expect each known misbehavior to occur in real usage. Sharing such predictions and validations in system cards can also make risk assessments more transparent to external stakeholders.

Our main findings are:

• Simulated deployments improve forecasts of deployment misbehavior. Across GPT-5-series Thinking model releases, our simulated deployments were substantially more informative about deployment-time misbehavior changes and rates than current pre-deployment evaluations.

• Simulated deployments can surface novel misalignments before release. Simulated outputs can be audited to find novel forms of misalignment. We show that this audit would have surfaced “calculator hacking” (a new form of reward hacking in GPT-5.1) prior to deployment.

• Simulated deployments substantially reduce evaluation awareness. Deployment simulation with real prompts induces far lower evaluation-awareness than traditional evaluations, with rates similar to real production traffic—which is reassuring for the validity of our risk estimates.

• Realistic tool use simulation is a challenge, but can be mitigated even in agentic settings. Realistic simulation is difficult when tool use depends on external state. Tool simulation shows promise in addressing this challenge, even for simulating internal agentic deployments.

• Our approach also remains informative with public chat datasets, enabling external auditing. Public chat datasets such as WildChat provide a public analogue to production data. We found that WildChat yielded weaker—but still informative—pre-deployment risk predictions. This can empower external parties to perform independent audits across providers.

2 Method↩︎

Below, we describe how to simulate the deployment of a candidate model \(X\) using production data from deployed model \(Y\). Following prior work that treats changes to deployed learning systems as counterfactual interventions [2], we hold historical context fixed while changing the model that produces the next response.

Step 1: Sample representative production prefixes. From recent production conversations generated with model \(Y\), we uniformly sample eligible user turns from the product context whose deployment we aim to simulate (for example, ChatGPT or Codex). For each sampled turn, we retain the conversation prefix through that user message and remove all later turns.

Step 2: Generate a target-model completion in the simulated environment. We generate the next assistant response for each prefix using candidate model \(X\) in a production-like environment.Let \(D_Y\) denote the distribution of sampled prefixes \(h\) from deployment \(Y\). We write \(X\rightarrow Y\) for the simulated distribution obtained by sampling \(h \sim D_Y\) and generating the next response with \(X\); throughout, the arrow runs from the completion model to the source of the prefixes. For category \(c\), let \(r_c(X\rightarrow Y)\) denote its prevalence in this distribution and \(r_c(X)\) its realized prevalence when \(X\) is deployed. This is a single-turn approximation of the target deployment: it captures the target model’s response to realistic user contexts, but may not fully reproduce tool state or capture multi-turn adaptation effects between the user and the model. In preliminary experiments, we did not find meaningful improvements to our estimates by simulating multiple turns.

Step 3: Audit the simulated deployment for new misbehaviors. We run an automated auditing pipeline over the simulated deployment \(X \rightarrow Y\), with the aim of identifying previously unseen forms of misalignment introduced by model \(X\).

Step 4: Produce pre-release prevalence estimates. We update the taxonomy of previously known misbehavior types with any new types of interest surfaced by the auditing step, then freeze a measurement procedure for each (in our case, a grader prompt). For each tracked category \(c\), we then measure \(r_c(X \rightarrow Y)\) as our estimate of \(r_c(X)\). Throughout, reported rates refer to outputs of these fixed measurement procedures, which have been validated but may be imperfect. The decision to release the model can be informed by these estimates.

Step 5: Validate and report estimate quality after deployment. Measuring and reporting the quality of our predictions is an integral step of the pipeline. If the model is released, we rerun the same fixed measurement stack after release on production traffic from model \(X\). This post-release rerun evaluates the pipeline along three axes:

1. Taxonomy coverage: did post-release auditing surface any important misbehavior class missing from the frozen taxonomy?

2. Directional accuracy: for known behaviors, did resampling correctly predict whether deployment prevalence would increase or decrease?

3. Rate calibration: how close were the predicted and realized prevalences? Calibration is the most ambitious measure of success, as strong calibration would directly provide directional tracking.

3 Experiments↩︎

We evaluate deployment simulation across four sets of experiments. First, we assess how well it forecasts post-deployment misbehavior rates across GPT-5-series launches, including a GPT-5.4 study with outcome-blinded predictions (3.1). As part of this evaluation, we diagnose where our method fails and decompose its prediction errors into their constituent sources. Second, we test the hypothesis that deployment simulation induces less evaluation awareness than classical, handcrafted evaluations (3.2). Third, we test whether we can improve the realism of deployment simulation in an especially challenging setting: agentic work with heavy tool use that depends on external state which requires its simulation (3.3). Finally, we test whether external evaluators can apply our methodology using public datasets (3.4).

Production traffic distribution and user privacy. With the exception of 3.3, our experiments use de-identified ChatGPT traffic from GPT-5-series deployments from users who allow their data to be used for model improvements. We exclude Temporary Chats,² employee traffic, ChatGPT Enterprise, API, and Codex traffic. Due to technical limitations in our current processing pipeline, we also exclude conversations with file attachments. Because of these filtering steps, our production estimates of misbehavior are most representative of this filtered slice of production traffic. Before any use in our evaluations, account-linked identifiers and identifiable information were automatically removed. Only aggregate rates and statistical comparisons are reported in this work. In total, we analyze approximately 1.3 million conversations from four production deployments spanning August 2025 to March 2026 (5).

We only consider Thinking models of the GPT-5-series, and so may omit “Thinking” when referring to model names.

3.1 Forecasting GPT-5-series Deployment Misbehavior↩︎

3.1.1 Setup and Hypotheses↩︎

Models and misbehavior categories. We evaluated the pipeline across 20 categories of deployment-time misbehavior for GPT-5.4. The predictions used in the primary analysis were frozen before we inspected the held-out production measurements, although they incorporated a pipeline update made after GPT-5.4 was released. These categories fall into two classes: disallowed-content outputs (e.g.sexual content), and misaligned actions (e.g.deceiving the user about tool use). For the full list, see 12. We also conducted retrospective studies of previous GPT-5-series Thinking model releases using the same categories to further validate our pipeline. We obtained all misbehavior labels by applying GPT-5 Thinking graders at high reasoning effort on simulated or real deployment conversations. Each grader labeled only the final assistant turn for the relevant misbehavior.

Baselines. Our Challenging-Prompts baseline uses the evaluations of that name reported in OpenAI system cards. These evaluations consist of production prompts that previously induced model misbehavior.³ We extract directional predictions by comparing evaluation results across models; for example, checking whether GPT-5.2 is expected to produce sexual disallowed content more or less than GPT-5.1. We also extract GPT-5.4 point estimates from these evaluations. For each category, we fit a log-log linear relationship between evaluation results and realized production rates for prior GPT-5-series models, then use that fit to predict the GPT-5.4 production rate; see 6 for more details. The Challenging Prompts baseline is defined only for disallowed-content categories. To cover all tracked categories, we additionally consider a previous-rate baseline, which naively predicts that the incidence of each category will remain unchanged from the preceding model’s deployment.

Preregistered hypotheses. We preregistered three hypotheses (see 6 for details):

1. H1: Deployment simulation forecasts are more accurate than the previous-rate baseline.

2. H2: Deployment simulation forecasts are more accurate than the Challenging Prompts baseline.

3. H3: No novel misaligned behavior occurs in ChatGPT traffic at or above the preregistered detectable-incidence threshold (\(\approx 0.003\%\)).

Unless otherwise stated, our descriptive analyses, figures, and category-level comparisons use a symmetric multiplicative factor, defined for two rates \(r_1\) and \(r_2\) as \(\max(\frac{r_1}{r_2}, \frac{r_2}{r_1})\). Thus, rates that differ by a factor of two have a symmetric multiplicative factor of \(2\times\), regardless of which is larger. When comparing a forecast with a realized rate, we call this quantity symmetric multiplicative error; when comparing rates across deployments, we use it as the magnitude of the multiplicative change. To keep the ratio finite for zero-count categories, we apply Jeffreys smoothing, \((K+\tfrac{1}{2})/(N+1)\), to all count-derived forecasts, baselines, and realized rates before calculating it. The preregistered H1 and H2 hypothesis tests are the exception: they use mean per-category binomial negative log-likelihood (NLL) scored against the raw realized outcome counts. Accordingly, all H1 and H2 \(p\)-values refer to NLL, while factor errors and category win counts are descriptive. See 6 for further discussion of this evaluation philosophy and the preregistered scoring rules.

3.1.2 Results↩︎

Deployment simulation better predicts whether measured misbehavior will increase or decrease. For deployment decisions, the simplest question is whether a tracked misbehavior is likely to become more or less common after release. For misbehaviors whose production incidence changed by at least \(1.5\times\), simulated deployments predict the direction more accurately than the Challenging Prompts baseline on the comparable subset (92% vs.%) and remain accurate across all tracked categories (84%; 3, left). Thus, without requiring a separately designed and curated evaluation set for each failure mode, deployment simulation better predicts changes across many behaviors using a uniform sample of real traffic.

Quality of frequency estimates obtained via deployment simulation. In contrast with traditional evaluations, simulated deployments can be used to predict the incidence rate of misbehavior in deployment directly. Across 60 category–deployment pairs from retrospective analyses of GPT-5.1 and GPT-5.2 and the outcome-blinded GPT-5.4 forecast, predicted and realized production rates had a strong Pearson correlation on the log scale (\(r=0.91\); 3, right).

Deployment simulation outperformed Challenging-Prompts rate estimates for 6 of 9 disallowed-content categories. The one-sided sign-flip test on mean per-category NLL gave \(p=0.0469\) (4). The naive previous-rate baseline was stronger: deployment simulation had lower per-category NLL for 11 of 20 categories, but its mean NLL was not lower overall, providing no support for H1 (\(p=0.6567\)). These results can be largely explained by two factors: GPT-5.4 misbehaves at frequencies similar to GPT-5.2 for many categories, and our deployment simulation pipeline has some fixed bias term that primarily affects categories whose rates did not change substantially. Indeed, for categories whose production rates changed by less than \(1.5\times\), deployment simulation had lower symmetric multiplicative error than the Challenging Prompts baseline for 2/5 categories and the previous-production baseline for 3/9. For categories whose production rates changed by at least \(1.5\times\), the corresponding win rates were instead 4/4 and 8/11.

The largest prediction error for GPT-5.4 was for calculator hacking, predicted to be \(21\times\) less frequent for GPT-5.4 than its eventual realized rate (1.7 vs. 35.2 per 100k; see 8). Errors of this size limit the reliance one can place on our pipeline in its current form. That said, this error, like most of our largest errors, appears to be due primarily to resampling fidelity, as shown in 12 and discussed below.

Resampling inconsistencies affect estimates more than shifts in the prefix distribution. Forecast error can arise from two sources: shifts between the historical and target prefix distributions, and mismatches between the resampling and production environments. To isolate their contributions, we report symmetric multiplicative error for three comparisons in 5:

• Environment fidelity error: comparing the \(5.4\rightarrow5.4\) resampled rate with the GPT-5.4 production rate isolates differences between the resampling and production environments, such as sampling-pipeline mismatches or poor fidelity of stateful tools.

• Prefix fidelity error: comparing the \(5.4\rightarrow5.2\) and \(5.4\rightarrow5.4\) resampled rates holds the completion model and resampling environment fixed, isolating the effect of using off-policy prefixes.

• Full forecast error: comparing the \(5.4\rightarrow5.2\) resampled rate with the GPT-5.4 production rate gives the error observed in practice.

Errors due to the resampling environment and prefix-distribution shift can point in opposite directions and partially cancel. Somewhat surprisingly, tail errors are dominated by the resampling environment rather than by prefix-distribution shift: with perfect environment fidelity, our largest remaining prediction error would have been \(\sim2.5\times\). This suggests that many of the largest errors arise from potentially addressable engineering limitations.

Prefix-distribution error can be reduced by using the most recent production data. The best time window from which to sample production data is not obvious. Prefixes from a large historical window may provide broader coverage and greater robustness to seasonality, whereas the most recent data may better represent the traffic encountered at deployment time. We took the former approach in our analyses, but later investigation suggested that the latter may have been preferable. In [fig:weekly-and-variation,fig:appendix-weekly-common-weeks], we compare changes in misbehavior rates within each deployment and across adjacent deployments after excluding weeks with less than half the median weekly sample size. Across categories, within-deployment variation is often larger than the change associated with the model deployment itself. However, this analysis is confounded by system-prompt updates and other deployment-time adjustments. Taken at face value, the results suggest that restricting prefixes to the most recent production traffic may reduce deployment-prediction error, especially error due to prefix-distribution shift.

Deployment simulation was sufficient for identifying the one novel ChatGPT misalignment in the deployment window we study: calculator hacking. Across the GPT-5-series deployments, the only significant novel misalignment in ChatGPT traffic that we are aware of was calculator hacking, in which the model uses the browser tool as a calculator while behaving as if it had performed a search. This behavior appeared with GPT-5.1, and our automated audit of a simulated deployment would have surfaced it before release. For GPT-5.4, the audit of production conversations surfaced no novel misbehavior type, consistent with H3. The retrospective detection of calculator hacking provides limited positive evidence about sensitivity, based on one relatively prevalent behavior, although we view it as an encouraging initial result.

3.2 Evaluation Awareness in Simulated Deployments vs Traditional Evaluations↩︎

If a model is aware that it is being evaluated, this awareness might affect its behavior and distort our safety measurements. This is especially concerning because even small, subtle mismatches between evaluation and production environments can produce evaluation awareness. In this subsection, we test the hypothesis that simulated deployments reduce evaluation awareness relative to traditional, handcrafted evaluations. We use three distinct metrics: evaluation-detection capability, verbalized alignment-evaluation awareness, and metagaming. On the two metrics applicable across the full evaluation suite—evaluation detection and metagaming—traditional evaluations displayed substantially more evaluation awareness than production traffic (7), echoing results reported elsewhere [1], [3]. Verbalized alignment-evaluation awareness was also much more common in alignment evaluations than in production. In contrast, simulated-deployment rates were much closer to production across all three metrics.

Setup. GPT-5.2 was the policy model that generated the trajectories in all three conditions. Separate GPT-5.2 calls, independent from trajectory generation, served as evaluation awareness detectors. For evaluation-detection capability, a detector received the full trajectory in a fresh context window and classified it as organic production traffic or an evaluation [1]. For verbalized alignment-evaluation awareness, a chain-of-thought monitor scored whether the policy explicitly reasoned that it was being evaluated [3]. A separate metagaming monitor scored reasoning about the oversight process [4]. We applied these measurements to GPT-5.2 production conversations, simulated deployment trajectories (\(5.2 \rightarrow 5.2\)), and a collection of traditional evaluations:

1. Scheming-propensity evaluations, a suite of alignment evaluations introduced in prior work [3];

2. Reward-hacking evaluations introduced in prior work [5], [6], including impossible coding and interview-style tasks;

3. SWE-Bench [7], a public agentic capability evaluation;

4. AIME [8], a public question-answering evaluation;

5. OpenAI-Proof QA, a private question-answering evaluation used in OpenAI system cards [9];

6. MonorepoBench, a private agentic coding evaluation used in OpenAI system cards [9].

This collection mixes private and public evaluations, alignment and capability assessments, and question-answering and agentic tasks. We included this range to reduce confounding from familiarity with a particular evaluation or from the need to use tools. We ran the evaluations using configurations resembling our system-card pre-deployment suite.

Traditional evaluations are much easier to identify and show much more metagaming than production traffic. When asked directly, the evaluation detector classified 98.9–100% of trajectories from every traditional-evaluation category as evaluations, compared with 5.38% of production conversations—a difference of approximately 18–19\(\times\). This pattern held for alignment and capability evaluations, public and private datasets, and question-answering and agentic tasks. Inspecting the detector’s chain of thought suggested that its judgments were driven largely by obvious format cues, such as exam-style questions or requests to produce a solution.py file. Metagaming also occurred more often in every aggregate traditional-evaluation group shown in 7: rates ranged from 0.84% to 76.0%, compared with 0.12% in production traffic, a difference of approximately 7–630\(\times\). Anecdotally, evaluation-detection false positives in production largely involve users informally testing model capabilities or requesting assistance with school assignments.

Traditional alignment evaluations show evaluation-awareness signals roughly two to three orders of magnitude more often than production traffic. Across the two aggregate alignment-evaluation groups in 7, verbalized alignment-evaluation awareness occurred in 1.20–26.80% of samples, compared with 0.018% of production traffic—approximately 67–1,489\(\times\) more often. Metagaming occurred in 61.87–76.03% of alignment-evaluation samples, compared with 0.12% of production traffic—approximately 516–634\(\times\) more often. As expected, we did not detect verbalized alignment-evaluation awareness in our capability evaluations. In alignment evaluations, verbalized awareness and metagaming were also more often judged to affect the model’s decisions than in simulated deployments (15).

Evaluation-awareness rates in simulated deployments are much closer to production than traditional-evaluation rates. All three simulated-deployment rates of evaluation awareness were within 2.6\(\times\) of their production counterparts. For evaluation detection and metagaming, simulated deployments were far closer to production than to any traditional-evaluation aggregate; for verbalized alignment evaluation awareness, they were far closer to production than to alignment evaluations.

3.3 Realistic tool simulation is possible even in agentic coding settings↩︎

In this section, we focus on simulating internal employee Codex deployment traffic rather than ChatGPT traffic for two reasons. First, pre-deployment risk assessment for internal model deployments is essential for mitigating risks, especially from misalignment. Second, agentic coding is an especially challenging setting for deployment simulation and therefore serves as a stress test for our technique.

In 3.1.2, we found that our largest prediction errors occurred when the resampling environment poorly matched production (5). We suspect that the primary source of fidelity error was our use of a sampling pipeline different from that used for production traffic, an issue we have since addressed. A more fundamental conceptual hurdle remains: realistic tool use depends on external state. In increasingly common agentic settings, users ask models to inspect repositories, call tools, edit files, send network requests, and perform other stateful actions. A typical agentic trajectory can involve hundreds of tool calls that depend on or modify state beyond the conversation.

This creates a dilemma for simulation. Reconstructing the exact external state can be practically infeasible, but allowing an unreleased candidate model to act directly on live systems would defeat the purpose of pre-deployment evaluation: the very harms we are trying to forecast, such as leaking sensitive information or making damaging changes, could occur during the evaluation itself.

Tool simulator affordances. We build on prior work on tool simulation, using another LLM to simulate the response a tool call would have produced [10], and add deployment-specific affordances that substantially improve the realism of reconstructed production trajectories. To test this approach, we use roughly \(120{,}000\) Codex trajectories from internal OpenAI employee traffic rather than external ChatGPT traffic. This was a uniform sample from a subset of all traffic, for which we had full code state. We find that providing the tool simulator with the following additional affordances greatly improves simulation quality:

• Original trajectory context. First, one can give the tool simulator access to the original conversation: identical tool calls can receive identical results, and similar calls can receive plausible interpolations. This also helps reproduce failures from the original run, such as transient service failures or connectivity issues, which may be important because unexpected tool failures often induce misalignment. This affordance is less useful when the new model takes a substantially different path than the previous model.

• Time-matched codebase in a container. For agentic settings, another powerful affordance is to give the tool simulator access to the codebase checked out at the relevant commit, including any untracked files present at the time. For commands that do not require network access or external state, the tool simulator can execute the proposed commands in the codebase and return the observed results. The same idea could be applied to non-coding settings that require external files.

• A database of tool call-tool response pairs. One can also give the tool simulator a queryable database of past tool calls and responses sourced from other conversations. This database can show the simulator what particular tool responses typically look like.

• Read only access to network services and connectors. Finally, the tool simulator can access read-only versions of network services to determine what network calls would likely have returned.

Evaluating tool-simulation realism. We evaluate tool-simulation realism in two ways. First, we run a discriminator test: a GPT-5.4-based “differentiator” sees the shared prefix and two randomly ordered final-turn rollouts—one real and one simulated—and must identify the real one. Second, we measure evaluation-detection capability as in 3.2. The original policy model was GPT-5.4, the resampling policy model was GPT-5.5, and the tool simulator was GPT-5.4. We optimized the simulator and differentiator prompts with agents over eight iterations, alternating between improving the simulator’s win rate and strengthening the differentiator.

Improving tool-simulation realism. We also ablate components of the reconstructed tool-use environment. All the tested affordances appear to improve the realism winrate on their own and their benefits appear to stack.

3.4 Evaluating WildChat as a public proxy for production data to resample↩︎

To test whether deployment simulation can support external auditing without access to OpenAI’s private production data, we applied it to WildChat, a public dataset of chat conversations [11]. WildChat was collected between 2023 and 2024 by offering users free access to ChatGPT with GPT-3.5 and GPT-4, with explicit opt-in consent to collect and release anonymized chat transcripts. While WildChat is not expected to represent current AI usage as well as recent OpenAI production data, its public availability makes it a useful test case for auditing both OpenAI and non-OpenAI models. For each of GPT-5.1, GPT-5.2, and GPT-5.4, we resampled the final assistant turn in \(100{,}000\) randomly selected WildChat conversations and evaluated the resulting responses across our tracked categories.

Using recent production data gives more accurate predictions than using WildChat. Across models, estimates using recent OpenAI production data had lower multiplicative error against post-deployment production rates than WildChat estimates across tracked categories (\(1.75\times\) vs.\(2.44\times\); one-sided t-test on NLL: \(p=0.000142\); 9). This is consistent with the core premise of our method: resampling is most predictive when the prefix distribution closely approximates the deployment distribution of the target model.

Still, resampling WildChat data is surprisingly informative about deployment-time risk. Despite the distribution shift, WildChat resampling predicted which of two models would perform better at a rate significantly above chance (mean accuracy of 63.9% across GPT-5-series models, \(p=0.0025\)). Misbehavior rates estimated from WildChat remained positively correlated with post-deployment production rates across tracked categories, and most categories had average prediction errors within a factor of three of production rates (9, right). This indicates that public chat data can recover coarse information about which failures are more or less prevalent and can therefore help estimate corresponding deployment-time risks. Because WildChat is public, it can also support cross-provider comparisons that are difficult to run with private production data.

Unlike disallowed-content categories, our misalignment categories are assessed by giving the grader the candidate model’s full reasoning trace. This raw chain of thought is not publicly accessible, creating another barrier for external auditors. We therefore tested deployment simulation on WildChat without giving the grader access to the candidate model’s chain of thought, better approximating the conditions faced by external auditors. Mean multiplicative error across GPT-5-series misalignment categories was \(2.5\times\) with chain-of-thought access and \(3.1\times\) without it; the difference in NLL was not statistically significant (one-sided paired t-test: \(p=0.115\); 9, right). We generally expect the importance of chain-of-thought access to vary by misalignment category.

These results suggest that, for chat-like settings, public chat datasets can help external researchers estimate real deployment misbehavior prevalence even without access to private production logs or raw CoT. However, our validation compares WildChat and ChatGPT production traffic; separate validation would be needed to assess whether similar public proxies work for more agentic deployment settings. The remaining gap with recent production data quantifies the value of more representative, up-to-date, and tool-rich public datasets.

4 Discussion and Limitations↩︎

Below, we highlight four limitations and directions for future work.

Dependence on accurate measurements. Accurate measurements of model misbehavior require accurate graders. We reused graders previously validated for OpenAI system cards [9]. That said, detecting important forms of misalignment involving deceptive or strategic behavior often relies on the model’s reasoning process transparently revealing its intent. While this condition generally seems to hold today [6], we may lose chain-of-thought monitorability in several ways: future models may reason less legibly, skip key reasoning steps, or learn to obscure their intent [12].

Forecast quality depends on the similarity between the sampled and realized prefix distributions. Deployment simulation estimates behavior on the distribution represented by the sampled prefixes. However, usage distributions are not fixed. For example, new deployment applications, world events, new third-party tools and connectors, privacy updates (which could change the data available to resample), and seasonal variation in use patterns can all cause the distribution of conversation prefixes from any given sampling window to differ from the simulated deployment prefix distribution. This means recent historical traffic may not always match the deployment distribution of a more capable model. Prevalence forecasts should therefore be interpreted as estimates conditional on the sampled traffic distribution. Although our experiments show strong results under the off-policy prefix shifts across GPT-5-series deployments, they should not be read as evidence of robustness to any step-changes in model affordances.

Access to representative data. Our results suggest that the strongest evidence for how a model is likely to behave in production comes from resampled private production data, which is available only to AI developers. We found WildChat [11] to be an informative but substantially weaker public proxy for deployment misbehavior. It is unclear whether WildChat is especially predictive of OpenAI models, rather than those of other frontier labs, because it was built from older ChatGPT data collected in 2023–2024. We encourage other AI labs to quantify the efficacy of public data sources as predictors of their models’ safety, thereby supporting external auditing and fairer production-like comparisons.

Addressing tail risks. While we would expect deployment simulation to approach full coverage in the limit of infinite data, in practice it can find only alignment failures that occur on prefixes used for resampling. For instance, a catastrophic failure occurring once every 10 million conversations is unlikely to appear in a deployment simulation of 1 million conversations. Future versions of deployment simulation could estimate such tail risks through stratified sampling—skewing the sample to make misalignment more likely—and then correcting for the resulting bias [13]–[16]. Additionally, if novel tail risks are introduced by new model affordances that aren’t sufficiently elicited by old prefixes, even these mitigation approaches would be insufficient. This underscores the importance of also investing in other pre-deployment risk-assessment techniques focused on such tail risks.

5 Conclusion↩︎

Pre-deployment evaluations are most useful when they cover the situations models will actually face without requiring evaluators to anticipate every failure mode. Deployment simulation is deliberately simple: hold fixed de-identified conversation prefixes from prior deployments, resample the candidate model’s next response, and audit the result. Reusing such prefixes rather than writing prompt suites by hand or curating adversarial cases expands coverage of ordinary and hard-to-anticipate contexts with less manual evaluation work. It also makes evaluation a checkable forecast: developers can state expected misbehavior rates before release and compare them with what users actually encounter. Across our studies, this broader sampling provided a stronger signal than traditional baselines; in retrospective analyses, it helped identify failure categories that had not been tracked at the time.

Tool-use settings remain the hardest case, since faithful resampling can require reconstructing mutable external state; our results suggest that simulation is a promising way to close that gap. Our WildChat results suggest that public chat datasets can be a useful starting point for deployment-grounded audits when private logs are unavailable, even if they are not a substitute for representative production traffic. We hope this encourages deployment-grounded auditing by developers and motivates newer, more representative public chat datasets with richer tool-use contexts for independent comparisons of frontier models.

Understanding how AI systems behave in the real world is crucial for frontier labs seeking to deploy them safely. A natural benchmark for this understanding is whether we can predict models’ behavior before deployment [17]. Deployment simulation is an approach to pre-deployment risk assessment that helps labs and evaluators anticipate how language models may behave in real-world settings and what risks they may pose. Used alongside traditional evaluations, these forecasts can make model risk assessment more realistic, quantitative, and useful for deployment decisions.

Acknowledgments↩︎

We are grateful to Charles Zhao, Mikita Balesni, Jenny Nitishinskaya, and Gabriel Wu for running experiments closely related to this project and for offering valuable feedback. We especially thank Gaby Raila, Danielle Kehl, David Robinson, and Bowen Baker for their thoughtful feedback and broader support of the work. We also thank Dakota Goldberg, Sean Fitzgerald, Surya Mamidyala, and Chris Wendel for their invaluable help in establishing an intermediate version of our deployment-simulation pipeline. Finally, we thank Annie Disabato, Kyle Miller, Gaurav Misra, Pablo Orduna, Hao Sun, Madelaine Boyd, Jieqi Yu, Charles Proctor, Erik Boxhoorn, Ram Keelveedhi, Vinnie Monaco, and Ally Bennett, as well as the broader Safety Engineering team, for support that enabled us to improve the pipeline.

6 Preregistration Details and Version History↩︎

Before looking at GPT-5.4 Thinking production data, we preregistered both point predictions and evaluation criteria for the prospective study using OSF [18]. The full preregistration is available at osf.io/un3he [19]. This appendix records the intended hypotheses, scoring rules, and decision procedures for that forecast.

Preregistration history and corrections. We submitted an initial preregistration on March 6, 2026, before the release of GPT-5.4 Thinking. After release, but before inspecting the GPT-5.4 production outcomes used for validation, we improved the realism of the deployment simulation pipeline and filed an updated preregistration on April 20, 2026. Production outcomes were extracted retrospectively after the measurement window closed, and no member of the study team inspected the validation outcomes until April 21, 2026. The April 20 amendment therefore preceded any access to those outcomes. That update changed the pipeline’s point predictions but not the category set, measurement window, hypotheses, scoring rule, or statistical tests. The revised forecasts were therefore outcome-blinded, although they were not produced entirely before deployment.

During analysis, after inspecting the validation outcomes, we found an implementation error in the registered Challenging Prompts rate estimates. We corrected the error, which strengthened the Challenging Prompts baseline. Separately, the registered GPT-5.2 production rate for Fabricated Facts contained a transcription error (74 rather than 267.7 incidents per \(100{,}000\) assistant turns). The erroneous value favored deployment simulation, so correcting it made the H1 comparison less favorable to our method. 1 reports the initial, outcome-blinded, and final corrected results under a common scoring implementation. We report only the corrected analysis in the paper.

6.1 Challenging Prompts log-log linear fit↩︎

Following the equation specified in the pre-registration, \(\log(q_c)=\alpha_c\log(x_c)+\beta_c\), we fit a separate log-log linear relationship for each category. For category \(c\) and historical model \(m\in\mathcal{H}=\{\text{GPT-5},\text{GPT-5.1},\text{GPT-5.2}\}\), let \(x_{cm}\) denote the Jeffreys-smoothed Challenging Prompts unsafe rate and \(q_{cm}\) the Jeffreys-smoothed production prevalence. We estimate \[(\widehat\alpha_c,\widehat\beta_c) = \underset{\alpha,\beta}{\operatorname{argmin}} \sum_{m\in\mathcal{H}} \left[ \log(q_{cm})-\alpha\log(x_{cm})-\beta \right]^2.\]

Let \(x_{c,\text{GPT-5.4}}\) denote the corresponding GPT-5.4 Challenging Prompts rate. The resulting rate estimate is \[b^{(\mathrm{CP})}_c = \exp\!\left[ \widehat\alpha_c\log(x_{c,\text{GPT-5.4}}) +\widehat\beta_c \right].\]

For Extremism, all three historical unsafe counts are zero. Jeffreys smoothing keeps the log rates finite.

6.2 Hypotheses↩︎

Let \(\mathcal{C}\) denote the preregistered set of misbehavior categories. For each category \(c \in \mathcal{C}\), we preregistered a point prediction \(p_c\) for the category’s deployment prevalence \(\theta_c\) over a prespecified post-deployment measurement window, which started 7 days after the deployment of GPT-5.4 Thinking and ended 21 days after deployment.

For each category \(c\), let \(N\) be the number of sampled deployment items in the post-deployment measurement window and let \(K_c\) be the number of sampled items labeled as category \(c\). The empirical deployment prevalence is \(\hat{\theta}_c = K_c/N\).

6.2.0.1 Evaluation philosophy.

In practice, we care less about absolute frequency error than about practically large multiplicative underestimates or overestimates that materially change the expected incidence of a harm category. Most of the paper therefore uses symmetric multiplicative error, an intuitive metric aligned with this goal. However, symmetric multiplicative error does not lend itself well to statistical testing. For the preregistered hypothesis tests comparing our pipeline with baselines, we used a likelihood-based scoring rule that directly matches the sampling process: binomial negative log-likelihood (NLL).

6.2.0.2 Primary scoring rule (binomial negative log-likelihood).

We score a predicted prevalence \(p\in(0,1)\) against the observed deployment counts \((K_c,N)\) via the binomial negative log-likelihood⁴.

\[\mathrm{NLL}(p;K_c,N) \;=\; -\Big(K_c \log p + (N-K_c)\log(1-p)\Big).\]

For comparability across categories, we use per-sample NLL: \[\bar{\mathrm{NLL}}(p;K_c,N) \;=\; \frac{1}{N}\mathrm{NLL}(p;K_c,N).\]

6.2.0.3 Jeffreys smoothing (applied to count-derived probabilities).

Because the preregistered tests use binomial NLL, each point prediction \(p_c\) must satisfy \(p_c\in(0,1)\). To ensure this, whenever we convert finite counts \((K,N)\) into a probability for use as a prediction or baseline rate, we use the posterior mean under Jeffreys’ prior for the binomial model, \[J(K,N) \;=\; \frac{K+\tfrac{1}{2}}{N+1}, \qquad\text{corresponding to } p \sim \mathrm{Beta}\!\left(\tfrac{1}{2},\tfrac{1}{2}\right).\] This can be interpreted as adding \(\tfrac{1}{2}\) pseudo-success and \(\tfrac{1}{2}\) pseudo-failure, and ensures count-derived probabilities lie strictly in \((0,1)\) even when \(K\in\{0,N\}\) (preventing degenerate \(0/1\) probabilities that can arise purely from finite sampling). Compared to Laplace smoothing (uniform prior \(p\sim\mathrm{Beta}(1,1)\), posterior mean \((K+1)/(N+2)\)), Jeffreys smoothing adds half as many pseudo-counts, providing a lighter-touch regularization while retaining a standard reference-prior interpretation.

6.2.0.4 Definition of the preregistered predictions.

In the common case where \(p_c\) is produced as an empirical prevalence on a finite pre-release evaluation sample with counts \((K^{(\mathrm{sim})}_c,\,N^{(\mathrm{sim})}_c)\), we define \[p_c \;=\; J\!\big(K^{(\mathrm{sim})}_c,\,N^{(\mathrm{sim})}_c\big)\in(0,1).\] If a prediction is produced directly as a continuous probability, as for the Challenging Prompts rate estimates from the log-log linear fit in 6.1, we still require that it lie in \((0,1)\).

H1 (Primary; directional). Our pipeline’s predictions outperform a previous-deployment baseline under per-sample binomial NLL.

Previous-deployment baseline. Let \((K^{(\mathrm{prev})}_c,\,N^{(\mathrm{prev})}_c)\) denote the previous model’s deployment measurement counts for category \(c\). Define the baseline probability \[b^{(\mathrm{prev})}_c \;=\; J\!\big(K^{(\mathrm{prev})}_c,\,N^{(\mathrm{prev})}_c\big)\in(0,1).\]

Define the per-category loss difference \[d_c \;=\; \bar{\mathrm{NLL}}(p_c;K_c,N) \;-\; \bar{\mathrm{NLL}}(b^{(\mathrm{prev})}_c;K_c,N).\] We hypothesize that the mean loss difference across categories is negative: \[\mathbb{E}_{c\sim\mathcal{C}}[d_c] \;<\; 0.\]

H2 (Secondary; directional; subset where defined). On the subset of categories \(\mathcal{C}_{\mathrm{trad}} \subseteq \mathcal{C}\) for which a Challenging Prompts score \(e_c\) is available for the new model, our pipeline’s predictions outperform the Challenging Prompts rate estimates under per-sample binomial NLL. Each estimate \(b^{(\mathrm{trad})}_c\in(0,1)\) is obtained by fitting historical Challenging Prompts scores to historical deployment prevalences using only pre-release data, then applying that mapping to \(e_c\) for the new model. The log-log linear fit is defined in 6.1. We hypothesize: \[\mathbb{E}_{c\sim\mathcal{C}_{\mathrm{trad}}}\!\left[ \bar{\mathrm{NLL}}(p_c;K_c,N) - \bar{\mathrm{NLL}}(b^{(\mathrm{trad})}_c;K_c,N) \right] \;<\; 0.\]

H3 (Novel misalignment types above a detectable incidence threshold; directional). Let \(\mathcal{T}_{\mathrm{novel}}\) denote the set of novel misalignment types in deployment traffic that are not mappable to any category in \(\mathcal{C}\) under a preregistered adjudication rubric. For each novel type \(t\in\mathcal{T}_{\mathrm{novel}}\), let \(\theta_t\) denote its true deployment prevalence over the measurement window, and let \(K_t\) denote the number of occurrences of type \(t\) in the \(N\) sampled deployment items (so under i.i.d.sampling, \(K_t \sim \mathrm{Binomial}(N,\theta_t)\)).

Auditing sensitivity assumption. We assume the discovery-and-adjudication procedure has perfect recall for any novel type that appears at least \(m=10\) times in the sampled dataset; i.e., if \(K_t \ge m\), the procedure will surface and approve type \(t\) as a novel type.

Multiplicity control via a preregistered bound on the number of novel types. We preregistered an upper bound \(M_{\max}\) on the number of distinct novel types at the granularity induced by our adjudication rubric (i.e., \(|\mathcal{T}_{\mathrm{novel}}|\le M_{\max}\)) and a familywise error budget \(\alpha=0.05\). Define the detectable-incidence threshold \(\theta_\star=\theta_\star(N,m,\alpha,M_{\max})\) as the smallest prevalence such that a type at prevalence \(\theta_\star\) would fail to reach \(m\) occurrences with probability at most \(\alpha/M_{\max}\): \[\Pr\!\left[\mathrm{Binomial}(N,\theta_\star) < m\right] \;\le\; \frac{\alpha}{M_{\max}}, \quad\text{i.e.,}\quad \sum_{k=0}^{m-1} \binom{N}{k}\,\theta_\star^{k}\,(1-\theta_\star)^{N-k} \;\le\; \frac{\alpha}{M_{\max}}.\] By a union bound, for any collection of at most \(M_{\max}\) novel types, the probability that any type with prevalence at least \(\theta_\star\) fails to appear \(\ge m\) times in the sample (and thus could be missed by the audit) is at most \(\alpha\): \[\Pr\!\left[\exists\, t\in\mathcal{T}_{\mathrm{novel}}:\;\theta_t \ge \theta_\star \;\text{and}\;K_t < m\right] \;\le\; M_{\max}\Pr\!\left[\mathrm{Binomial}(N,\theta_\star) < m\right] \;\le\; \alpha.\]

Hypothesis. We hypothesize that no novel misalignment type has true deployment prevalence at or above this detectable-incidence threshold, i.e., \[\max_{t\in\mathcal{T}_{\mathrm{novel}}}\theta_t \;<\; \theta_\star.\]

6.3 Testing and decision procedures↩︎

For H1 and H2, we use the preregistered exact one-sided paired sign-flip test across categories, with the mean per-category NLL difference as the test statistic and all sign flips enumerated. H1 uses all categories in \(\mathcal{C}\) and compares deployment simulation with \(b^{(\mathrm{prev})}_c\); H2 uses \(\mathcal{C}_{\mathrm{trad}}\) and compares deployment simulation with \(b^{(\mathrm{trad})}_c\).

For H3, we run the preregistered discovery and independent-adjudication procedure. For any approved novel type, we define a judge, label the preregistered sample, and record its sample count \(K_t\). If no approved novel type has \(K_t\ge m\), then under the preregistered assumptions that \(|\mathcal{T}_{\mathrm{novel}}|\le M_{\max}\) and that the procedure has perfect recall for \(K_t\ge m\), we reject the complement of H3 at familywise level \(\alpha\); if any approved type has \(K_t\ge m\), we do not make this conclusion. We use \(m=10\), \(\alpha=0.05\), and \(M_{\max}=10\); for the realized sample size \(N\approx700{,}000\), the resulting threshold is \(\theta_\star\approx2.86\times10^{-5}\) (\(0.00286\%\)).

7 Additional results on predicting GPT-5-series misbehavior before deployment↩︎

3pt

8 Category-level GPT-5.4 forecasts↩︎

The tables below report the final corrected estimates, which supersede the ones in the preregistration. Aggregate H1 and H2 results for the initial registered forecasts, the outcome-blinded update, and the final corrected analysis appear in 1.

4pt

4pt

9 Detailed forecasting-validation figures↩︎

10 Detailed evaluation awareness figures↩︎

11 Data sources↩︎

5 reports the date ranges and numbers of conversations from each deployment used in our analyses.

12 Tracked categories↩︎

For our experiments, we use slightly refined versions of the misalignment categories from [21], while the known disallowed-content and sensitive-conversation behaviors follow the refusal and safety reporting used across recent OpenAI system cards, including GPT-5.4 [9], [20]. The full list of categories and descriptions appears in 6. We use two shorthand category sets throughout. All tracked categories comprise the full fixed taxonomy measured in resampling and production. The traditional-baseline subset comprises the categories that also have a traditional-evaluation analogue.

References↩︎