You know what Claude Code costs per seat. But do you know which sessions burned the budget, which model did the work, or whether your cache paid off? LangWatch now tracks every Claude Code session: tokens, costs, cache hits, bash commands, MCP tool calls, file edits, and full terminal replays. Works with Claude Code, Codex, Gemini CLI, and opencode. Free for individuals. Start with: npx langwatch claude
This is the 4th launch from LangWatch. View more
Claude Code usage tracking by LangWatch
Launching today
Track Claude Code usage: cost, cache, session replay. Run `npx langwatch claude` once. Every session gets cost with cache reads/writes as separate token classes, every bash and MCP call as a span, theoretical vs billed for your Max plan, and a full terminal replay in the UI. Works for Codex too.
Free
Launch Team
LangWatch
Hey Product Hunt, Manouk here, founder of LangWatch.
We built this because we run a fleet of coding agents ourselves and had no idea what they actually cost: subscriptions hide the number, and local trackers only see one machine.
You know what Claude Code costs you per seat. What you probably can't answer is which sessions burned the budget, which model did the work, or whether your cache was earning its keep. Today's token prices are heavily subsidised, and the teams who find out what they actually consume after prices move are the ones who get surprised.
This week we've added a new launch in LangWatch, which our dev-team is using day-in, day-out. You can now track your full Claude Code usage on LangWatch: every session, tokens spent throughout the month, cache hit analysis, bash commands, skills and MCP tool calls, with a full reproduction of your terminal right in the UI.
Getting started is one command:
npx langwatch claude
From there, every session lands in LangWatch automatically:
Where the tokens go: cost per session and per model, with cache reads and writes accounted separately.
Theoretical vs billed: on a Max plan, see what your usage would have cost at API prices.
Every tool call: bash commands, file edits, skills, and MCP calls, each as a span with duration.
Terminal replay: step through the whole session in the UI, as it happened.
Works the same for Codex, Gemini CLI, and opencode.
Free for individual use.
Start tracking your own sessions
I'll be here all day, happy to answer anything, and genuinely curious what you'd want to see next in it.
Cluing (formerly Collabwriting)
Congrats on the launch @manouk_dr !
LangWatch
@sandra_idjoski thanks!!
Theoretical vs billed is the number that decides whether you stay on Max or move to the API, so I'd put that one on the front of the dashboard rather than three clicks in. The part that will bite you is the price table itself. If you reprice historical sessions when a model's cache read rate changes, last month's report quietly changes too, and that's a number people build budgets on. Stamp each session with the rates that were in force when it ran.
LangWatch
@asadmalik901 let us know what your outcome is! ;) thanks for sharing.
LangWatch
@asadmalik901 oh that is in the front actually, on the home of the app! I just skipped on the demo video. But it works as you expected, rates are stamped and immutable as the sessions arrive, so you can compare month over month
indeed companies and even the engineers themselves are "feeling" the pricing dynamics under them, but without really having any visibility as it's all hidden under a plan and evolving model behavior, which is dangerous liability to have when token sponsoring ends
@asadmalik901 @rogerio_chaves The stamped-immutable-rate answer covers the common case well. Curious about a session that straddles a price change though, one that starts before a rate update and keeps running after it takes effect. Does the whole session get stamped with whichever rate was active at the start, or does it end up split across two rate periods internally?
@asadmalik901 @rogerio_chaves @raffay_sajjad this is the one I'd want nailed before I trusted a month-over-month chart. The stamped-immutable-rate answer is right for the common case, but a long session that starts before a rate change and keeps running after it — single rate stamped at session start, or split internally across two rate periods? On one session that's rounding. On a fleet running overnight it isn't.
Ryan's "cost per outcome, not cost per session" point below is the other half of this for me, coming at it from a different angle. I route deliberately by model — cheaper models to gather context, expensive ones to judge. What I've never been able to answer is whether that routing actually pays for itself, because the win shows up as output quality and the cost shows up in tokens, and I've never had both in one view.
So the thing I'd want: can sessions be tagged or grouped, so I can compare two routing strategies against each other rather than comparing this month to last month? Per-model cost gets me halfway there. That comparison is the report I'd actually open every week.
Good to note that individual developers can use it for free before rolling it out to larger teams. The pricing that I see on the top nav is for LangWatch or for this specific tool?
LangWatch
@divya_kothari1 it's for the whole platform, so you get LLMOps + Gateway + Governance on a single place ;)
FuseBase
Congrats! How much overhead does the tracking introduce during long-running Claude Code sessions?
LangWatch
hey @kate_ramakaieva Good question, we don't sit in the request path, so nothing is added to the model call latency. We read the session data Claude Code already writes locally and ship it in the background in batches, so the overhead is a small background process rather than anything you feel per turn. It stays flat over long sessions since we tail incrementally instead of re-reading the whole transcript.
the MCP tool calls as spans is the bit i want most. i drive a browser automation MCP from claude code all day and the screenshots are obviously the expensive part, except obviously is doing a lot of work in that sentence because i have no per-call number for any of it.
cache reads and writes counted separately is the other one, that is where the surprise usually hides.
LangWatch
@alex_watson2110 yeeppp both are in there: every MCP call gets its own span with its own token cost, and cache reads and writes are broken out separately, so you'll have a real per-screenshot number instead of a hunch.
The replay functionality could be just as useful for learning as it is for troubleshooting. :)
LangWatch
@ankur_jeswani indeed and to improve your skills for example! Let us know your feedback once you tried, very curious!
LangWatch
@ankur_jeswani the cool thing is that you can even point the agent back at it to troubleshoot itself and improve their skills for next time
Manouk's "we run a fleet of coding agents ourselves and had no idea what they actually cost" is the honest version of this. Same here — our answer was "we'll find out when the subsidies stop."
One push: cost per session can mislead. The number that changes how you route work is cost per outcome — per merged PR, per green CI run, per fix that actually held. A run that spends 3x on the expensive model and lands it first try beats a cheap model looping four times — but a per-session view shows the opposite, and quietly trains you to downgrade the model that was earning its price.
You're already logging tool calls as spansm that: span → the commit or test run itproduced. On the roadmap, or are you deliberately staying at the session boundary?
+1 to the immutable price-stamp point above, with a wrinkle: it has to cut both ways. Rates must never change historical reports by accident — but "what the new prices" is exactly the question the subsidy argument makes people ask. That's a deliberate re-price, not a mutation.