Course · Codex · Sessions & context

Inspect the context window with /status

The agent feels vague, re-reads files, or drops a convention it followed an hour ago. That pattern often means a full context window, not a “tired model.” Before you /compact or restart on instinct, read the balance.

A session is the saved Codex conversation in your current run. The context window is everything loaded for that session: transcript, reads, tool output, system and tool definitions, and project instructions such as AGENTS.md. /status reports aggregate usage and remaining capacity; it does not itemize every block.

Reading the gauge

> /status

  Model           [your configured model]
  Directory       ~/code/budgetcli
  Permissions     workspace-write, on-request
  Agents.md       AGENTS.md (project)
  Token usage     8.4k total (5.9k input + 2.5k output)
  Context window  71% left - 58k of 200k used

An illustrative reconstruction, not a captured screen; exact labels shift between releases.

What /status does not do matters as much as what it does. There is no per-category breakdown, no conversation-versus-reads split, no ranking of the heaviest single read. It answers how full, not what exactly filled it. Finer attribution is yours: what you asked for, file sizes, /mcp for connected servers, and the size of your rules chain. A native itemized breakdown is proposed for the CLI, not a shipped command.

Treat the window as a budget, not a mood. Every read and every turn spends against it. /status is the fuel gauge.

Course estimators (illustrative, not Codex measurements)

This course uses simple assumptions to reason about reads, not numbers Codex prints:

About 10 tokens per line of code for rough sizing.
About 4 characters per token for prose.
A 200k-token window as a round capacity figure for mental math.

On budgetcli (the course’s running example, a small self-hosted personal-finance API in Python and FastAPI: 166 lines of Python and about 230 lines including tests, config, README, and AGENTS.md), the whole tree is on the order of 2,000 estimated tokens, well under one percent of 200k. Careless “read everything” habits are cheap on that tree and expensive once the repo and session grow. The simulator below uses the same illustrative magnitudes to show overhead, MCP schema cost, one oversized read, and what compaction might keep. Step through it to rehearse diagnosis without burning an afternoon; totals are illustrative assumptions, not claims about your live session.

Step 1 / 11Session start

Illustrative simulation: window size, token counts, and compaction threshold are assumptions, not measurements of your session.

17k / 200k tokens (9%)

simulated threshold 80%

Click any segment of the bar - or a legend chip below - to see what it is.

This simulation starts with 17k tokens assigned to system instructions, loaded tool definitions, and a rules file. Those values are teaching assumptions. The rules are the part the project author supplies.

A lean rules file pays rent every single turn.

Use the gauge with its grain. Window full but the chat is short? Suspect rules, MCP, or large reads before compacting. Window full and the transcript is the obvious bulk? /compact may fit. The gauge tells you whether; your notes tell you which.

Make /status a habit at task boundaries (finishing one piece, starting the next), not only when quality already slipped. The gauge does not predict the cost of the next file you are about to ask for; that judgment still uses the estimators before you prompt.

When the next task is unrelated and you want the old thread gone, not thinner, see reset.