通过模拟部署预测模型发布前的行为

引言

在发布新模型之前，实验室不仅需要了解其能力，还需掌握它在实际使用中可能的行为表现，包括可能引入的新风险。随着模型能力的提升，这一点变得愈发重要。作为部署前安全审查的一部分，我们利用定向评估、红队测试及其他检查手段来理解模型行为。如今，我们已开始采用一种在模型实际部署前模拟其部署的方法，这提供了一种补充信号：即在模型到达用户之前，对其可能的行为进行类似部署的预览。

部署模拟是一种在实际部署前模拟未来部署的方法。我们通过以隐私保护的方式，用新的候选模型重放之前的对话来实现这一点。这使我们能够在发布前研究新模型在真实场景中的响应方式，包括是否会出现新的不良行为及其可能出现的频率。

在多次 GPT-5 系列思维模型的部署中，部署模拟改进了我们对不良模型行为发生率的估计，帮助在发布前发现了新形式的不对齐问题，并降低了模型识别出自身正在被测试的风险。我们还将该方法应用于具有挑战性的智能体部署，表明它不仅能用于标准聊天场景，还能扩展到涉及工具使用的更复杂智能体设置，并可用于内部模型部署前的风险评估。

在模型开发过程中，我们已经利用部署模拟的洞察来识别传统评估中的盲点，并为缓解措施和部署决策提供信息。随着我们使该流程更易于运行，预计它将在未来的模型开发过程中发挥更大作用。

部署模拟的工作原理

业界使用的部署前评估通常由合成、手动编写或生产环境中的提示词混合组成，这些提示词被有意选择为困难、高严重性或对抗性的。这些评估通常有两个相互交织的目标：评估模型在部署流量中发生概率极小的压力测试场景下的响应方式，以及获得对不良模型行为的一般性理解，包括发现新的不良行为并预测其在部署时的发生频率。

虽然传统评估对于第一个目标仍然至关重要，但部署模拟在第二个目标（针对非尾部风险）方面代表了重大进步（在我们的实验中，该方法无法可靠测量每 20 万条消息中发生频率低于 1 次的行为）。部署模拟的优势在于规避了传统评估中的一些核心挑战：

• 覆盖范围： 很难确信评估提示词能覆盖所有可能的不良模型行为类型。测量新类型的不良行为需要创建新的评估，并了解需要衡量的危害。这可能耗时费力，且评估会随时间饱和。
• 选择偏差： 传统评估通常针对特定的不良模型行为构建，选择方式偏向于之前发生过的场景。这可能使其对部署分布全貌中此类行为发生率的估计信息量不足。
• 被模型识别为测试： 模型越来越能够判断自己正在被测试，这可能会扭曲其行为及我们对安全性的下游测量。虽然我们在 OpenAI 使用的许多传统评估也来自生产流量且不存在此问题，但这是业界许多传统评估普遍关注的问题。

部署模拟背后的主要技术很简单：我们从部署中提取最近的对话，移除旧模型的原始助手回复，并用待发布的候选模型重新生成回复。我们通过搜索新的失败模式来评估这些补全内容，并基于这种类似部署的分布来估计部署时不良行为的发生频率。我们可以在发布后对真实部署流量进行相同的测量，从而验证我们的部署前预测。

部署模拟显著缓解了上述三个限制：通过使用代表近期使用情况的评估提示词分布来解决采样偏差问题。使用代表性提示词的部署模拟也能缓解覆盖范围的担忧：通过模拟更多流量，我们获得了对不良模型行为更广泛的覆盖。这种计算量与覆盖范围之间的权衡很重要，因为它使风险评估这一维度的质量随计算量扩展，而非依赖于构建更多评估所需的手动工作。模型似乎也无法区分通过部署模拟获得的对话与真实部署流量。

图 1：我们的部署模拟流程概览

