Course · Codex · Sessions & context
Sessions & context
Last chapter ended on a number: budgetcli’s whole source is about 62,000 estimated tokens, 31% of a 200,000-token window, and you could hand Codex every line of it in one message. You still shouldn’t - that’s exactly where chapter 1 left the question open. Here’s the answer this chapter earns: the window isn’t tight because the repo is big. It’s tight because a real week of work never stays as small as one repo, and nothing about the window empties itself.
That’s this chapter’s slice of the villain running under the whole course: the context window is the only thing Codex knows on any given turn, and every turn spends some of it. Read a file, the window shrinks. Talk for an hour, it shrinks. Nothing in this chapter adds understanding for free - which is the tension every move below turns on: everything that keeps a session’s understanding alive costs you window, and everything that reclaims the window costs you some of that understanding. No command escapes the trade. Each one just makes it on purpose instead of by accident.
Feel the shape of that before you meet a single command. The refactor this chapter follows touches three files whose size you already know from chapter 1’s estimator: the importer (csv.py, 2,100 estimated tokens), the models (models.py, 3,400), and the test suite (12,400). Read all three once, before you’ve typed a single instruction, and you’ve already spent 17,900 tokens - about 9% of the window - on nothing but finding out what’s there. Multiply that by a week of turns, on top of the conversation itself, and the “just fits” repo from chapter 1 stops mattering. The repo was never the problem. The session is.
The week we’ll follow
Section titled “The week we’ll follow”You inherited budgetcli last chapter - a friend’s weekend FastAPI budgeting service - and shipped your first reviewed fix. The real work starts now, and it spans days:
- This morning you come back to yesterday’s session and pick it up without re-explaining a thing.
- You hit a design fork - two ways to categorise transactions - and explore both off a shared starting point instead of betting on one.
- A small tangent jumps the queue mid-task, and you handle it without derailing the thread you’re in.
- You let the agent run long on a money-handling refactor, the window fills, and you reclaim it in place instead of starting over.
- The agent starts feeling dull, and you learn to see exactly what’s eating the window instead of guessing.
- And when a line of work is genuinely finished, you reset cleanly instead of dragging its residue into the next thing.
Each lesson adds one move and leaves you with the problem the next one solves. Read them in order and they’re a story; land on one from search and it still stands on its own.
By the end you’ll treat the context window the way you treat memory in any program you write: a resource you watch, spend on purpose, and reclaim before it runs out. That habit, more than any single command, is what lets a week of budgetcli work survive on your own financial data without the agent going hazy on you.
Start where the week does - picking up yesterday’s session.