Course · Codex · Sessions & context

Inspect the context window with /status

You compacted last lesson on a hunch - the agent felt hazy, so you assumed the conversation had grown too big, and you were right, this time. But “felt hazy, assumed, compacted” is a ritual - it doesn’t actually diagnose anything - and rituals fail you the first time the guess is wrong. A model doesn’t get tired and it doesn’t have bad days; what it has is a context window that gets full. When the agent goes vague, re-reads a file it already read, or forgets a convention it was following an hour ago, that’s almost always a saturated window felt from the outside - and the fix depends entirely on what filled it. Before you spend another /compact on a guess, it’s worth being able to see the budget instead of assuming it.

That’s the idea worth naming before you meet the command: treat the window as a budget, not a mood. A budget has a statement you can read, a set of purchases you can itemise, and a balance you can check before you spend more. Every file Codex reads is a purchase against it. /status is the statement.

Reading the gauge

/status     # what's loaded in this session right now

/status lays out the state of your session - including what’s occupying the context window and how much room is left. The point is that it turns the vague feeling into specific facts. The conversation has grown large after a long refactor; a file you pulled in is heavier than you realised; the window is closer to full than it felt. Whatever the cause, you stop reasoning from a symptom and start reading the actual breakdown:

> /status

  Session · budgetcli
  Context window      ~62% used        ← the conversation, post-refactor
  Model / effort      [your configured settings]
  Approval / sandbox  [your configured policy]
  ...

The exact layout and labels are the kind of detail that shifts between releases, so check the Codex docs for the current readout rather than trusting any one screenshot - including this one. What’s stable is the use: when the agent feels off, /status is how you find out whether the window is genuinely full, and roughly what’s responsible, before you act.

What the readout teaches you to notice

The first habit it builds is catching a single careless read. Here’s a purchase you can price exactly, using chapter 1’s own estimator: ask Codex to “read the whole test suite” and all 1,240 lines land in context in one move - 12,400 estimated tokens, or 6.2% of a 200,000-token window, spent on a single call before the conversation itself has grown at all. Watch the window jump by that much right after one read and that’s usually the culprit, not the slow accumulation of the conversation. The fix isn’t to compact; it’s to point the agent at the specific function or file you actually need next time, rather than turning it loose on the whole tree.

The second is that the conversation is only one line item on the statement. A session also carries its system prompt, your tool definitions, whatever you’ve loaded from AGENTS.md, and - once you start connecting them in a later chapter - MCP servers, whose tool schemas sit in the window from the start whether or not you ever call them. /status is how you notice when something other than the chat is the heavy line, so you don’t compact the conversation to fix a problem the conversation didn’t cause.

You can rehearse that reading without burning a real afternoon on it. Step through this simulated session and watch the gauge move - the overhead that’s spent before you type a word, the schemas that land when servers connect, one careless read eating a double-digit percentage of the window in a single call, and what a compaction actually keeps. The numbers here are illustrative, built to show the shape of the readout, not a claim about any one budgetcli session:

That distinction is the whole reason this lesson sits where it does. Last time, compaction was the right call - the conversation genuinely was the biggest line on the statement. But if /status had shown the conversation small and the test-suite read as the 6.2% spike, compacting would have ground away your working context to fix a problem a narrower read next time would have avoided. Diagnose first, then choose the fix: /compact when the conversation is genuinely the problem, a tighter read next time when one file blew it up, dropping a server you’re not using when that’s the weight.

From feeling to gauge

The real shift here isn’t a command, it’s a stance. An opaque “the context just fills up” breeds superstition - restarting at random, blaming the model, inventing little rituals like the one you ran last lesson. The moment the window has a statement instead of a mood, the right move is usually obvious from what you read: conversation too big, compact it; one file too big, read narrower; switching tasks entirely, reset.

So make /status a reflex at task boundaries - finished one piece, about to start the next - not just a panic button for when things already feel broken. Caught early, a filling window is one deliberate move from fixed. Caught late, you’ve already spent an hour getting worse answers for a reason you never checked.

One honest limit: /status tells you what’s spent, not what’s coming. It won’t warn you that the next file you’re about to ask for is another 6.2%-sized purchase - that judgment is still yours, made with the estimator, before you ask. The gauge is for reading the balance, not for predicting the next charge.

And that last option from the last two paragraphs - switching tasks entirely - is exactly where the day is headed. The cents refactor is done, the categoriser’s in, the reports endpoint reads integer cents now. The next thing on your list has nothing to do with any of it. You don’t want to compact this thread and you don’t want to drag it forward; you want it gone, cleanly, so the next task starts in a window that holds no opinions about money handling. That’s how to reset without losing what mattered.