领域	传统评估	部署模拟
覆盖范围	更擅长处理我们希望确保覆盖的低发生率但高严重性风险	更擅长理解我们在部署流量中可能遇到的风险谱系
代表性/偏差	专注于评估针对性的过去或预测风险，即使这些行为在部署中发生率极低	代表当前部署流量中超过一定发生率的风险
评估意识	可能存在明显的测试线索（例如使用合成数据），除非评估是用部署数据创建的	类似部署的上下文似乎能显著缓解评估意识
工作量	自定义提示词分布和设置需要显著更多的手动工作	需要一次性基础设施成本，然后重用部署中的前缀和已知不良行为的评分器

传统评估与部署模拟之间的高层次比较

我们如何测试部署模拟

为了评估部署模拟，我们预先注册了对 GPT-5.4 思维模型 20 种不良行为在部署时发生频率的预测。我们还对 GPT-5 系列其他思维模型的部署进行了回顾性研究。我们分析的模型行为涵盖了我们在系统卡中报告的不对齐和禁止内容类别（例如模型对工具撒谎，或输出禁止的色情内容）。虽然在这些结果中我们只追踪了 20 类不良模型行为，并且只寻找新的不对齐行为，但部署模拟是一种通用技术，可用于模拟任何部署时的模型属性。

我们使用的生产流量同样来自 GPT‑5 系列思维模型。在运行评估之前，我们自动移除了与账户关联的标识符和可识别信息。根据我们的隐私政策，我们仅分析允许将其数据用于模型改进的用户的 ChatGPT 流量。我们仅报告这些评估的汇总结果。总计，我们分析了约 130 万条去标识化的对话，涵盖从 GPT‑5 Thinking 到 GPT‑5.4 的部署，时间跨度为 2025 年 8 月至 2026 年 3 月。

我们通过三种主要方式评估部署模拟生成的部署前风险评估质量：

• 分类覆盖： 发布后审计是否发现了我们初始不良行为分类中缺失的任何重要失调行为？
• 方向准确性： 模拟是否正确预测了已知行为在部署中的流行程度是增加还是减少？
• 比率校准： 我们的部署前估计是否接近我们后来在部署中观察到的比率？实现良好的比率校准不仅需要方向准确性，这使得它成为最高可能的质量标准。

我们还测量了在部署模拟期间模型能够察觉自身处于评估中的程度，并测试了该方法对不同形式的生产流量以及具有挑战性的工具使用设置的鲁棒性。

部署模拟显著扩展了部署前风险评估

在 GPT‑5 系列思维模型的部署中，部署模拟在确定实际风险率方面优于具有挑战性的提示基线，能够在发布前发现计算器黑客行为，并且对模型而言似乎与部署状态难以区分。

我们的预测概览。 关于 GPT‑5 系列思维模型部署的所有预测可视化，请参见图 2。对 GPT‑5.4 Thinking 的预测是预先注册的，而其他预测则是回顾性的。总体而言，我们的预测的中位数乘法误差为 1.5 倍（例如，如果不期望行为的发生率为每 10 万次中出现 10 次，这相当于估计每 10 万次中出现 15 次或 6.67 次）。虽然我们方法的尾部误差可能大约大 10 倍，但我们预计通过进一步改进模拟流程可以显著减少这些误差，如下文所述。

图 2. 基于先前部署数据的部署模拟对部署时不期望行为频率的预测。符号 5.1 → 5 表示我们使用 GPT‑5.1 对 GPT‑5 的前缀进行重采样，即基于 GPT‑5 的数据模拟 GPT‑5.1 的部署。失调行为的最高发生率是 GPT‑5.1 中的“计算器黑客”，我们已在_此前_⁠(在新窗口中打开)中讨论过。

将部署模拟预测与基线进行比较。 对于部署前风险评估，需要正确估计的最重要类别是那些在模型部署后发生率发生较大变化的类别（例如 >= 1.5 倍）。在这个子集上，部署模拟在预测某种不期望行为在模型部署后流行程度是增加还是减少（图 3，左图），以及估计其确切的部署时发生率（图 3，右图）方面，都显著优于基线。我们使用两个主要基线：一个是我们目前用于系统卡片和发布决策的具有挑战性的提示基线，以及一个使用先前部署的比率作为新模型估计的朴素基线。

