We stopped letting the chat model write code. The bill told us why.

Bottom line up front: a chat-plan model is the most expensive possible way to generate code. A scheduler agent plus a flat-rate IDE is a little dearer per task and much cheaper per week, because it stops the thing that actually burns money: rework. Here are our receipts and the split we landed on.

The bill that started the argument

Last month our token plan hit its wall once a week. Not twice. Once, like clockwork, usually a Thursday evening, with the API replying 429 insufficient_quota and the agent going quiet until the rolling window reset.

We were paying per-token prices for code the IDE would have written for free. The fix was not buying a bigger plan. It was noticing that a huge share of our tokens went into one specific job: writing code inside a conversation window.

The split

The machine room has two boxes. A 35W mini PC that never sleeps runs the scheduler agent (Hermes): it browses, files tickets, checks receipts, runs the cron jobs. A workstation with a 5080 does the building. Between them sits a Syncthing folder.

The interface between the two is not chat. It is a file:

• ticket the scheduler writes: target behavior, which files may change, which files are off-limits, and the acceptance signal (which test passes, which screenshot looks like what)
• work the IDE does against that ticket, with a human steering the parts that need taste
• receipt back through the same folder: file path, checksum, diff, screenshot
• verdict: the scheduler checks the receipt against the ticket, line by line, and either closes the task or bounces it with the clause it failed

The scheduler does not touch the code. The IDE does not write tickets. That division is the whole trick.

What we gained

Drift went down. Chat-based coding fails in a specific way: by turn five nobody remembers that turn one said “do not touch the schema.” The code runs, and nobody can say what it runs. A ticket is a document that cannot get amnesia. Deviation stopped being invisible and became something a check catches. The bounce rate tells you it works: a rejected receipt costs one short round trip, while a wrong merge costs a debugging evening.

Control. Every task leaves paper: the ticket, the receipt, the verdict. When I ask “who decided to rename this field,” the answer is a file, not a memory. In multi-agent work that is the difference between a system and a haunting. I can watch everything it does, and nobody has to ask.

Compounding. After a job of a new kind, we write two artifacts: a short tutorial and one SOP line. The next ticket of that type reuses the skeleton. In chat mode this knowledge evaporates with the window; here it goes back into the machine that reads it next time.

What it still costs

Three honest bills.

1. Orchestration burns tokens that writing code never asked for. Read the request, write the ticket, parse the receipt, check the screenshot, chase the deadline. Every one of those is a model call. We measured it against our old way: about 3 to 4 times more messages per task than the IDE chat alone. On a metered plan that is real money. We fixed it by routing all scheduling to the small flash model and keeping the large models for work with taste in it. That is a cheap answer to a problem that had an expensive shape.

2. The gate costs my attention. A flow with explicit checkpoints demands checks. We ran our review gate too narrow for a while and watched finished drafts pile up in a published folder, waiting for one human to read them. Output capacity meant nothing; the bottleneck was a chair. Make review cheap or make it parallel. We now write review material so I can pass on a batch in ten minutes.

3. Small jobs lose. One config line, one typo, one quick lookup. Routing that through a ticket plus a receipt takes half an hour and earns nothing. There is a break-even point and we should not pretend otherwise. The split pays when the task has a name, a boundary and a definition of done. Below that, open the editor and type.

Where we put the line now

Worth a ticket: work that spans a day, anything with an acceptance test, anything that must leave a record, anything we will do again. Straight chat: throwaway patches, exploration where I do not yet know what “done” means, chores I could do faster with my hands.

The number

Writing code against a metered chat plan was the single largest item in our quota, and it was also the work a subscription covers without counting. Moving it was worth roughly a quarter of our monthly spend. The remaining orchestration load is not free, but it is now billed to the right meter: small model, cheap tokens, and no Thursday wall.

If your token plan dies every week, do not upgrade it first. Read the log and ask what those tokens were writing. If the answer is code, the fix is not a bigger plan. It is a different box.