Every concept the week introduces, and the day it arrives
Use ← and →, or the dots at the top, to move between days. p switches between reading size and presenting size.
One page for the whole week, so that “how do I set the reasoning effort” does not depend on remembering which afternoon it came up. It fills in as the week goes: day 1's three are below, in full, and everything after them names the day it arrives.
| day | what it adds |
|---|---|
| 1 | the loop — chat, agent, harness · context · cold start and the project-instructions file |
| 2 | models · reasoning effort · benchmarking · headless |
| 3 | a written objective and /goal · permissions
· what it costs and how long |
| 4 | teams and roles · an independent verifier · rounds · steering · skills |
| 5 | hooks · a paper written for a machine to read · the same idea in your own directory |
The flags change every few months.
claude --help and codex --help are the current truth;
what is here is the part that does not rot.
Day 1
Text in, text out. It cannot see your files, run anything, or check itself. Whatever it says about your data is a guess about your data.
The same model, in a loop, with tools: read a file, write a file, run a command, look at the output, decide what to do next. That loop is the entire difference.
What is around the agent: permissions, project instructions, skills, hooks, subagents (agents the agent launches), jobs. The part you configure — and the part that makes it yours. Each piece gets its own day this week.
Two modes, and you will use both:
Interactive. You watch, you steer, you interrupt.
This is what you are doing while the room is running.
Headless / jobs. Fire it at a bounded deliverable and walk
away. claude -p, codex exec, or a whole team of agents
on a job.
Day 4 is the one that does this at scale.
Everything the model can see right now — your instructions, the files it has read, the commands it has run and their output — is one flat block of text. It is finite.
What fills it. Long files. Verbose command output. A 200-line traceback. A PDF. Twenty rounds of trial and error.
What happens when it fills. It gets summarised. Detail is lost, and you do not choose which detail. Quality degrades in a way that is hard to notice from the outside.
Look at it. Both harnesses will tell you how full it is and what is taking up the room:
/context what is in it, and how full /compact summarise and keep going /clear throw it away and start clean
/status session and token usage /compact summarise and keep going /new a fresh conversation
The practical skill is not writing clever prompts. It is deciding what deserves to be in context: keeping tasks bounded, starting fresh when the thread is spent, and writing things to disk rather than carrying them in the conversation.
Run /context now, and again when your run finishes.
When it is nearly full, believe less of what you read.
The other half of the same fact. A TURN is one step of the loop: the agent acts, sees what came back, and decides what to do next. Every turn sends the whole conversation again, from the beginning — the model holds nothing between turns, so there is nothing else it could do. Five consequences follow, and they are the ones you meet on an invoice.
/clear costs you the setup again and nothing else, which is
usually a few thousand tokens against the hundreds of thousands you are carrying.
Start fresh when the subject changes.Two of our own runs, from later in the week. Each is one task, run once, headless.
Two runs from later in the week, as each one recorded itself. Each is one task, run once, with nobody watching.
day 2 day 3 model claude-opus-5 claude-opus-5 effort xhigh xhigh turns 132 242 tokens in 19,475,555 58,906,227 tokens out 169,476 235,493 of the input, a cache read 19,213,028 58,560,011 in, per token out 115 250 cached share of the input 98.7% 99.4%
Read the last two rows. Roughly a hundred times more went in than came out of the first, and about two hundred and fifty times on the second; and in both, near enough all of the input was a cache read rather than text the model had not seen. That shape — a small amount written, an enormous amount re-read — is what a conversation of a few hundred turns looks like, and it is why the two levers that matter are how much you put in front of it and how often you start again.
Token counts rather than prices, deliberately: a price is a fact about a price list on the day, and these two were measured in August 2026. The ratios are the durable part.
Close the terminal and it is gone. Tomorrow the agent knows nothing about today — not the conventions you agreed, not the bug you found, not why you rejected the obvious approach.
There is exactly one fix: write it down, in the project, in a form the agent will read next time.
Project instructions. CLAUDE.md /
AGENTS.md at the root. Conventions, layout, what not to do. Read
automatically at every start.
A record of the work. What was tried, what it cost, what the answer was — the receipt that sits beside the code, saying it ran, on what date, in which environment, and how many checks passed. An exercise without one is a plan.
A useful test: if you were hit by a bus, could a stranger — or a fresh agent — pick this project up from what is on disk? That is the same question, and it has been good practice since long before any of this.
Day 2
Day 1 names these while showing somebody else's work. Day 2 is where they are actually turned, on a task the whole room runs.
Models.
Reasoning effort.
Benchmarking — the same task, run several ways, scored the same way.
Headless.
Day 3
All three arrive together because they are the same situation: you are not watching.
A written objective, and
/goal.
Permissions — because you are leaving.
What it costs, and how long.
Day 4
Teams and roles — a lead that plans and assigns, workers in parallel, and a verifier. Each with its own model and its own depth: put the verifier on a different model family from the workers and the check stops being the same model marking its own homework.
An independent verifier — and the
question of whether what it finds ever reaches the round that has to act on it. Read
reports/ and transcript/, not the deliverable.
Rounds — a bounded run that stops and hands the decision back. The budget is an input the lead plans against, not just a cost; a run can always be resumed, so what it dropped for lack of room should be written down rather than lost.
Steering — job say while
it runs, job resume, job freeze. Check that a direction
arrived; it is read at the start of a round and not before.
Skills — a procedure written down
once, loaded when it is relevant. It is why a fresh session knows the tool exists at
all: install puts the same SKILL.md into both harnesses, and cloning
without it does nothing.
Day 5
Hooks — a command the harness runs at
a named moment, whether or not the agent thinks of it. Day 5's fires at
Stop, when the agent decides it is finished: it checks what was left on
disk, and a non-zero exit puts its message into the conversation as a new turn, so
the agent is not finished after all. A skill is loaded when the session thinks it
applies; a hook runs regardless, which is what it is for. Both tools have the
event, and Codex will not run a hook you have not trusted in /hooks.
A paper written for a machine to read
— a repository whose claims.yaml states the thesis and one record
per claim with its evidence named, whose prose carries a key beside every number,
and whose check_provenance.py refuses the build when the paper, the code
and the data stop agreeing. What a reader used to reconstruct by guessing, stated
once, and checked.
The same idea in your own directory —
the convention in .md files, written once; a skill that points at them;
a hook that checks the result and, on failure, serves the .md that
applies. Nothing restated. Add a check, write its .md, and both routes
get it.
Each stub was filled by the day that introduced it, in the words that day used, and this file is where they all ended up. It is the answer to the question day 1 asks: what you still have when the week is over.