Harshavardhan Katkam

Agreed, and it's a point the series runs into head-on. One clarification on Day 03: the repo size is only the up-front estimate. The meter itself records the usage the server reports on every request, so whatever is in the transcript gets counted, tool outputs included. Neither side of the ledger is guessed. You're right about where the pressure moves, though. Once the agent can call tools (Day 06), file reads pile up in the transcript and soon outweigh everything else. Day 08 is about exactly that: tools that return a bounded slice of a file instead of the whole thing. A later memory day handles what to drop from a long transcript without breaking it.

Good question, and an honest answer: not yet. The Day 03 meter keeps running totals only (calls, input tokens, output tokens, cost), because the point that day was the first number, not the breakdown. You're right that a total hides where the cost came from. Here, almost all of it is the transcript being resent on every call. The breakdown comes later in the series. A LangGraph day counts calls per node and per run. The tracing day records each model call as its own span, with its usage, so you can see which step resent what. On drift: every measurement is recorded with the model and the commit it was taken at, for exactly that reason.

Thanks! The measured number surprised me too: on the free model I'm using, code came out at about 2.58 characters per token, well below the usual rule of thumb. That's why the ratio gets calibrated, not assumed. Next up, Day 04: making the model return structured output instead of prose I have to parse.

Thanks, Kartik. Yes, and you've named the exact case. Next up is Day 01, the 40-line loop. Day 06 hand-rolls tool calling and breaks it on purpose: a tool name the model invented, arguments cut off mid-JSON, a parameter that doesn't exist. None of them crash the loop. Each one goes back to the model as the tool's result, an error message listing what's valid, so it can correct itself on the next turn. Day 04 covers the same idea for the final answer: a strict schema instead of parsing prose. And glad "fluently wrong" landed. It's the one idea I'd want a beginner to keep.

Thanks! Real codebases are the point. Day 07 is the first full run, on a well-known open-source Python project pinned to one release, so anyone can reproduce the result and check the map against the actual source. Later it gets scored against a second project too.

Thanks, Kartik. The stop-reason trap is a good one; a truncated answer that looks finished is exactly the kind of bug the series is about. Tool-call failures are handled in week one, not deferred. On day 06 a bad call doesn't crash the loop: an invented tool name, arguments cut off mid-JSON, or a wrong parameter go back to the model as the tool's result, an error message listing what's valid, so it can correct itself next turn. The loop is also capped at a fixed number of turns, so a model that keeps calling tools can't run forever. Week four's hardening (day 28) is about the failures that don't raise anything: a run that finishes cleanly with a map that's quietly wrong. On truncation: day 05 sets max_tokens so a cut-off answer surfaces as malformed JSON rather than passing as finished. You've convinced me it's worth checking finish_reason explicitly as well.

Thanks, Julian. That's exactly the bet. Once you've written the loop yourself, a framework stops being magic and becomes a set of choices you can judge. That's why LangGraph only shows up in week 3, after the hand-built version has already hit the problems it solves. Curious which part of the loop fought you hardest?

Agreed, and that's the bar I'm holding it to. From day 01 the loop only counts a step when a tool result comes back, and the map has to point at what it read: a file and a line, not a summary of a summary. What I'd refuse to call done on day 30: a map whose claims don't cite a file and line the agent actually opened a "better" version that hasn't been scored against the eval set any version that can write to the repo it's reading. It writes docs, never code. If it can't show its evidence, it's narration, and you're right that 30 days of that would teach the wrong thing. Thanks for pushing on it.