Repository navigation
Hosted search usage causes premature auto-compaction #47825
Description
Hosted Responses search reports billing usage in usage.input_tokens, usage.output_tokens, and usage.total_tokens, which can exceed retained context size.
Codex uses last_token_usage.total_tokens for context accounting: Calling a gateway with hosted search reports the entire search loop's token usage.
Codex assumes that count is the number of tokens in the context window.
Please separate billable token usage from context occupancy so hosted tool loops do not trigger premature auto-compaction.
Activity
84dnnvbdvp-debug commentedon Sep 24, 2026
The current source path makes this look like a real accounting-contract mismatch rather than just a UI problem.
response.completedcopies providerusage.total_tokensverbatim intoTokenUsage; that response becomeslast_token_usage, whileContextManager::get_total_token_usage()treatslast_token_usage.total_tokensas active context andcontext_window_token_status()uses it for both auto-compaction and the full-window threshold. The TUI even documentslast_token_usage.total_tokensas the latest active context size.One regression I’d add is two runs with the same retained transcript but different provider-reported aggregate usage: the hosted-search run reports a much larger
total_tokensbecause of internal search/model passes. Billing/telemetry should preserve that full provider usage, butactive_context_tokensand the compaction decision should remain identical until the retained transcript itself grows. I’d cover bothTotalandBodyAfterPrefixscopes; the latter also seeds its server-observed prefill fromusage.input_tokens. I would not derive occupancy by subtracting cached input either—cached prompt tokens are cheaper, but they still occupy the model context.