ai newsDi., 27. Okt.
EilmeldungClaude Code vs Cursor compared on pricing, permission settings and rule files

Entwickler analysiert Logs und senkt seine Claude Code Kosten deutlich

Ein Solo-Entwickler, der rund zwanzig Mac-Apps mit Claude Code baut, sah sein Kontingent wochentags aufgebraucht. Ein Blick in die eigenen Logs zeigte, dass der Großteil der Kosten auf drei veränderbare Ursachen entfiel, darunter lange Sitzungen.

dev.toDienstag 08:20 · 27.10.DE2 Min. Lesezeit
Bild: dev.to

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.

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.

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.

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.

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.

Originaltitel: How I stopped my Claude Code plan running out midweekQuelle: dev.to (dev.to). Original öffnen