I Hit My Claude Code Budget Mid-Feature: Here Is What Happened Next

Task 4’s review round was still running when the month’s API spend cap hit. Six tasks were left on the plan for a feature I was in the middle of shipping. I finished them by hand, no subagent review, same bar I’d been holding for the first three. That gap, the one between “the process broke” and “the feature shipped anyway,” is more interesting than the feature.

The shape of a build session that isn’t a prompt and a hope

The feature was Local Waifu’s adaptive personality dials, ten numbers that tune how a character behaves from how you talk to her. I did not open an editor and start typing. The session ran: a design doc, a self-review pass to close gaps in that design before any code existed, then a ten-task implementation plan with each task scoped small enough to review on its own. Tasks 1 through 4 ran as implement, then a separate review pass against the spec, then the next task only after the review passed.

That structure is the whole point. A task plan turns “did the AI do a good job” from a feeling into a checklist: does this match what the design doc said, does it have tests, does it handle the edge case the spec named. A vague prompt produces a vague sense that the output looks right. A written spec produces a yes or no.

What “the loop caught something” looks like, with the receipt

Here is the one that mattered. The design specified that a dial’s confidence score drops by 0.20 on disagreement between the two systems that propose changes to it, clamped at a floor of 0.0. Confidence going negative would mean the number meant to track “how sure are we” reads as more certain the more evidence contradicts it, backwards from what it’s for.

Task 2’s first implementation dropped the clamp. Confidence could go negative after enough disagreements in a row. The review subagent checked the diff against the spec line, caught the missing .max(0.0), and flagged it. The implementer fixed it in one line, the reviewer re-verified, task 2 closed. Commit b8447f6.

I want to be precise about what this is and isn’t. It’s a small, mechanical bug: a spec said clamp, the code didn’t, a decent test suite would probably have found it too, eventually. It isn’t proof that AI review catches everything, or that it catches things a human wouldn’t. It’s proof that on this specific task, with this specific spec, the loop did the one job it exists for.

The loop is not free, and task 4 is where it stopped

Nobody puts this part in the “AI built my whole app” threads. The review round for task 4 was mid-pass when the session hit the month’s spend cap. That’s a real constraint, not a hypothetical one: a review loop means twice the model calls per task at minimum, implement plus review, and a long enough feature will eventually run into whatever ceiling you’re operating under.

The plan still had six tasks on it. I could have stopped and picked it up next month. I didn’t, because the six remaining tasks were consumer wiring: hooking the already-designed dial values into the style prompt, the proactivity scheduler, the memory recall bias. Smaller, more mechanical, less room for a spec-versus-implementation gap to hide in than task 2’s confidence math had.

Building without the reviewer: same bar, held by hand

Tasks 5 through 10 got implemented directly. No subagent review round. What replaced it was three things I did myself, in order, every time: run the test suite, run the linter, then reread the diff as though someone else had written it and I was the one checking it against the spec.

Zero bugs surfaced in that second half. All tests passed, clippy stayed clean, nothing needed a second pass. I’m not framing that as “so the review loop was unnecessary all along.” Task 2’s confidence math was the one place in the whole plan where a subtle spec detail (clamp at zero, not just decrement) was easy to drop and hard to notice by eye, because the code runs and produces a number either way, just occasionally the wrong one. The later tasks were wiring: either a value reaches the consumer or it doesn’t, and that kind of miss is loud, not subtle. The loop earning its cost on task 2 and not being obviously missed on tasks 5 through 10 are both true at once, and they’re evidence for the same conclusion: spend the review pass where a mistake would be quiet.

The same discipline, pointed at an AI’s suggestions instead of its code

A few days before this build, I ran CodeRabbit over the entire codebase, not a diff, the whole thing. 162 findings: 3 critical, 80 major, 79 minor. The instruction I gave myself was “check each finding in order, and if it’s true, fix it,” which sounds obvious until you notice what it rules out: applying findings because a tool flagged them.

A handful weren’t real. One finding wanted a mic-test lock reserved earlier than the code already reserved it, based on a misread of the actual guard’s lifetime, verified and left alone. Two of CodeRabbit’s suggested fixes I deliberately didn’t take as written: one touched a deliberate default I’d set for a reason CodeRabbit had no way to know about, so I flagged it back rather than silently overriding my own prior decision. The findings that were real got fixed, including one that mattered: a Bearer-token redaction function was only replacing the word “Bearer” itself, six characters, instead of the token that followed it, because the code searched for the terminator starting at the matched pattern instead of after it. That one shipped in an earlier version and sat there until this pass caught it.

Same posture both times: an AI’s output, whether it’s a code diff or a list of findings, is a draft to check against something real, not a verdict to apply.

What I actually trust a subagent to catch, and what I still read myself

The pattern across both sessions: subagents are good at exactly the thing task 2 needed, checking a piece of code against an explicit, written rule. They’re worse at the judgment calls, whether a finding is worth fixing given context the spec didn’t capture, whether a “critical” severity label matches the actual blast radius, whether a suggested fix conflicts with a decision I made on purpose. Those still need a person who knows why the code is the way it is, which today is me.

That’s also why the session survived losing the reviewer halfway through. The review loop isn’t a black box I trust instead of checking my own work. It’s a first pass that does the same check I’d do by hand, faster, so I have to consciously slow down and do it myself only when the loop isn’t there. The budget running out was annoying. It wasn’t a blocker, and that’s the actual proof this was a discipline and not a dependency.