Clarify rollout token counters and add local compact/prune path

What changed from a user's point of view

While building tooling against Codex CLI rollout JSONL files, two related compaction/token-budget issues came up.

1. total_token_usage.total_tokens is easy to misread as current context

In rollout token_count events, payload.info.total_token_usage.total_tokens appears to be cumulative over the session, while payload.info.last_token_usage.input_tokens is the useful value for the most recent/current turn context.

Example shape from local rollout JSONL:

{
  "payload": {
    "type": "token_count",
    "info": {
      "total_token_usage": { "input_tokens": 76218, "total_tokens": 76484 },
      "last_token_usage": { "input_tokens": 38235, "total_tokens": 38325 },
      "model_context_window": 258400
    }
  }
}

A later event in the same rollout can show total_token_usage.total_tokens growing past 500k while last_token_usage.input_tokens is about 100k. That is internally coherent if total_token_usage is lifetime/session usage, but the field name is a trap for anyone writing context-window or compaction tooling. The name reads like "the total token count of the current context" rather than "cumulative token usage across turns."

Request: either rename/document the field semantics in emitted schema docs, or add clearer aliases such as:

• session_cumulative_token_usage
• last_turn_token_usage
• current_context_input_tokens if that is the intended context-window signal

2. Local deterministic compact/prune path

Codex CLI currently relies on model/API compaction for context reduction. That means trying to compact can itself consume the same provider budget that is already under pressure. It also leaves no deterministic local path for tooling that just wants to prune large tool outputs, stale command logs, or older rollout payloads before the next turn.

Request: add a local compact/prune operation that can run without a model call, for example:

• prune or summarize tool-output blocks using deterministic size/age rules
• remove older command stdout while keeping command, exit code, and artifact paths
• preserve developer/system/user messages and explicit memory/handoff content
• emit before/after token estimates so operators can see whether API compaction is still needed

Why this matters

The current behavior makes it easy for local tools to misdiagnose "current context is huge" by reading a cumulative lifetime field. When that happens, the next instinct is to trigger compaction, and compaction may spend scarce budget rather than reducing pressure locally.

Related issues I found before filing: #20311, #16258, #21269, #13733. This issue is specifically about the rollout field naming/semantics plus a deterministic local prune/compact path.