图 3. 部署模拟在预测发生率变化方向（左图）和精确生产比率（右图）方面均优于静态评估。

我们流程中的模拟误差来源。 我们还研究了当前流程中的误差来源。具体来说，较大的尾部误差使得流程在部署决策中不太可靠：例如，当看到某种类型的不期望行为预测大幅增加时，如果已知流程偶尔会出现较大误差，就会引发疑问：这是可靠的估计还是流程的伪影？可能的误差主要有两个来源：

• 重采样环境保真度误差： 为了准确估计生产比率，我们的模拟流程需要尽可能真实。这在一定程度上是一个工程问题（使用与生产流量相同的流程从模型中采样），同时也对需要对外部资源进行读写访问的工具构成了有趣的挑战，这些资源是不断变化的（例如网络搜索或与本地文件交互）。我们可以通过比较实际部署及其模拟的预测（即模拟已部署模型的部署）来隔离模拟保真度误差。
• 提示分布偏移误差： 部署模拟的一个主要担忧是，任何模型的部署都会导致输入分布的变化，特别是当用户适应新的模型能力时。我们通过比较使用近期提示与使用实际部署中的提示进行模拟时的估计值来隔离提示分布误差。

如图 4 所示，我们发现当前流程中的大部分误差——尤其是尾部误差——主要来自模拟保真度。这是个好消息，因为我们预计模拟保真度通常比减少提示分布偏移更容易改进。我们还发现，使用来自先前部署的最新数据可能有助于减少提示分布偏移误差。更多细节可在研究论文中找到。

图 4：重采样环境保真度似乎是我们估计中最大的误差来源，尤其是对于最极端的误差。

自动化审计发现了这些部署中引入的唯一一种新的失调行为。 在我们研究的部署窗口内，基于模拟部署的自动化审计流程本可以在发布前发现“计算器黑客”行为，这是我们在分析的 ChatGPT 流量中识别出的唯一一种新型失调行为。计算器黑客是一种奖励黑客形式，涉及模型使用浏览器工具作为计算器，同时将该操作呈现为搜索。这并不意味着大规模审计会捕捉到每一个新的失败，但它说明了为什么真实环境很重要：它们可以引发更狭窄的评估集可能永远无法直接展现的行为，即使这些行为在用于启动模拟的原始流量中并不存在。

降低评估意识

使用类似部署场景的另一个优势在于，它们可以减少模型在意识到自身正在被测试时可能产生的偏差。在先前的研究中，我们以及其他团队⁠(在新窗口中打开)都发现，模型通常能意识到自己正在被测试。例如，模型可能会在其思维链中推理自己正在被测试什么、评估者可能喜欢什么，以及——如果它们行为不当——自己是否会被发现。这给对齐评估带来了一个问题：如果模型仅仅因为认为自己正在被测试才表现良好，那么当它意识到自己已部署后，我们如何建立对其安全行为的信心？

我们证明，与不基于真实部署数据的传统评估相比，部署模拟显著降低了模型表现出的评估意识水平。我们通过三种方式衡量评估意识：要求模型对轨迹来自生产环境还是评估进行分类，监控思维链中关于被评估对齐的明确陈述，以及监控元游戏⁠(在新窗口中打开)：任何关于监督的推理。模拟部署流量在所有三项指标上都与真实部署流量高度匹配。例如，GPT‑5.2 将真实生产流量标记为类似评估的比例为 5.4%，模拟流量为 5.1%，而传统评估（如 SWE-Bench 或 MonorepoBench，主要由合成示例组成）被分类为评估的比例几乎为 100%。

图 5. 评估意识对比：真实生产流量和模拟流量在评估检测、口头化对齐评估意识和元游戏方面表现出相似比率，而传统评估数据集报告的比率则高得多。

用于智能体轨迹的工具模拟

为了测试该方法是否能扩展到标准聊天模式之外，我们还研究了在具有挑战性的智能体编码环境中模拟部署。具体来说，我们使用来自 GPT‑5.4 的 120,000 条内部员工智能体轨迹，来模拟基于 GPT‑5.5 的编码智能体的内部部署。这有两个目的：这展示了部署模拟如何也可用于内部部署的风险评估，并且证明了即使在智能体环境中，通过细致的工具模拟，也可以实现高模拟保真度。

