DEV Community

Apps by Mo
Apps by Mo

Posted on Fully Autonomous

How I stopped my Claude Code plan running out midweek

I make Mac apps on my own, about twenty of them now, and I build them with Claude Code. For months my plan ran out on Wednesday or Thursday. I assumed I was simply using it a lot. When I finally read Claude Code's own logs on my Mac, most of the spend went to three things I could change.

1. Long sessions cost more than they look

Every reply in a conversation carries the whole conversation with it. In my logs, a reply late in a long session cost about 3.3 times a reply in a short one, for the same kind of work. A session that runs all afternoon gets more expensive with every message, even when the messages are small.

The fix was boring: when a session grows long, the coder writes a short handover (what it did, what is left, what to watch out for) and a fresh session starts from that. The new session knows enough to carry on, and it pays for a few hundred words of context instead of the whole afternoon.

2. Reviews were the most expensive thing I did

I ask for a review before I ship anything that touches saving, sync or payments. Having Claude read a whole diff and hunt for problems is costly. Now a second model, Codex on my ChatGPT plan, does the hunting read-only, and Claude only judges each finding: real, or a false alarm. Across 68 reviews that used about 71% fewer Claude tokens per review, and 120 of the 128 findings were real bugs.

3. Starting from nothing every time

The third cost was hidden. Every new session spent its first minutes rediscovering how the app is built, which command builds it, and the trap I hit last week. Now each app has a short memory (how it is built, the exact commands, the traps), each session starts with a brief, and each one ends by writing a page about what it did and what slowed it down. The next session reads that first.

What it added up to

In the week I measured, the same work would have used about 478M tokens with Claude Code alone. It used 280M. That is 41% of the plan saved, read from Claude Code's own logs, and the plan now lasts the week.

You can do all three by hand: keep sessions short and write your own handover notes, use a cheaper model for the first pass of a review, and keep a notes file per project that every session reads first. I got tired of doing it by hand, so I built a Mac app that does it for me, Atelier. Disclosure: it is mine. https://appsbymo.app/atelier/?ref=devto

If you would like a short email when I ship a new Mac app or a big update (twice a month at most, unsubscribe in one click), you can join here: https://appsbymo.app/?ref=devto#signup-h

What eats your plan? I am curious whether others see the same long-session effect.

Top comments (8)

Collapse
 
xwiox profile image
WIO •

the 71% fewer tokens on reviews is the part i'd poke at. since claude still has to read each finding and judge it, does it need the surrounding code to call something a false alarm, or just the snippet codex quotes?

Collapse
 
appsbymo profile image
Apps by Mo •

Fair thing to poke at. Often the quoted lines plus Codex’s reason are enough to judge. When they are not, Claude opens the file and reads around the finding, and that is where most of the remaining review cost goes. It still comes out well under having Claude read and hunt through the whole diff itself, because it only looks closely where a finding points.

Collapse
 
xwiox profile image
WIO •

ah so most of the leftover is those file opens, not the judging itself. that lines up with why it still beats having claude chew the whole diff.

Thread Thread
 
appsbymo profile image
Apps by Mo •

Yes, that is it. And the opens stay small because a finding usually names the file and line, so Claude reads a screen of code around it rather than the whole file. Thanks for digging into it.

Collapse
 
fortitudeomnis profile image
Developer at Fortitude Omnis Group •

Same here, though mine was the gaps more than the length. I priced 33 days of my own Claude Code logs at API rates, about $4,560. 62% was cache reads, the model rereading context it already had. Output, the actual code, was 8%.

The bit I didn't expect: 207 times I came back to a session after the one-hour cache had expired, and the whole conversation (around 470K tokens) got written to cache again. $972 of it. Read warm, the same context would've been about $48.

So your handover trick does double duty. Shorter sessions are cheaper per reply AND there's less to rewrite when you come back from lunch double bonus! Was your 3.3x all warm, or were some of those late replies the first one after a break?

Collapse
 
appsbymo profile image
Apps by Mo •

Good question, and I did not split it. The 3.3x compares late replies with early ones, so some of those late replies were surely the first after a break, and your cache numbers say that is a big share of it. The fix covers both: a short handover leaves little to rewrite when you come back cold. Thanks for pricing it out, the $972 against $48 is a striking pair.

Collapse
 
crisstiank profile image
Cristian K •

Great breakdown, the measured 3.3x cost of late replies in a long session is a number I'll remember. One thing that helped me with handovers is asking the agent to end them with the exact next command to run and the one assumption it is least sure about. Did you notice the review pass catching different bug types than a normal in-session review?

Collapse
 
appsbymo profile image
Apps by Mo •

Ending the handover with the assumption it is least sure about is a great addition, I am taking that. On bug types: yes, in my experience the separate pass finds more of what the session took for granted, like an order copied from nearby code or a case its own tests never tried. The reviewer never shared the session’s assumptions, so it does not skip past them.