There is no conversation

A lesson from Working With AI. Play it above, or read it through below.

• There is no conversation. There is one input, rebuilt.

  The common read: The conversation lives on their server and I am adding to it, so my twelfth message costs about what my first one did.

  Nothing is stored. The Messages API reference says the endpoint serves "either single queries or stateless multi-turn conversations", and stateless is the operative word: there is no session on the other side, no thread id, and nothing to append to. What creates the appearance of a conversation is that your client re-sends the entire history as an array on every request, and the reference says so in the same paragraph.

  Read the shape rather than the product. You specify the prior conversational turns with the messages parameter, and the model generates the next message from that array, together with the tools and system text this lesson accounts for later. The array is your data structure, held by your process, serialised and posted whole each time. Twelve turns is twelve requests, and the twelfth one carries every byte of the previous eleven along with the new question.

  Loop has been talking to the model for an hour and feels understood. Loop has been paying, every single turn, to re-explain everything Loop has ever said. Loop is not understood. Loop is subscribed.

  That arrives as a bill nobody can account for, filed against the model as "it got more expensive this month", on a team whose usage in requests is flat and whose usage in tokens tripled. The requests were long threads, and long threads are quadratic. Price a thread before you open it: cost is the sum of every prefix, so a fifty-turn session is not fifty times a one-turn session, it is roughly thirteen hundred times one turn.

• Nothing leaves because you asked it to

  The common read: Telling the model to forget something takes that something out of what gets sent, so a correction is a repair rather than an addition.

  A correction is another message. The array grows by one entry, the entry says to ignore an earlier entry, and the earlier entry is still sitting there in full, byte for byte, on every request from then on. Nothing in the API removes a message from an array your process owns, and the reference is explicit that consecutive same-role turns are merged rather than replaced.

  The reason the correction seems to work is worth stating flatly, because it is what makes the wrong model survive. Recency is not in the protocol, and it is not a rule the API enforces; it is the observed behaviour of models on inputs that contradict themselves. A recent, specific, unambiguous instruction usually wins over a stale contradicting one, and it wins for exactly as long as it stays recent.

  Twenty turns later the instruction and the thing it corrects are both mid-thread, both stale, and the model is emitting an answer conditioned on two pieces of text that contradict each other and carry no metadata separating them.

  That arrives as a report that the assistant "keeps going back to the old approach", filed against the model's memory, by an engineer who did in fact tell it three times. Deletion is the only lever that behaves the way people think correction behaves. Edit the array or start a new one, and treat every "actually, ignore that" as what it is: two contradicting facts in the input, with the outcome decided by position rather than by intent.

• Three things ride along, in one fixed order

  The common read: Tool definitions are registered with the model once at the start of a session, so a big tool surface is a setup cost rather than a per-request cost.

  Name the three parts of the prompt in the order they are assembled, then read on. Tools, system, messages. The prompt-caching page states that order as a hierarchy where each level builds on the previous ones, and the ordering is the useful half: everything you think of as configuration sits AHEAD of everything you think of as the conversation, and all of it is text the model reads on every single request.

  The size of that first segment is the part nobody measures. Anthropic's own engineering write-up on code execution with MCP reports fifty-eight tools consuming approximately 55K tokens before a conversation starts, and says that internally at Anthropic tool definitions were measured consuming 134K tokens before optimisation. Those are Anthropic's numbers about Anthropic's systems, published 2025-11-24, and they are an existence proof rather than a benchmark.

  That arrives as an agent that has become "slow and stupid since we added the integrations", filed against the model version, on a setup whose only change was two more MCP servers in a config file nobody re-read. Count your prefix before you tune your prompt. The tools and the system text are the part of the input you can measure exactly, they are identical on every request, and they are the cheapest thing in the whole system to cut.

• A bigger window did not make the model read better

  The common read: The window is a container, so anything that fits is available, and filling it is free until it overflows.

  Predict what happens to recall as a context window fills, then read on. It falls. Anthropic's context-engineering write-up names this context rot and states the finding plainly: as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases. The same post gives the architectural reason, that every token attends to every other token, so n tokens carry n squared pairwise relationships.

  The post is careful about the shape of the curve and this lesson is careful with it too. It reports a performance gradient rather than a hard cliff: models stay highly capable at long contexts and may show reduced precision for retrieval and long-range reasoning compared with shorter ones. That is a vendor describing its own models, published 2025-09-29, and it is the most consequential sentence in this lesson because it says the failure is gradual, unsignalled, and therefore invisible in exactly the sessions where it matters.

  That arrives as a session that "was going great and then it started making things up", filed against nothing at all because there is no error, on a thread that crossed no limit and threw no warning. Anthropic's own formulation is the one to act on: find the smallest possible set of high-signal tokens that maximise the likelihood of the outcome you want. Minimal is not short, and the same post says so; the target is signal per token.

• Four levers, and only one of them is free

  The common read: A summary keeps everything that mattered and drops only the noise, so compaction is strictly better than starting over.

  Compaction is lossy by construction and the loss is chosen by a model. Anthropic states the trade in its own words, that the art lies in selecting what to keep against what to discard and that over-aggressive compaction loses subtle context whose importance only becomes apparent later, and states elsewhere that compaction is not sufficient on its own for long-running work. Nothing about that is a defect; it is what summarising means.

  Four levers exist and they price differently. Starting a fresh thread is free, instant and total, and it costs you everything you have not written down. Compaction keeps the flow and pays in unpredictable gaps. Writing the durable facts into a file the agent reads costs you the discipline of maintaining the file and pays back on every future session. Referencing a path instead of pasting a body costs a tool call and buys a value that is current rather than a snapshot that is stale.

  That arrives as a fourth attempt at the same task that goes worse than the first, filed as "it used to be better at this", by someone who has been in one thread since Tuesday. Externalise before you compact. The decision the levers actually pose is which facts must survive a summary, and once you can name those, the cheapest correct move is to put them somewhere a summary cannot reach and then start clean.

• The first thing Nightshift needs is a file

  The common read: Getting good at this is about writing better prompts, so the work is in the wording of the request I am about to send.

  Of everything that reaches the model on one request, name the part you actually spent this lesson on, then read on. Not the wording. Everything here was about the rest of the input: the tools ahead of it, the instructions ahead of those, the eleven turns behind it, and the file you pasted on Tuesday.

  Anthropic's own framing of the shift is that building with language models is becoming less about finding the right words for prompts and more about what configuration of context is most likely to produce the behaviour you want.

  This course builds one thing across six levels. It is called Nightshift, it watches your Downloads folder, and at 06:00 it writes ~/nightshift/brief-YYYY-MM-DD.md with three sections: what arrived, what needs you, and what it did. It has no code yet and that is deliberate. Its first artifact is a file that says what a good verdict on one downloaded item looks like, because that file is the durable half and the prompt around it is the disposable half.

  The version of this failure that never gets filed is the one where a thread goes well, the engineer learns something real about their own system inside it, closes the tab, and starts the next session by explaining the same thing again. Write down the part that would survive a summary. That is the whole discipline, it costs one file, and every technique in the next five levels is an answer to the question of what belongs in it.