上文我们提到，模拟保真度是我们当前流程中误差的主要来源之一。使部署模拟逼真的挑战之一在于，需要工具以逼真的方式运行，即使它们需要对不断变化的外部资源进行读写访问（例如网络搜索或与本地文件交互）。

这对于智能体部署等环境尤其具有挑战性：单个智能体轨迹可能依赖于数百次工具调用、仓库状态、网络响应或瞬时故障。这使得使用真实工具访问进行重采样既困难又可能危险。鉴于此，我们不是将工具调用应用于实时系统，而是用另一个 LLM 来模拟它们。我们证明，为这个 LLM 提供额外的能力对于实现逼真度以及因此的估计质量至关重要。

我们为工具模拟模型提供了原始的最终轮次输出、对话发生时的仓库、工具调用/响应对数据库以及只读连接器。在一个判别器试图区分模拟输出和真实输出的测试中，逼真度从 11.6% 的胜率提高到 49.5%，接近 50% 的随机水平。

图 6：即使在工具密集的环境中，当通过增加能力来模拟工具调用时，可以使重采样逼真度几乎与真实采样无法区分。

作为模拟保真度的额外证据，当使用 GPT‑5.4 模拟 GPT‑5.4 Codex 思维流量时，失调率几乎在误差范围内。相比之下，在我们的部署前测试中，GPT‑5.5 在大多数类别中的失调程度更高。

图 7：通过工具模拟，使用 GPT‑5.4 重采样的对话行为率与实际 GPT‑5.4 生产流量非常相似——表明重采样环境保真度高。有关这些类别的更多背景信息，请参阅GPT‑5.5 系统卡⁠(在新窗口中打开)。

这些结果表明，当周围工具环境以足够保真度模拟时，部署模拟可以扩展到复杂的智能体环境。

WildChat 与外部审计

一个自然的问题是，外部审计员是否可以在无法访问私有生产流量的情况下获得一些相同的好处。我们使用 100,000 条 WildChat 对话作为前缀进行了测试。WildChat 的准确性低于最近的 OpenAI 生产数据，但仍然具有参考价值：最近的生产数据的平均乘法误差低于 WildChat（1.75 倍对比 2.44 倍），而 WildChat 通常保持在生产比率的大约 3 倍以内，并以高于随机水平的比率识别出更好的模型。我们认为 WildChat 风格的评估是开发者运行部署模拟的一个有前景的补充。关于这一点的更多结果，请参见随附的 Alignment 博客文章⁠(在新窗口中打开)。

局限性

部署模拟是对对抗性评估、红队测试和针对性尾部风险分析的补充，而非替代。某些不良模型行为的检测依赖于思维链的可监控性：如果未来的模型推理不够清晰、省略关键步骤或学会掩盖意图，我们可能无法检测到这些形式的不良行为。此外，由于生产数据是私有的，开发者目前比外部审计员拥有更强的代表性上下文访问权限。更好的公共数据集可以缩小这一差距。

部署模拟对于在采样前缀中足够频繁出现的行为最为有用。在千万次对话中仅发生一次的故障不太可能在百万次采样运行中被发现，因此对抗性评估、红队测试和针对性尾部风险分析仍然是必要的。我们目前专注于模拟单次助手响应，因为在初步实验中，我们发现通过模拟多轮对话并未对估计结果带来有意义的改进。这可能是未来提高模拟保真度的一个重要领域。

该方法还依赖于前缀分布——即被重新采样的对话组合。历史流量可能无法反映用户在与更强大模型交互时的行为变化，尤其是在重大产品更新、新工具发布、全球事件或季节性转变之后。完整论文中的分析表明，通过使用最新的可用数据，这一问题可以得到缓解。

结论

