When should GPT-6.1 Sol compact?GPT-6.1 Sol 该在什么时候压缩？

Codex compacts on its own once a conversation reaches the token limit you choose. Here is what that choice costs, based on 137 real sessions.对话达到你设定的 token 上限时，Codex 会自动压缩。这个选择要花多少钱，下面用 137 个真实会话来回答。

Pick a threshold选一个阈值

The first row shows the cheapest trigger overall and the one with the shortest total model time. The second row shows the cheapest trigger for each waiting budget. The cards change when you move the speed slider under the chart. The chart only counts cost and waiting time, not what a smaller context does to the work itself. Day-to-day development usually needs 150K to 300K of context to go smoothly, so don't set the threshold too low; treat the "Cheapest overall" card as a reference only.第一行是整体最省钱和模型总耗时最短的触发点，第二行是各个等待时间预算下最省钱的触发点。拖动图表下方的速度滑块，卡片会跟着变。图里只算了费用和等待时间，没算上下文变小对工作本身的影响。一般来说，日常开发需要 150K 到 300K 的上下文才能顺畅工作，所以不建议把阈值设得太小，“整体最省钱”那张卡片仅供参考。

Cost and waiting at every trigger每个触发点的费用和等待

Everything is measured against the largest trigger, 828K, which sits at 0%. The top chart is cost. The bottom chart is time: orange is the share of model request time spent compacting, and purple is how much longer or shorter the model runs in total, ordinary requests and compactions together, compared with the 828K trigger. Both use one axis that stops at 20%, so a curve that climbs higher runs off the top. Hover or tap either chart to read any trigger. The shaded bands show the likely range.所有数值都和最大触发点 828K 相比，那里就是 0%。上面一张图是费用，下面一张图是时间：橙线是压缩占模型请求时间的比例，紫线是模型总耗时（普通请求加压缩）比 828K 触发点多或少了多少。两条线共用一根最高到 20% 的轴，更高的部分会冲出图的上沿。把鼠标移到任意一张图上或点一下，就能读出对应触发点的数值。浅色带是可能的范围。

Compaction time is mostly the model writing its summary. If your server is faster or slower than the measured 43 tokens per second, move the slider. It changes the orange and purple lines and their shaded ranges in the bottom chart and the pick cards above. The cost chart stays the same.压缩耗时主要花在模型写摘要上。如果你的服务比实测的每秒 43 个 token 更快或更慢，就拖动滑块。滑块会改变下面那张时间图里的橙线、紫线和它们周围的浅色区域，以及上面的卡片。费用图不会变。

How to read it怎么看这张图

Where this can mislead you哪些地方可能误导你

How the numbers were made这些数字是怎么算出来的

In short: we replayed real sessions at every trigger and added up what they would have cost and how long compaction would have taken.简单说：我们用真实使用记录在每个触发点上重放一遍，把费用和压缩耗时加起来。

  1. Real requests真实请求Request by request, from real GPT-6.1 Sol sessions in Codex: the context size, the cached share and the output of each one.逐个请求分析 Codex 里真实的 GPT-6.1 Sol 会话：每个请求的上下文大小、缓存命中比例和输出量。
  2. Measured compactions实测压缩346 compactions from these sessions calibrate the model. Each has its own input, cached prefix, summary output and observed duration. Timing starts at the later of the preceding request and the current turn start, and ends at the compaction record; it may include a little client-side time. Summary size uses the measured mean.用这些会话中的 346 次压缩校准模型。每次都有压缩请求自己的输入、缓存前缀、摘要输出和实测耗时。计时取前一个请求结束和当前回合开始中较晚者为起点，到压缩记录为止，可能包含少量客户端时间。摘要大小取实测均值。
  3. More workloads扩充工作负载Each session's request-to-request changes are cut into blocks of 8 requests and reshuffled with a fixed random seed. That gives 100 extra workloads that behave like the real one.把每个会话里相邻请求的变化切成每 8 个请求一块，用固定的随机种子重新洗牌，得到 100 组行为和真实记录相似的工作负载。
  4. Replay and average重放并取平均Every workload is replayed at every trigger. We average the cost and the compaction time over all 100 workloads. The final curves are not smoothed.每组工作负载在每个触发点上各重放一遍，再对 100 组的费用和压缩耗时取平均。最终曲线没有做平滑。

