[Bug] Cloud planning loop consumes excessive CPU/RAM with no per-thread performance telemetry

Summary

A long-running cloud-backed Codex goal consumed excessive CPU/RAM resources from the user’s perspective while producing mostly planning, specifications, orchestration, and repeated goal continuations instead of the requested working product.

The local thread record contains extensive workload evidence, but Codex exposes no per-thread CPU, RSS, peak-memory, server compute, or energy telemetry. This makes it impossible to correlate the observed resource pressure with individual goal continuations, models, subagents, compactions, or planning loops.

Uploaded thread: 019f78cf-a24c-7f30-80ac-c32b3ccfc887

Available Performance Evidence

No historical CPU percentage, RSS, or peak-memory measurements were found in the thread or local Codex logs. The following workload measurements are available from the uploaded rollout:

• Rollout size: 28 MB (29,160,023 bytes).
• Rollout records: 23,382 JSONL lines.
• Automatic persistent-goal continuations: 105.
• Reasoning records: 4,023.
• Standard function calls: 2,867 plus 2,867 results.
• Custom tool calls: 1,730 plus 1,729 results.
• Total recorded tool calls: 4,597.
• Context compactions: 14.
• One verified goal checkpoint reported more than 7 million tokens used.
• The goal ran for more than a day while the user repeatedly reported that the agent was planning instead of delivering.

These numbers demonstrate a very large orchestration workload, but they do not reveal the corresponding cloud CPU/RAM cost or local client resource usage.

Steps to Reproduce

1. Start a persistent, unbounded implementation goal in a large multi-agent thread.
2. Let the agent repeatedly invoke brainstorming, specification, planning, review, subagent, and continuation workflows.
3. Allow the thread to accumulate millions of tokens, thousands of reasoning/tool records, and repeated context compactions.
4. Observe high CPU/RAM or resource pressure during cloud-thread processing.
5. Inspect the delivered repository and find that much of the activity produced planning documents and orchestration rather than the requested user-facing implementation.
6. Attempt to inspect per-thread performance logs and find no CPU, RSS, peak-memory, compute-time, or model-worker resource telemetry.

Actual Result

• Very high apparent resource consumption for limited user-visible delivery.
• Planning and orchestration loops continue without a compute-efficiency guard.
• Context growth causes repeated compaction and more processing.
• Subagent and tool-call volume grows without a corresponding deliverable-progress metric.
• The user cannot determine which model, continuation, subagent, or workflow consumed CPU/RAM.
• There is no automatic stop, throttle, or warning when compute consumption is high but source/product progress is low.

Expected Result

Codex should expose per-thread and per-goal resource observability, including:

• Local client CPU and RSS/peak memory.
• Cloud processing time and, where possible, normalized compute usage.
• Token usage by root agent, subagent, and continuation.
• Context size and compaction cost.
• Tool-call and subagent counts.
• Time and compute spent on planning/specification versus source implementation and verification.
• Deliverable-progress signals such as production-file changes, commits, passing acceptance tests, and user-visible artifacts.

The system should warn, throttle, or pause when resource usage grows substantially without measurable progress toward the original deliverable.

Impact

• The user directly observed sustained high local CPU usage while the cloud-backed thread was processing.
• The machine became unusually hot and experienced overheating/thermal pressure.
• Overall system responsiveness degraded and the computer became difficult to use normally.
• Codex delivery was simultaneously extremely slow, so the high resource usage did not correspond to fast or useful progress.
• Excessive CPU/RAM usage caused concrete thermal and performance impact on the client.
• Potentially unnecessary cloud compute consumption.
• Millions of tokens and thousands of operations spent without proportional delivery.
• No way for the user or support team to diagnose the resource source after the fact.
• The only recovery is manually interrupting the thread.

These client-side effects are user-observed. Exact CPU percentage, process RSS, temperature, throttling, and peak-memory values cannot be supplied because Codex did not record or expose them for this thread.

Environment

• Codex CLI: 0.144.6
• Platform: macOS
• Models included gpt-5.6-sol high/xhigh and gpt-5.6-terra medium during the thread.
• Persistent goal with an unbounded token budget.
• Multi-agent orchestration enabled.
• Repository: selectorChromePlugin

Suggested Fix

• Add a per-thread resource dashboard and downloadable performance trace.
• Record CPU/RSS/peak-memory metrics for local Codex processes.
• Expose normalized cloud compute and processing duration per turn where raw infrastructure metrics cannot be shared.
• Attribute tokens, compute time, tool calls, and compactions to root/subagent/goal identifiers.
• Add a compute-to-deliverable watchdog that detects plan-only or orchestration-only loops.
• Prompt the user before continuing after configurable resource, duration, token, or no-progress thresholds.
• Include resource telemetry in uploaded feedback threads so maintainers can diagnose performance regressions.

Related planning and goal-alignment reports: #34657, #34659, and #34662.