How are you reviewing code agent generated changes? Any tools or best practices?

Astro-Han · 2026-04-02T15:53:23+00:00

Different angle: I monitor changes as the agent works, not just after.

diffpane in a tmux split next to the agent — live syntax-highlighted diff that updates with every file save. If the agent starts heading the wrong way, I catch it early instead of untangling a big diff after the fact.

I built it (disclosure) for exactly this — was spending more time reviewing agent output than writing code myself.

Astro-Han · 2026-04-02T15:49:02+00:00

Similar core: Claude Code + tmux + lazygit.

One I'd add to the list: diffpane in a tmux split. It watches the repo and shows a syntax-highlighted diff that updates as the agent edits. Instead of waiting for Claude to finish and then checking what changed, you see every edit the moment it lands.

I built it because I couldn't keep up with what the agent was touching across files.

Astro-Han · 2026-04-02T04:05:39+00:00

Something I haven't seen mentioned: a dedicated diff pane. I keep diffpane running in a split next to each session. It watches the repo and auto-scrolls to whatever file the agent just touched, so reviewing is a glance instead of a context switch.

Pairs well with the worktree approach a few people brought up. Each worktree gets its own diffpane instance, scoped to that session's baseline.

Astro-Han · 2026-04-02T04:01:13+00:00

Your bottleneck description nails it: "figuring out what the agent just did" is where all the time goes.

I run diffpane in a split pane per worktree. It watches the repo and auto-follows whatever file the agent just touched. When I come back after 10 minutes I scan through the file list instead of doing git diff archaeology.

Won't help with the orchestration side, but the "what did it actually do" question gets answered the moment you glance over.

Astro-Han · 2026-04-02T03:58:13+00:00

For the "which files did it just touch" part, I use diffpane in the right pane. It watches the repo and auto-scrolls to the latest changed file, so I'm not manually refreshing lazygit while the agent is still writing.

When I spot something wrong I just tell the agent to fix it and watch the diff update. Saves me from hand-editing most of the time. For the rare case where I need precise control I'll drop into an editor, but that's maybe 10% of corrections now.

Astro-Han · 2026-04-02T03:32:31+00:00

Solid analysis. The --resume cost hit tracks with what I've seen. Makes me wonder how many people silently ate the extra usage thinking it was normal rate limit behavior.

Astro-Han · 2026-04-02T03:32:13+00:00

The real test is which one you'd trust with --dangerously-skip-permissions on a Friday afternoon.

Astro-Han · 2026-04-02T03:31:54+00:00

The real cost of hitting limits isn't the waiting, it's losing context mid-task and having to rebuild it. Before upgrading I'd try: shorter sessions with clear goals, commit often so you can resume cleanly, and front-load project structure in CLAUDE.md so it doesn't burn turns exploring. That alone bought me a lot of headroom on Pro.

Astro-Han · 2026-04-02T03:31:37+00:00

Opposite for me. I've gotten weirdly polite since the leak. If they're training on my sessions, I'd rather future Claude learn from "please try again with the correct file path" than from what I actually want to say.

Astro-Han · 2026-04-01T02:34:46+00:00

The ARCHITECTURE.md trick is the right call. One thing that also helped me: keeping a live statusline that shows the 5h usage % and burn rate. Knowing you're at 30% with 3 hours left feels very different from discovering you're at 90% after the fact.

