Are Your Overnight Claude Agents Making You Money?

Hello builders,

Before you point a Claude Code loop at a week of real work, you can know in dollars whether it is going to make you money. Most of the fear in the threads is about token burn, and in the arithmetic below the token bill turns out to be the smallest term in the equation. Most AI coding agent ROI math prices seats for a whole team, so here is the break-even for one loop, against your own hourly rate, with your review time in it.

The loudest post on this subject is titled “The loop engineering trend is a financial nightmare,” and it took 178 upvotes. I get the fear. I also think it is pointed at the wrong number, and the way we find out is to put three things on one page: the tokens, the value of the work the loop replaced, and the minutes you spend checking what it produced.

Watch the arithmetic move

Every input here is invented, so replace all four with yours before you believe any of it. Say a unit of work takes you 50 minutes by hand, your loaded rate is $95 an hour, reviewing an accepted unit takes 6 minutes and a rejected one 3, and a night’s run produced 8 units for $6.40 in tokens.

• All 8 accepted: that’s about 6.7 hours of your work, or $633, and 48 minutes of review costs $76. Net is about $551 and cost per accepted unit is $10.30.
• 3 of 8 fail the gate: you still paid $6.40 for all 8, but only 5 units of work happened, worth about $396. Review is 39 minutes, or $62, so net drops to about $328 and cost per accepted unit rises to $13.63.
• Review takes 25 minutes: same run, but you don’t trust the output, so you read every accepted unit line by line. That comes to 134 minutes, or $212, which leaves a net of about $177 and a cost per accepted unit of $43.71.

From the first case to the second, the net fell by 40% and the token bill never moved.

So where did the money go? Almost all of it is work that didn’t happen, and a small part is time spent reviewing things that turned out to be rubbish. A cheaper model fixes neither, and one with a higher rejection rate can leave you paying the same per accepted unit while you review more rubbish. That’s why we divide by accepted units: 8 pull requests with 3 failing the gate is 5 units of work, and all 8 cost money.

Review time is the term that decides whether a loop is worth running, and it is the only one nobody instruments.

Run it on your receipts

A model we fill in by hand is a model we fill in once. This one reads the records your loop already writes, one claude -p --output-format json result per run saved in .loop/runs/, plus four inputs you own. If you’re salaried, use your fully loaded cost per hour, because the loop is competing with what your time costs your employer.

One catch before the script. A subtype of success only means the run finished, and it says nothing about whether the work got past your gate. So right after the verifier writes .loop/verdict.json, we stamp its answer into that run’s record, where $out is the path the wrapper saved the run’s JSON to:

jq --argjson ok "$(jq '.advance' .loop/verdict.json)" '. + {gate_passed: $ok}' "$out" > "$out.tmp" && mv "$out.tmp" "$out"

Run the first block below once to write your inputs, and save the functions in .loop/lib.sh:

mkdir -p .loop
cat > .loop/economics.tsv <<'EOF'
# what                          value
hourly_rate                     95
minutes_manual_per_unit         50
minutes_review_per_accepted     6
minutes_review_per_rejected     3
EOF

loop_side() {
  jq -rs '{runs: length,
    accepted: (map(select(.gate_passed == true)) | length),
    cost: (map(.total_cost_usd // 0) | add)}' .loop/runs/*.json
}
v() { awk -v k="$1" '$1==k{print $2}' .loop/economics.tsv; }

breakeven() {
  loop_side | jq -r --argjson rate "$(v hourly_rate)" --argjson man "$(v minutes_manual_per_unit)" \
      --argjson ra "$(v minutes_review_per_accepted)" --argjson rr "$(v minutes_review_per_rejected)" '
    .accepted as $a | (.runs - .accepted) as $r |
    ($a * $man / 60 * $rate) as $replaced |
    ((($a * $ra) + ($r * $rr)) / 60 * $rate) as $review |
    {accepted: $a, rejected: $r,
     "value of work replaced": ($replaced * 100 | round / 100),
     "spent on tokens": (.cost * 100 | round / 100),
     "spent reviewing": ($review * 100 | round / 100),
     "net": (($replaced - .cost - $review) * 100 | round / 100),
     "cost per accepted unit": (if $a > 0 then ((.cost + $review) / $a * 100 | round / 100) else "n/a" end)}'
}

What does your own week look like? Source .loop/lib.sh, run breakeven and read the net line. If it’s negative, we haven’t failed at anything. We’ve measured something most people arguing about this online never measure, and the output shows which term dominates. It’s usually review time.

For scale, Anthropic’s cost docs give ordinary daily usage, which is a different thing from loop usage:

“Across enterprise deployments, the average cost is around $13 per developer per active day and $150-250 per developer per month, with costs remaining below $30 per active day for 90% of users.”

The same page says the dollar figure in each record is computed “locally from token counts at list price” and that “The figure is an estimate.” On Pro or Max, “the session cost figure isn’t relevant for billing purposes,” so treat the token term as an estimate and keep your eye on the review minutes.

What I’d do is run it against a week of receipts before adding a second loop. If the net is negative after review time, don’t build it, because a loop that loses money per accepted unit at today’s rejection rate loses more at scale, and scale is the only reason to build one. The fix that pays twice is a gate you trust, since trusting the gate is what lets us review outcomes and stop reading every line.

Now go build something this weekend!

John Cook