部署模拟是一种新的部署前风险评估方法，可帮助前沿实验室和评估者预测语言模型在现实世界中的行为，并在部署前了解其潜在风险。它通过增加一个更接近生产环境的预测层，补充了现有的安全评估、红队测试和针对性分析，从而改进对部署行为的估计、减少评估意识效应，并使部署前的预测在发布后可被验证。与传统评估方法结合使用时，部署模拟能够使模型风险评估更加贴近实际、更具量化性，并对部署决策更有帮助。

Introduction

Before releasing a new model, labs need to understand not just what it can do, but how it is likely to behave in real-world use, including where it might introduce new risks. This becomes even more important as capabilities increase. As part of our pre-deployment safety review, we leverage targeted evaluations, red-teaming, and other checks to understand model behavior. We’ve now started using a method for simulating model deployments before they happen, which adds a complementary signal: a deployment-like preview of how a candidate model may behave before it reaches users.

Deployment Simulation is a method for simulating a future deployment before it happens. We do so by replaying previous conversations in a privacy-preserving manner with a new candidate model. This enables us to study how the new model responds in realistic contexts before release, including whether new undesired behaviors emerge and how often they may appear.

Across multiple GPT‑5‑series Thinking deployments, Deployment Simulation improved our estimates of undesired model behavior rates, helped surface novel forms of misalignment before release, and helped reduce the risk that models would be able to tell they were being tested. We also applied the method to challenging agentic rollouts, showing that it can extend beyond standard chat to more complex agent settings involving tool use, and can also be used for risk assessment before internal model deployments.

We have already used insights from Deployment Simulation during model development to identify blind spots in traditional evaluations and inform mitigations and deployment decisions. As we make the pipeline easier to run, we expect it to play a larger role in the future model development process.

How Deployment Simulation works

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 have generally had two intertwined goals: assessing how the model responds when stress-tested in situations that have a very small chance of occurring in deployment traffic, and gaining a general understanding of undesired model behaviors, including finding novel undesired behaviors and predicting their deployment-time frequencies.

While traditional evaluations remain crucial for the first goal, Deployment Simulation represents a significant step forward with regards to the second goal for non-tail risks (in our experiments, our approach can’t be expected to measure behaviors that occur with frequency less than 1 in 200,000 messages). Deployment Simulation’s strength comes from side-stepping some core challenges with traditional evaluations:

• Coverage: it is difficult to be confident that evaluation prompts will cover all possible types of undesired model behavior. Measuring new types of undesired behavior requires creating new evaluations, and knowing what harms to measure. This can be time and labor intensive, and evaluations can saturate over time.
• Selection biases: traditional evaluations generally are built with specific undesired model behaviors in mind, selected in ways that bias towards contexts have previously occurred. This may make their estimates less informative about incidence of such behaviors in the full breadth of the deployment distribution.
• Being recognizable as tests by models: models have been increasingly able to determine they are being tested, which can distort their behavior and our downstream measurements of their safety. While many of the traditional evaluations we use at OpenAI are also drawn from production traffic and don’t suffer from this issue, this is a common concern for many traditional evaluations used across the industry.

The main technique behind Deployment Simulation is simple: we take recent conversations from deployment, remove the original assistant response from the older model, and regenerate it with a candidate model to be released. We evaluate the completions by searching for new failure modes, and estimate deployment-time undesired behavior frequency based on frequency in this deployment-like distribution. We can perform the same measurements after release on real deployment traffic, enabling us to validate our pre-deployment forecasts.

Deployment Simulation significantly mitigates the three limitations listed above: sampling bias is addressed by using a distribution of evaluation prompts representative of recent usage. Deployment Simulation with representative prompts can also mitigate concerns about coverage: we get greater coverage of undesirable model behaviors by simply simulating more traffic. This tradeoff between compute and coverage is important, because it makes the quality of this axis of risk assessment scale with compute, rather than the manual effort required to build more evaluations. Models also don’t seem to be able to distinguish between conversations obtained via deployment simulation and real deployment traffic.

Figure 1: Overview of our Deployment Simulation pipeline

