Untitled

Here's what's breaking. Codex Desktop 26.519.2081.0 shipped without the context/token usage indicator. You used to see context-window pressure near the input bar. Now it's gone. No changelog note, no deprecation warning. Just an empty corner where your token budget used to live.

Sound familiar? If you're running long agent sessions, this one hurts. You're flying blind on when the context window is about to blow.

Why it happens

Context indicators aren't magic. They read from the same event stream the model already emits. Every completion carries usage metadata — prompt_tokens, completion_tokens, total_tokens — and the app aggregates those into a running total against the model's context limit.

When that indicator disappears after an update, it's almost always one of three things:

1. The usage payload stopped arriving — the client is still requesting it, but the response shape changed and the parser silently drops it.
2. The UI component got conditionally rendered out — a feature flag, an A/B branch, or a refactor that removed the element from the tree.
3. The aggregation state reset — the counter exists but never gets rehydrated on session resume, so it renders as zero and gets hidden.

You can usually tell which one by opening DevTools and inspecting the network tab during a completion. Look at the response body. If usage is present in the JSON but no UI element updates, it's a rendering problem. If usage is missing entirely, the request is being sent without stream_options: { include_usage: true } or your client is on an old stream parser.

Here's the request shape that actually returns usage on a streaming call:

{
  "model": "gpt-4o",
  "stream": true,
  "stream_options": { "include_usage": true },
  "messages": [{ "role": "user", "content": "hello" }]
}

Without include_usage, streaming responses omit the final usage chunk. Non-streaming calls always include it. If Codex switched to a streaming path and forgot the flag, the indicator would go dark with no error.

Manual fix

If you're hitting this in your own tooling, here's how to restore the counter yourself. Wrap the client and accumulate tokens per session:

type Usage = { prompt_tokens: number; completion_tokens: number; total_tokens: number };

class UsageTracker {
  private totals: Usage = { prompt_tokens: 0, completion_tokens: 0, total_tokens: 0 };
  private contextLimit = 128_000; // set per model

  ingest(chunk: any) {
    if (chunk?.usage) {
      this.totals.prompt_tokens += chunk.usage.prompt_tokens ?? 0;
      this.totals.completion_tokens += chunk.usage.completion_tokens ?? 0;
      this.totals.total_tokens += chunk.usage.total_tokens ?? 0;
    }
  }

  pressure() {
    return this.totals.total_tokens / this.contextLimit;
  }

  render() {
    const pct = (this.pressure() * 100).toFixed(1);
    const warn = this.pressure() > 0.8 ? " ⚠" : "";
    return `context: ${pct}% (${this.totals.total_tokens}/${this.contextLimit})${warn}`;
  }
}

Wire it into your stream loop:

const tracker = new UsageTracker();

for await (const chunk of stream) {
  tracker.ingest(chunk);
  process.stdout.write("\r" + tracker.render());
}

That gets you a live indicator in ~20 lines. It won't fix Codex Desktop itself, but it works in any wrapper you control — CLI, TUI, Electron, whatever.

For Codex Desktop specifically: check if you're on a canary channel. Roll back to the previous build via the installer and confirm the indicator returns. That tells you it's a regression, not a config issue. Then file it — the issue you linked is already open, so drop your version string and platform there.

This sucks. I know. Losing observability right when you need it most is the worst kind of regression.

The bigger problem

Manual tracking works until you have nested agents, tool calls, and retries. Then your token math gets messy fast. You're summing across spans that don't share a parent, double-counting retries, and missing the tool-call overhead entirely. The indicator you built says 40% when you're actually at 90%.

Guess what happens next? The agent truncates mid-task and you don't know why.

TracePilot handles this at the SDK layer. Every LLM call and tool invocation gets a span with its own token count and parent link. You get a real context-pressure number per agent run, not a running sum you have to maintain yourself.

One line change:

import { TracePilot } from 'tracepilot-sdk';

const tp = new TracePilot('tp_live_YOUR_KEY');
await tp.startTrace('codex-session');

const { result, spanId } = await tp.wrapOpenAI(
  () => openai.chat.completions.create({ model: 'gpt-4o', messages, stream: true }),
  messages
);

Open the dashboard. You'll see token usage per span, latency, and the full execution tree. If a step blows past your context budget, you fork it right there, edit the prompt, and replay — no redeploy.

The Codex indicator will come back eventually. Until then, don't wait on the vendor to give you visibility into your own spend.

---

Debugging AI agents shouldn't feel like reading The Matrix.
Join other engineers who are building reliable autonomous workflows in our community: TracePilot Discord