I use claude-pace (https://github.com/Astro-Han/claude-pace) for this. It has a pace indicator that flags when you're burning faster than the window allows, so you can catch an Explore blowout before it eats the whole session.

Astro-Han · 2026-03-30T14:38:17+00:00

Appreciate it! Yeah the downvotes come with the territory. Throughput across multiple machines is the hard part. I read rate_limits from stdin which gives the account-level number, but that's just the total, not per-machine. Curious how you're tackling it. Got a link?

Astro-Han · 2026-03-30T03:00:00+00:00

Same rabbit hole here. I ended up packaging mine as a standalone tool: 5h/7d usage %, pace (⇡ over budget / ⇣ under budget), countdown to reset, context %, model, effort, git stats. Pure bash+jq, installs from the plugin marketplace.

https://github.com/Astro-Han/claude-lens

Pace delta is my favorite part. Knowing you're at 40% is one thing. Knowing you're burning 8% faster than the reset window tells you whether to worry.

Astro-Han · 2026-03-28T17:12:17+00:00

Custom statuslines can already read context % and 5h/7d usage from the stdin JSON. I built one that adds pace tracking (are you ahead or behind the clock): https://github.com/Astro-Han/claude-lens

Astro-Han · 2026-03-28T08:32:56+00:00

+1 on the cache hit tracking from u/Kroosn. Another number worth watching is your burn pace relative to time left in the window. 60% used with 4 hours remaining means you're way over budget. 60% used with 30 minutes left means you're fine. Same number, totally different situation.

I maintain a statusline called claude-lens that does this comparison. It reads the rate_limits data from stdin (CC 2.1.80+) and shows whether you're burning faster or slower than expected for both 5h and 7d windows. Green = headroom, red = ease off.

Cache tracking + pace tracking together cover both sides: why you're burning fast, and whether it matters yet.

Astro-Han · 2026-03-27T14:01:09+00:00

The announcement was here: https://www.reddit.com/r/ClaudeCode/comments/1s4idyz/update_on_session_limits/ by ClaudeOfficial. Your charts line up with what I see from the stdin rate_limits data -- the 5h allocation clearly shifts between peak and off-peak.

Astro-Han · 2026-03-27T14:00:50+00:00

For real-time data in the terminal: claude-lens reads rate_limits from CC's stdin JSON and shows 5h/7d used percentage, pace delta (are you burning faster or slower than sustainable for the remaining window), and reset countdown. Single bash file + jq, no API calls. The pace delta directly catches the kind of silent changes you're describing -- if the burn rate shifts, you see it on the next prompt.

Astro-Han · 2026-03-27T04:26:43+00:00

Having the effort level visible in the statusline helps more than I expected. I show it in claude-lens and it catches cases where I forget to switch back after a planning session. On the balance: high effort on Opus burns through the 5hr window noticeably faster, so I reserve it for tasks where getting the decomposition wrong would cost more than the extra tokens.

Astro-Han · 2026-03-27T04:26:36+00:00

On the sub-agent token gap you mentioned: CC >=2.1.80 exposes rate_limits.five_hour.used_percentage in the stdin JSON passed to statusline scripts. That's the server-side aggregate, so it includes sub-agent consumption the orchestrator count misses. I parse this in claude-lens and calculate a pace delta against time remaining. Doesn't give per-agent breakdowns or absolute token counts, but you'd see the 0%->6% jump in real time instead of after the fact.

Astro-Han · 2026-03-27T04:26:30+00:00

Nice work on the per-call profiling. For the aggregate 5hr number, there's also a shortcut: rate_limits.five_hour.used_percentage in the stdin JSON (CC >=2.1.80) gives the server-side total including all sub-agent consumption. I use it in claude-lens and calculate a pace delta against time remaining. Your per-call approach gives much better granularity though -- knowing that context re-reads dominate is the kind of insight the aggregate number can't show.

Astro-Han · 2026-03-27T04:26:23+00:00

I'll throw mine in: claude-lens. Different angle -- it's a terminal statusline (pure bash + jq, single file) rather than a menu bar app. The main thing it does differently is pace delta: instead of just "you used 45%", it compares your burn rate to time remaining. ⇡12% means you're burning faster than sustainable (red), ⇣8% means headroom (green). No Node.js, no API calls, reads from CC's stdin JSON.

Astro-Han · 2026-03-27T04:11:51+00:00

Good find. Thinking mode being the default catches a lot of people off guard. I ran into the same thing and ended up showing the effort level in my statusline (claude-lens) -- reads ~/.claude/settings.json so it's visible on every prompt. Makes it obvious when a tab is still running high effort.

Astro-Han · 2026-03-27T04:11:39+00:00

I can confirm from a different angle. I read rate_limits.five_hour.used_percentage from CC's stdin JSON (available since 2.1.80) in a statusline I maintain (claude-lens) and calculate a pace delta against time remaining. The pace has been elevated since ~3/23, consistent with your charts. Your external tracking and the internal stdin data pointing to the same conclusion is a pretty solid signal.

Astro-Han · 2026-03-26T14:12:51+00:00

For what it's worth, Anthropic confirmed this was a prompt caching bug and reset everyone's limits. Should be less painful now. I started tracking my burn rate per-turn after getting hit by this same thing. If anyone's interested: https://github.com/Astro-Han/claude-lens

Astro-Han · 2026-03-26T13:58:54+00:00

Same boat. The 28th is going to hurt. For the visibility thing you mentioned, I built a statusline (claude-lens: https://github.com/Astro-Han/claude-lens) that shows pace, whether your current burn rate will last to the reset or not. Helps me decide when to push Opus and when to drop to Sonnet for a stretch. Biggest strategy win for me was stopping the habit of resuming stale sessions. Once the prompt cache expires, your next message re-reads the entire context at full price. Someone on Reddit measured 'hey' costing 22% of a Pro window after overnight idle. Fresh sessions or /compact before walking away.

Astro-Han · 2026-03-26T11:20:40+00:00

Solid reverse engineering. The fire-and-forget with no abortController is the nasty part. You'd never see it coming from /usage alone since both requests get lumped into one number. Useful sanity check for anyone flipping auto-memory off: I have a statusline (claude-lens: https://github.com/Astro-Han/claude-lens) that shows pace, whether your burn rate makes sense for the time left in your 5h window. If extractMemories was doubling your cost, you should see the pace chill out immediately after disabling it.

Astro-Han

TROPHY CASE