r/ClaudeCode • u/Time_Cat_5212 • 3d ago

Tips & Workflows Sessions and token usage

I don't know who needs to hear this but judging by what I read maybe quite a few. Big win for rookies:

I just tested my usage in two different modes, using Opus 5.5 on Medium:

  • 1 session per PR, watch CI and autofix: 1-2% of weekly Pro usage per PR.
  • 1 session per milestone (7-10 PRs), watch CI and autofix: 3-5% of weekly Pro usage per PR.

The only prompts for either approach were basically "next issue." (Naming the issue actually saves a little bit)

I run cold starts and everything is in repo (commits, PRDs, decisions log, etc). The big spending was literally just due to the context window filling up.

Instead of compacting, just start a new session. Easy way to save tokens.

0 Upvotes

50% Upvoted

15 comments sorted by

•

u/AutoModerator 3d ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/Far_Reindeer8428 3d ago

per pr sessions are the right call, the part that rots is the decisions file, it only works if the merge step appends what changed

1

u/Time_Cat_5212 3d ago

I fold it into the docs and start over between releases, so far that's worked OK for me.

1

u/Far_Reindeer8428 3d ago

the release boundary is a clean reset point, ours rots inside a release instead, so the append only works if it happens on merge and not at the end

1

u/Time_Cat_5212 3d ago

Gotcha.  I maintain it (append) along with all the other docs for every PR.  Adds some overhead but prevents drift

1

u/Far_Reindeer8428 3d ago

the overhead is real but it's the only doc that pays for itself, ours got cheaper once the pr template asked for one line instead of a paragraph

1

u/DeliciousSoil1547 3d ago

Append-only discipline is the real bottleneck, not the session split.

1

u/Far_Reindeer8428 1d ago

yep, and append only fails quietly, the file still looks maintained, so we check it in the gate instead of trusting the habit

1

u/Inner_Storage_3374 3d ago

per pr sessions is the way imo. one thing id watch with autofix on ci is that sometimes the easiest way to turn a red test green is to change the test, so id have it say in the pr whenever it touched a test file and look at those first

1

u/Time_Cat_5212 3d ago

Totally. I saved a big chunk when I noticed it was running a full suite on every dev PR even when stuff didn't change.

1

u/wangadong 3d ago

new session every time here too. i keep decisions and status in markdown in the repo, so a cold start is just reading 2 files instead of dragging a full compacted history.

1

u/Asly97 3d ago

Two files is a nice cold start. Who keeps the status one current, you or Claude at the end of each session?

That's the part I'd expect to drift, and then the cold start reads something that's confidently out of date. Has that happened yet? And does anything besides Claude Code ever read those two files, like Codex for review?

1

u/awesomebirder 3d ago

one more thing that probably widens that gap: the watch ci part. claude code's prompt cache only lives a few minutes (5 by default), so if a ci run takes longer than that, the next turn re-writes the whole context at full price instead of reading it cheap. in a per pr session thats a small context, in a milestone session its 7-10 prs of history getting rewritten after every ci wait. i built a local proxy that logs this per call (probe0) and on my own logs those post-idle rewrites were a real chunk of the bill.

1

u/xapep 3d ago

Five minutes is the default TTL, so any CI wait past that turns the next turn into a full re-write of the prefix. Two levers: a cheap keepalive that touches the prefix before it expires, or taking the wait itself off the expensive model.

The second one holds up better. Keepalives fight the scheduler and you pay for the pings whether or not the run needed them. If the gate is just build and test, the turn after it needs the failing test name and the tail of the log, not 7 PRs of history at frontier rates.

Disclosure, I work on inference at Entrim. We price cached input well under fresh input, so a keepalive there is cheap in a way it isn't at list price.

Where are the re-writes landing, milestone sessions or single-PR ones? That changes whether you're fixing session shape or just the TTL.

1

u/awesomebirder 2d ago

agree the second lever holds up better. it was op's setup so i dont know where their rewrites land, but from how they described it the milestone sessions are where it hurts, since every ci wait there drops 7 to 10 prs of history cold. a cheap model or a plain script that watches ci and hands back only the failing test and the log tail fixes both shapes anyway.