AreaTraditional EvaluationsDeployment Simulation CoverageBetter for low prevalence but high severity risks that we want to make sure we have coverage for Better for understanding the spectrum of risks we’re likely to see in deployment traffic Representativeness / biasFocused on evaluating targeted past or predicted risks, even for behaviors that have extremely low prevalence in deployment Representative of risks that occur above a certain prevalence in current deployment traffic Evaluation awarenessPotentially obvious test cues (e.g., with synthetic data) unless evals are created with deployment data Deployment-like context seems to significantly mitigate eval awareness EffortCustom prompt distributions and setups requires significantly more manual effort Requires a one-time infrastructure cost, and then reuses prefixes from deployment and graders from known undesired behaviors

High level comparison between traditional evaluations and Deployment Simulation

How we tested Deployment Simulation

To evaluate Deployment Simulation, we pre-registered predictions for the deployment-time frequency of 20 types of undesirable behavior for GPT‑5.4 Thinking. We also ran retrospective studies across other deployments of Thinking models of the GPT‑5‑series. The model behaviors we analyze cover both misalignment and disallowed content categories which we have been reporting in system cards (e.g. the model lying about tools, or outputting disallowed sexual content). While for these results we only track 20 categories of undesired model behavior, and only look for novel misaligned behaviors, Deployment Simulation is a general technique which could be applied to simulate any deployment-time model property.

The production traffic we leveraged was also from Thinking models of the GPT‑5‑series. Before running our evaluations, we automatically removed account-linked identifiers and identifiable information. In accordance with our privacy policy, we only analyzed ChatGPT traffic from users who allow their data to be used for model improvements. We report only aggregate findings from these evaluations. In total, we analyzed approximately 1.3 million de-identified conversations across GPT‑5 Thinking through GPT‑5.4 deployments, spanning August 2025 to March 2026.

We evaluate the quality of the pre-deployment risk-assessment produced by Deployment Simulation in three main ways:

• Taxonomy coverage: did post-release auditing surface any important misaligned behaviors missing from our initial bad behavior taxonomy?
• Directional accuracy: did the simulation correctly predict whether deployment prevalence would increase or decrease for known behaviors?
• Rate calibration: were our pre-deployment estimates close to the rates we later observed in deployment? Achieving good rate calibration requires more than directional accuracy, making this the highest possible quality standard.

We also measure how much models are able to tell they are in an evaluation during Deployment Simulation, and test how robust the method is to different forms of deployment traffic and to challenging tool use settings.

Deployment Simulation significantly expands pre-deployment risk assessment

Across GPT‑5‑series Thinking deployments, Deployment Simulation outperformed challenging-prompt baselines in determining actual risk rate, was able to surface calculator hacking before release, and appeared potentially indistinguishable from deployment to the model.

Overview of our predictions. For a visualization of all predictions for Thinking model deployments of the GPT‑5‑series, see Figure 2. The predictions for GPT‑5.4 Thinking were pre-registered, while the others were retroactive predictions. In aggregate, our predictions had a median multiplicative error of 1.5x (e.g. if the undesirable behavior rate is 10 in 100k, this would correspond to estimating a rate of 15 or 6.67 in 100k). While tail errors of our method can be roughly 10x larger, we expect they can be significantly reduced with further improvements to our simulation pipeline, as discussed below.

Figure 2. Deployment Simulation frequency predictions of deployment-time undesirable behavior based on prior deployment data. The notation 5.1 → 5 indicates that we are resampling prefixes from GPT‑5 with GPT‑5.1, that is, simulating GPT‑5.1’s deployment based on data from GPT‑5. The highest rate of misaligned behavior was “calculator hacking” in GPT‑5.1, which we have discussed_previously_⁠(opens in a new window).

Comparing Deployment Simulation predictions to baselines. The most important categories to estimate correctly for pre-deployment risk-assessments are ones that have large changes of incidence after the model’s deployment (e.g. >= 1.5x). On this subset, Deployment Simulation is substantially better than baselines both at predicting whether a certain undesirable behavior will increase or decrease in prevalence with a model’s deployment (Figure 3, left), and at estimating its exact deployment-time incidence (Figure 3, right). We use two main baselines: a Challenging Prompts baseline which we currently use for system cards and launch decisions, and a naive baseline of using rates from the previous deployment as estimates for the new model.

