Windows 0.153.4: high usage with V2 workers, Code Mode truncation and effort-change cache misses (local telemetry)

Summary

I am requesting investigation of unexpectedly high Pro allowance consumption on Windows, with a mixed Astra/Terra MultiAgent V2 workflow. We audited local logs rather than relying only on the UI. The records show substantial real model usage, but also output/truncation and effort/cache behavior matching existing reports. We are not claiming that raw token totals prove incorrect billing.

This report is based on my account's local telemetry, prepared with Codex and sanitized before posting. It adds a larger Windows 0.153.x case and a meter-to-request reconciliation to #40897, #42996 and #35463.

Environment

• Windows, PowerShell, Codex desktop plus CLI; ChatGPT Pro.
• Current CLI and running desktop executable: codex-cli 0.153.4.
• Root session creation metadata: 0.153.1. Two largest workers: created with 0.153.4. Creation metadata is not an exact per-turn runtime version.
• Root model: gpt-6-astra; main default medium effort, with actual effort changes during the session.
• All eight workers in the largest task: gpt-5.6-terra, medium effort.
• Saved turn contexts explicitly say multi_agent_version: "v2".
• Current speed: standard (service_tier = "default"); historical request telemetry omits tier.

Relevant current configuration:

model = "gpt-6-astra"
model_reasoning_effort = "medium"
model_verbosity = "low"
service_tier = "default"

[features]
multi_agent = true
memories = true
goals = true
hooks = true

[features.context_management]
experimental_mode = true

[agents]
enabled = true
max_concurrent_threads_per_session = 4
default_subagent_model = "gpt-5.6-terra"
default_subagent_reasoning_effort = "medium"
max_depth = 1

No global context-window, auto-compact threshold, model-provider/catalog, or tool-output-limit override. No project config override was found for the largest task. We understand max_depth is ignored by V2 in the released source; all 31 workers active during the reported day nevertheless had depth one.

Observed allowance and request records

On September 5 local time (UTC-4), the weekly used percentage rose from 42% at 2026-09-05 16:39:49 UTC to 83% at 2026-09-06 02:06:54 UTC. It remained 83% overnight. The successful-record totals below cover the local calendar day, 04:00 UTC to 04:00 UTC, so the exact meter interval and aggregate interval differ slightly.

• 38 recorded active threads, 4,976 unique successful response records.
• Input: 673,459,926 tokens, including 655,156,736 cached input.
• Output: 2,153,451 tokens, already including reasoning.
• Astra main tasks: 2,205 requests; Terra workers: 2,443; Sol main tasks: 254; Astra workers: 74.
• Largest task main: 1,666 Astra requests. Eight Terra workers: 1,925 requests combined.
• Individual main-task input averaged 135,526 tokens per request; two largest workers averaged 141,577 and 150,911.

We summed token_usage_record.usage, deduplicated by response ID, rather than summing cumulative token_count events or stale thread summary counters. No duplicate response IDs were found in the broader 14,385-record scan. Earlier cumulative-only records were not treated as a complete weekly bill.

Concern 1: large nested outputs and repeated context growth

This resembles #40897 on Windows. The two largest Terra workers made 228 and 106 parallel batches. Their nested calls requested output budgets of 30,000 or higher at least 541 and 248 times. Tool-result records contained explicit truncation markers 90 and 48 times; the Astra main had 139 such records.

These are marker-containing records, potentially including nested/reprinted notices, not a count of independently proven truncation incidents. One QA aggregate reported roughly 1.70M original tokens before outer truncation; we do not assume all of that was model input or billed usage. Subsequent contexts nevertheless grew large and were reused across hundreds of requests.

Can the team confirm whether the nested Code Mode/output truncation strategy unnecessarily retains large results or causes repeated retrieval, and which supported controls constrain both inner results and model-visible retained output?

Concern 2: reasoning changes and cache misses

This matches the symptom in #42996:

The full main-task cache hit ratio remained 98.32%, so this is not a persistent cache collapse and cannot explain most of the day's consumption. It does appear to cause avoidable extra work at transitions.

Concern 3: model-specific context management in mixed worker trees

The new experimental context system is enabled for the Astra parent, with Terra workers. We are preparing a small controlled task/rollover comparison. This is currently a hypothesis, not a demonstrated failure: does a worker inherit context-management behavior that depends on model-specific capabilities? Is there a supported way to retain Astra's new context system while using the appropriate older compaction behavior for 5.6 workers?

Cross-checks and limitations

• No nested worker explosion was observed; the two largest workers started with fresh context.
• Four stored automations are paused and the queued-item table was empty.
• No visible overnight meter drain. Memory startup was skipped below 25% remaining; memory inference is not completely represented by this ledger.
• 19 response-stream retry warnings were found on the reported day. No matched retained operational signature for HTTP 429, anti-abuse/request blocking, capacity or invalid images under our narrow search.
• 975 history-projection warnings included ordinal mismatches. This is why we avoided summary counters.
• The meter generally moved in one-point increments. Repricing recorded work at current standard rates gave about 311-316 credit-equivalents per allowance point in each of the 50->60, 60->70 and 70->80 blocks. This argues against a sudden unexplained multiplier during those blocks, but it does not validate account entitlement, official Pro weights, or nonlocal/ephemeral usage.

Requested investigation

1. Reconcile the account's allowance with the server-side request ledger, including entitlement, cache/speed weights and any anti-abuse/accounting adjustment. We can supply scoped response IDs privately.
2. Confirm or rule out the Code Mode/output-growth mechanism in this Windows case.
3. Assess the effort-change cache behavior against #42996.
4. Clarify model-specific context-management support/inheritance in mixed Astra/5.6 V2 trees.

Related: #40897, #42996, #35463, #41220. We recognize that #9748's historical server-side quota bug was reported fixed in February and do not assume it has recurred.

Sanitized diagnostic screenshots are prepared for attachment. They are rendered summaries of local numerical evidence, not screenshots of the product usage UI. No private source files, full prompts, credentials, account IDs or unredacted rollouts are included.

Start with the scoped response IDs, local token_usage_record.usage data, and the server-side request ledger requested in the report. Compare the Windows 0.153.4 case with related issues #40897, #42996, and #35463, then assess the Code Mode truncation, effort-change cache behavior, and mixed Astra/Terra context handling. Done means the allowance is reconciled and each requested mechanism is confirmed or ruled out.