Latitude for Claude Code

See where Claude Code burns tokens. Hit your limits less.

Developer Tools

Visit WebsiteSee on Product HuntTwitter ⧉Github ⧉

@heycesr This is genuinely impressive as having no visibility over what Claude actually does behind-the-scenes always made me a little bit anxious. How does the platform store the traceability data (encryption, retention) and do you plan to make it configurable (e.g. redaction of sensitive content like secrets before it leaves machine)?

Token visibility is the missing piece for anyone using Claude Code seriously you don't realize how fast context fills up until you hit the limit mid-task. Does it break down usage by file, conversation, or tool call?

The session level telemetry is smart - we burned through $12 last week on a Claude Code loop that kept re-reading the same file. This would've caught it immediately. One question: does the trace show token cost from failed tool calls that retry, or only successful ones? That's been our hidden cost driver

Tracking token burn across different workflows is always a headache, so this is super helpful. Quick question: is there a way to set up automated alerts if a specific subagent suddenly spikes in token usage, or is it strictly weekly reporting for now?

This is solving a real problem. I run automated agents (social media engagement, security audits, competitor monitoring) and the hardest part isn't building them — it's knowing when they silently fail. I built a custom "doctor" module that diagnoses and self-heals agent errors, but a proper observability layer would have saved me weeks.

The "auto-generated evals from production failures" is the killer feature here. How granular is the token cost tracking per agent task?

The captures locally framing caught my attention — curious how the telemetry hook actually intercepts Claude Code's runtime. Is it patching the Node.js fetch layer, or hooking at the MCP transport level? Asking because system prompts in Claude Code often contain sensitive workspace context (repo structure, file contents), so understanding the data path before it hits Latitude's servers matters a lot for teams in regulated environments.

- On macOS the installer writes

~/Library/LaunchAgents/so.latitude.claude-code-telemetry.plist which runs

launchctl setenv BUN_OPTIONS=--preload=... on every login. That sets

BUN_OPTIONS for every Bun process on your machine, not just claude — so any

other Bun-based tool you run will also load their preload shim. Wider blast

radius than "just Claude Code."

^^ Might be worthwhile reeling that in a bit. Every Bun process is a bit overreaching.

Oh man! Needed it. Claude is making me crazy, cause I never know where my tokens go. Thanks for helping on this and wish you all the best here!

Token-burn observability for Claude Code is the kind of thing you only think to build after you blow a session on a regex loop. Curious how you handle the per-tool breakdown when an agent calls bash ten times for the same file read. Is it parsed from stream events or from the response after the fact?

congratulations, how much overhead does telemetry collection add to latency during active sessions?

Does the recurring failure detection use heuristics, or are you applying some ML based pattern analysis?

Does it work for Claude Cowork projects? I mainly burn my limits on Cowork sessions.

this is genuinely what we need, especially being able to spot which sessions burn way more tokens than others lol.

Does this support the Claude Team plan, or API-only for now?