Figure 3. Deployment Simulation predicts both the direction of incidence changes (left) and exact production rates (right) better than static evals.

Sources of simulation error in our pipeline. We also studied the current sources of error in our pipeline. Specifically, large tail errors make the pipeline less trustworthy for deployment decisions: for example, when seeing a large predicted increase in an undesirable behavior of a certain type, if the pipeline is known to have even occasional large errors, it raises doubt about whether this is a reliable estimate or an artifact of the pipeline. There are two main sources of possible error:

• Resampling environment fidelity error: to estimate production rates accurately, our simulation pipeline needs to be as realistic as possible. This is in part an engineering problem (sampling from the model using the same pipelines used for production traffic), and in part an interesting challenge for tools which need read/write access to external resources which are constantly changing (e.g. web searches or interacting with local files). We can isolate the simulation fidelity error by comparing predictions from an actual deployment and its simulation (that is, simulating the deployment of the already deployed model).
• Prompt distribution shift error: a major concern with Deployment Simulation is that any model’s deployment will cause a distributional shift in inputs, especially if users adapt to new model affordances. We isolate prompt distribution error by comparing estimates when simulating the deployment using recent prompts vs prompts from the realized deployment.

As seen in Figure 4, we find that a large fraction of the error in our pipeline–especially for tail errors–is currently due to simulation fidelity. This is good news, as we expect simulation fidelity to be generally easier to improve than reducing prompt distribution shift. We also find that prompt distribution shift error may be reduced by using the most recent data from the previous deployment. More detail can be found in the research paper.

Figure 4: Resampling environment fidelity seems to be the largest source of error in our estimates, especially for the most extreme errors.

Automated auditing found the one new misalignment introduced in these deployments. In the deployment window we studied, our automated auditing pipeline based on simulated deployments would have surfaced ‘calculator hacking’ before release, which was the only novel misalignment we identified in the analyzed ChatGPT traffic. Calculator hacking is a form of reward hacking which involves the model using a browser tool as a calculator while presenting the action as a search. This does not mean large-scale auditing will catch every new failure, but it shows why realistic contexts matter: they can elicit behaviors that narrower eval sets may never surface directly, even if they were not present in the original traffic used to seed the simulation.

Reducing evaluation awareness

Another advantage of using deployment-like contexts is that they may reduce distortions that arise when models recognize they are being tested. In prior research, we as well as others⁠(opens in a new window) have found that models are often aware of when they’re being tested. For example, models may reason in their chain-of-thought about what they’re being tested on, what an evaluator might like, and – if they’re misbehaving – whether they’ll be caught. This poses a problem for alignment evaluations: if a model is only well behaved because it thinks it's being tested, how do we build confidence that it’ll behave safely once it learns it’s been deployed?

We show that Deployment Simulation substantially reduces levels of evaluation awareness exhibited by models relative to traditional evaluations which are not based on real deployment data. We measure evaluation awareness in three ways: by asking a model to classify whether a trajectory came from production or an evaluation, monitoring chain-of-thought for explicit statements about being evaluated for alignment, as well as for metagaming⁠(opens in a new window): any reasoning about oversight. Simulated deployment traffic closely matched real deployment traffic across all three measures. For example, GPT‑5.2 labeled real production traffic as evaluation-like 5.4% of the time and simulated traffic 5.1% of the time, while traditional evaluations (such as SWE-Bench or MonorepoBench, which are composed primarily of synthetic examples) were classified as evaluations almost 100% of the time.

Figure 5. Evaluation-awareness comparison: real production traffic and simulated traffic show similar rates for eval detection, verbalized alignment evaluation awareness, and metagaming, while traditional eval datasets report much higher rates.

Tool simulation for agentic trajectories

To test whether the method could extend beyond standard chat modes, we also studied simulating deployments for challenging agentic coding settings. Specifically, we use 120,000 internal employee agentic trajectories from GPT‑5.4 to simulate the internal deployment of coding agents based on GPT‑5.5. This serves two purposes: this shows how deployment simulation can also be used for risk-assessment for internal deployments, and it demonstrates that it is possible to make simulation fidelity high even in agentic settings via careful tool simulation.

