What the loop costs, and the free path

The three costs, only one of which appears on an invoice

Tokens. An agentic session re-sends its context on every turn. A 2,000-line source file is roughly 25,000 tokens. Forty turns that keep re-reading it is a million tokens of input, for one afternoon, on one file. Prices change constantly, so learn the shape rather than the number: input is much cheaper than output, cached input is much cheaper again, and a session that keeps a large context alive costs a multiple of one that works from a narrow slice.

The practical control is scope. Give it three files, not the repository. Most of the cost in a runaway session is re-reading things that were never relevant.

Latency. A thirty-second round trip, sixty times a day, is half an hour of standing still. It does not appear on a bill and it is often larger than the token cost in money terms. The fix is batching: ask three questions in one message, not three messages. Fewer, larger turns is both cheaper and faster.

Attention. The one nobody prices. Every generated block is a decision to make, and decisions are the fatiguing part of the day. A session that produces nine things to evaluate costs more of you than one that produces two, even if the token bill is identical.

The rough shape of the money

At the time of writing, per-seat assistant subscriptions sit in the range of a few tens of US dollars a month, and metered API use for heavy agentic work can exceed that comfortably for a single active developer. Both numbers have moved repeatedly and will move again, downward per token and upward per session as tools use more context, so any figure printed here is a snapshot rather than a fact.

What is stable is the comparison. Against a developer’s fully loaded hourly cost in a high-income market, the tool is cheap and the argument is about whether it works, not what it costs. Against a developer’s cost in a lower-income market, the same subscription can be a significant fraction of a salary, and the free path stops being a footnote and becomes the main road.

The free path, concretely

Open-weight coding models run on your own machine. The two common runners are Ollama (one command to install, one to pull a model) and llama.cpp, which is what Ollama is built on and which gives more control. Both are free and both run on ordinary hardware.

ollama pull qwen2.5-coder:7b
ollama run qwen2.5-coder:7b

A quantised 7-billion-parameter coding model needs roughly 5 to 6 GB of memory and runs at usable speed on a laptop with 16 GB of RAM, with no GPU, though a GPU makes it several times faster. The Qwen coder line, the DeepSeek coder line, Codestral and the StarCoder lineage are all in this space; which one is best changes every few months and any specific recommendation here will date badly.

Editor integration is free too. Continue and similar extensions connect a local model to VS Code, JetBrains editors or Neovim. Several hosted assistants also have free tiers, including for students and open-source maintainers, though the terms move.

The limitation. A local 7B model is close enough on completion, boilerplate, format translation and explanation. It is meaningfully worse at holding several files in mind at once, at long chains of reasoning, and at noticing that your codebase already contains the helper it is about to rewrite. The gap is real and you should not let anyone tell you otherwise. Compare it against the task list from the previous lesson: the local model covers the large-payoff column almost entirely, and falls behind in the column where you should be doing the thinking yourself.

The privacy dividend. A local model means the code never leaves the machine. For a contractor bound by a client agreement, an employee at a firm with a strict policy, or anyone working on something regulated, that is not a nice-to-have. It is the difference between using the tool and not.

The tools that were always free and are now worth more

This is the part that gets skipped in every discussion of cost.

Your compiler. Your type checker. Your linter. ripgrep. git bisect. A profiler. A property-testing library. A database constraint. None of these cost anything, none of them need a GPU, and every one of them is an oracle that runs on every change for ever.

In a world where producing plausible code is free, the tools that mechanically reject wrong code went up in value, and they are the cheapest things in your stack. A team with a strict type checker and a good test suite gets more out of a cheap model than a team with neither gets out of an expensive one. That is not a consolation prize for people without budget. It is the actual ordering of what matters.