Data volume数据量

137 independent work sessions, 38,991 deduplicated ordinary requests and about 184 hours of model requests. 346 timed compactions calibrate the model. Smoke tests, test sessions and the sessions used to time compaction are left out. Where Codex compacted a session for real, the compaction request is dropped and the stretches before and after are joined into one uncompacted stream, so the replay decides where compactions happen.137 个独立工作会话，共 38,991 个去重普通请求，约 184 小时的模型请求。346 次有计时压缩用来校准模型。冒烟测试、测试会话和用来测压缩耗时的会话都没有计入。会话里 Codex 真实压缩过的地方，压缩请求本身被去掉，前后两段接成一条没有压缩的请求流，由重放来决定在哪里压缩。

Trigger range and data window触发点范围与数据时间范围

The chart uses 64K to 828K in 2K steps. Its upper bound is the agreed Codex window of 872K multiplied by 95%, then rounded down to a 2K grid point. Only sessions started between 2026-10-17T21:11:07Z and 2026-10-31T21:11:07Z (UTC) supply ordinary requests, compaction calibration and post-compaction measurements. This is a rolling 14 days, selected by session start rather than recent activity. Fixed API token weights are used without a long-context surcharge, following the agreed subscription convention; the chart does not estimate subscription allowance consumption.图表从 64K 到 828K，步长为 2K。上限按约定的 Codex 窗口 872K 乘以 95%，再向下取到 2K 网格点。普通请求、压缩校准和压缩后上下文测量，都只来自协调世界时 2026-10-17T21:11:07Z 到 2026-10-31T21:11:07Z 之间开始的会话。这是按会话开始时间筛选的最近 14 天，不按最近活动时间筛选。费用模型使用固定的接口 token 权重，按约定的订阅口径不加长上下文附加费；图表不估算订阅额度消耗。

Cost per 1M tokens每 100 万 token 的费用

The chart does not show the total bill of the sessions, because that would grow with the amount of history. Every cost is the replay cost at that trigger divided by the billed tokens of the real history (5,969 million), times one million. The divisor is one fixed number per model, not the token count of each replay. The reference million therefore has the real billing mix: 96.3% cache reads, 0.0% cache writes (1 hour), 0.0% cache writes (5 minutes), 3.3% plain input and 0.4% output. Costs are comparable between models and between amounts of history. The chart then shows each cost relative to the cost at the largest trigger (828K).图上不是这些会话的总账单，因为总账单会随历史数据的多少而变。每个费用都是该触发点下重放得到的总费用，除以真实历史的计费 token 数（5,969 百万），再乘以一百万。除数是每个模型固定的一个数，不是每次重放的 token 数。所以这一百万 token 的构成与真实计费一致：缓存读取 96.3%、缓存写入（1 小时）0.0%、缓存写入（5 分钟）0.0%、普通输入 3.3%、输出 0.4%。这样不同模型、不同数据量之间的费用可以直接比较。图上再把每个费用换算成相对最大触发点（828K）费用的变化。

Request time grows with context请求耗时随上下文增长

An ordinary request takes longer the more context it carries. Fitting the real requests (duration against context and output tokens), every extra 100K tokens of context adds about 4.02 s to a request, likely between 3.75 s and 4.23 s, on a mean request of 17.0 s. The replay applies this to every request: one that now runs at a larger context than it really had takes longer, one at a smaller context takes less.普通请求带的上下文越多，耗时越长。用真实请求拟合（耗时对上下文和输出 token），上下文每多 100K token，一次请求大约多 4.02 秒，可能在 3.75 到 4.23 秒之间，而一次请求平均 17.0 秒。重放时每个请求都按这个关系调整：现在跑在比真实更大的上下文上，就更慢；跑在更小的上下文上，就更快。压缩占比的分母就是请求时间加压缩时间。

Formula and symbols公式和符号

The cost of one request comes first. Then ordinary requests and compactions are added up over the whole workload.先算一次请求的费用，再把普通请求和压缩在整个工作负载上加起来。