Above we discussed that the simulation fidelity is one of the main sources of error in our current pipeline. One of the challenges with making deployment simulations realistic is that it requires tools to act in realistic ways, even when they need read/write access to external resources which are constantly changing (e.g. web searches or interacting with local files).

This is especially challenging for settings such as agentic deployments: a single agent trajectory can depend on hundreds of tool calls, repository state, network responses, or transient failures. This makes resampling with real tool access both challenging and potentially dangerous. In light of this, instead of applying tool calls to live systems, we simulate them with another LLM. We show that giving this LLM extra affordances is essential to realism and therefore estimation quality.

We give the tool-simulator model the original final-turn rollout, the repository from the time of the conversation, a database of tool-call/response pairs, and read-only connectors. In a test where a discriminator tried to tell simulated from real rollouts, realism improved from an 11.6% win rate to 49.5%, near the 50% chance level.

Figure 6: One can make resampling realism almost indistinguishable from real sampling even in tool-heavy settings when simulating tool calls with increased affordances.

As additional evidence of simulation fidelity, when simulating GPT‑5.4 Codex thinking traffic with GPT‑5.4, the misalignment rates are, just about, within error bars. By contrast, in our pre-deployment testing GPT‑5.5 was more misaligned in most categories.

Figure 7: With tool simulation, behavior rates for conversations resampled with GPT‑5.4 and actual GPT‑5.4 production traffic are quite similar – indicating high resampling environment fidelity. See the_GPT‑5.5 system card_⁠(opens in a new window)for more context on the categories.

These results suggest that Deployment Simulation can extend to complex agent settings when the surrounding tool environment is simulated with sufficient fidelity.

WildChat and external auditing

A natural question is whether external auditors can get some of the same benefits without access to private production traffic. We tested this with 100,000 WildChat conversations used as prefixes. WildChat was less accurate than recent OpenAI production data, but still informative: recent production data had lower average multiplicative error than WildChat (1.75× vs. 2.44×), while WildChat often stayed within roughly 3× of production rates and identified the better model at above-chance rates. We see WildChat-style evaluations as a promising complement to developer-run Deployment Simulation. See this companion Alignment blogpost⁠(opens in a new window) for more results on this point.

Limitations

Deployment Simulation is a complement to, not a replacement for, adversarial evaluations, red-teaming, and targeted tail-risk analysis. The detection of some undesired model behaviors relies on chain-of-thought monitorability: if future models reason less legibly, omit key steps, or learn to obscure intent, we may not be able to detect these forms of undesirable behavior. Furthermore, because production data is private, developers currently have stronger access to representative contexts than external auditors. Better public datasets could narrow that gap.

Deployment Simulation is most useful for behaviors that occur often enough to appear in sampled prefixes. A failure that occurs once in ten million conversations is unlikely to be discovered in a million-sample run, so adversarial evaluations, red-teaming, and targeted tail-risk analysis remain necessary. We currently focus on simulating a single assistant response, as in preliminary experiments we did not find meaningful improvements to our estimates by simulating multiple turns. This may be an important area for improving simulation fidelity in the future.

The method also depends on the prefix distribution—the mix of conversations that are being resampled. Historical traffic may not match how users interact with a more capable model after a major product change, new tool release, world event, or seasonal shift. Analysis in the full paper suggests that this issue can be mitigated by using the most recent data available.

Conclusion

Deployment simulation is a new approach to pre-deployment risk assessment that helps frontier labs and evaluators predict how language models may behave in the real world and understand the risks they pose before deployment. It complements existing safety evaluations, red-teaming, and targeted analysis by adding a more production-like prediction layer that can improve estimates of deployment behavior, reduce evaluation-awareness effects, and make pre-deployment predictions checkable after release. Used alongside traditional evaluations, Deployment Simulation can help make model risk assessment more realistic, more quantitative, and more useful for deployment decisions.