Add Windows unified exec yield floor#27086
Merged
Merged
Conversation
iceweasel-oai
marked this pull request as ready for review
June 8, 2026 23:12
jif-oai
approved these changes
Jun 9, 2026
jif-oai
left a comment
Contributor
There was a problem hiding this comment.
This is very hacky so I would like to see concrete numbers that proves that this will drastically improve the A/B result
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The Windows
unified_execexperiment regressed at the turn level in a way that points to premature backgrounding / extra command cycles rather than individual responses getting heavier:codex_local_tool_calls_per_turnwas up about 20.7%.codex_local_blended_tokens_per_turnwas up about 4.1%, andcodex_local_output_tokens_per_turnwas up about 4.0%.codex_local_response_latency_per_turnwas up about 8.3%.codex_turnsabout -6.6%,codex_dauabout -1.0%, andcodex_local_hourly_active_usersabout -3.0%.At the same time, the per-response metrics moved in the other direction: blended tokens per response, output tokens per response, and latency per response were all lower in test. That suggests the bad turn-level shape is largely about extra tool/model cycles, not each response being slower or more expensive on its own.
Local Windows benchmarking showed the likely mechanism: shell-wrapped commands pay a large PowerShell startup/teardown tax before the actual command has much time to run. In the benchmark, the PowerShell wrapper added roughly 0.7-1.0s versus direct exec:
pwsh): about 930ms p50 / 980ms p90 overhead versus direct exec.The model commonly asks for a 1s initial yield. On Windows, that can spend nearly the whole window waiting on PowerShell machinery, so otherwise-short commands are more likely to return as background sessions and require follow-up polling/tool calls.
This is intentionally a temporary unlock. It gives Windows closer to the same useful post-shell command window as other platforms while we work on reducing the PowerShell tax directly, for example with persistent PowerShell workers or conservative direct-exec paths for commands that do not need shell semantics.
What changed
unified_exec's initialyield_time_msclamp.Verification
just test -p codex-core unified_exec