Cost of one request Q(x, c, y) = p_m · [(1-c) + αc] · x + p_o · y Cost ratios α = p_c / p_m ρ = p_o / p_m B = (1-β) + αβ Total cost J(T) = Σ Q(ordinary requests) + Σ Q(compaction input and summary output) Time of one compaction t_c = a · (C - K) + G / v Request time at trigger T U(T) = Σ [τ + s · (x_T - x_obs)] Time share N_c(T) · t_c(T) / [U(T) + N_c(T) · t_c(T)] Steady-state approximation T* ≈ R + √( 2Δ · (BR + ρG) / α )单次请求费用 Q(x, c, y) = p_m · [(1-c) + αc] · x + p_o · y 成本比例 α = p_c / p_m ρ = p_o / p_m B = (1-β) + αβ 总费用 J(T) = Σ Q(普通请求) + Σ Q(压缩输入与摘要输出) 单次压缩耗时 t_c = a · (C - K) + G / v 触发点 T 下的请求时间 U(T) = Σ [τ + s · (x_T - x_obs)] 时间占比 N_c(T) · t_c(T) / [U(T) + N_c(T) · t_c(T)] 稳态近似 T* ≈ R + √( 2Δ · (BR + ρG) / α )
xContext tokens in one request.一次请求里的上下文 token 数。
yOutput tokens of that request, billed as output.这次请求输出的 token 数，按输出 token 计费。
cShare of a request's input that hits the prompt cache.请求输入中命中提示缓存的比例。
p_m / p_c / p_oCost per token of uncached input, cached input and output.未缓存输入、缓存输入和输出每个 token 的成本。
αCost of a cached input token divided by that of an uncached one; GPT-6.1 Sol: 0.05.一个缓存输入 token 的成本除以一个未缓存输入 token 的成本；GPT-6.1 Sol 为 0.05。
ρCost of an output token divided by that of an uncached input token; GPT-6.1 Sol: 5.一个输出 token 的成本除以一个未缓存输入 token 的成本；GPT-6.1 Sol 为 5。
BEffective cost of one ordinary context token, after the cache hit rate.考虑缓存命中率后，一个普通上下文 token 的有效成本。
C / KC is the compaction input in tokens. K is the part of it that comes from the cache.C 是压缩输入的 token 数，K 是其中来自缓存的部分。
T / RT is the compaction trigger; R is the context right after a compaction.T 是压缩触发点；R 是刚压缩完时的上下文大小。
ΔHow many tokens the context grows after each ordinary request, on average.每个普通请求之后，上下文平均增长多少 token。
GSummary tokens actually written, and billed, in one compaction.一次压缩实际写出并计费的摘要 token 数。
βShare of the compaction input that hits the cache.压缩输入中命中缓存的比例。
aSeconds per uncached input token, fitted on the measured compactions.每个未缓存输入 token 的处理时间，单位是秒，由实测压缩拟合。
vHow fast the summary is written, in tokens per second. The slider changes this one.摘要的生成速度，单位是 token 每秒。滑块调的就是它。
N_c / t_cNumber of compactions and the time of one compaction.压缩次数和单次压缩耗时。
U / sU is the request time at trigger T. s is the seconds one more context token adds to a request. x_T is the context a request has in the replay, x_obs the one it really had.U 是触发点 T 下的请求时间；s 是上下文每多一个 token，请求多花的秒数；x_T 是重放里请求带的上下文，x_obs 是它真实带的上下文。

What moves the best trigger哪些因素会挪动最佳触发点

The time model is fitted to 346 compactions: R² = 0.59. Summary size alone gives 0.59, input size alone gives -4.88. The closed-form formula explains the direction of each effect. The chart itself comes from the replay, which keeps the real order of requests, the real growth and the real moments of compaction.时间模型用 346 次压缩拟合，R² = 0.59；只用摘要大小是 0.59，只用输入大小是 -4.88。闭式公式用来解释每个因素的影响方向，图上的曲线来自重放，保留了真实的请求顺序、上下文增长和压缩时点。

The shaded bands are not confidence intervals. They replay every trigger again with the 10th and the 90th percentile of the measured summary size and cached prefix. The time bands also use the 10th and the 90th percentile of how much a longer context slows a request, taken over the resampled workloads.浅色区域不是置信区间。它是把每个触发点用实测摘要大小和缓存前缀的第 10 和第 90 百分位再重放一遍得到的。时间的浅色区域还用到了上下文变长会让请求慢多少的第 10 和第 90 百分位，来自重采样出的各个工作负载。