Claude Code Observability: Track Tokens, Cost, and Usage per Developer

Wat observability betekent voor een coding agent

Traditionele observability vraagt of een dienst in de lucht is. Een coding agent is altijd "in de lucht" — hij draait op een laptop en communiceert met een model provider. De vraag die er toe doet is economisch en gedragsmatig: welke ontwikkelaar heeft wat uitgegeven, aan welk model, wat deden ze, en waarom kostte de ene sessie tien keer meer dan de andere. Dat is token-boekhouding, geen gezondheidscontrole, en dat is de bril die deze gids gebruikt. Voor de facturatiezijde van dezelfde medaille, zie Claude Code Pricing Explained.

De belangen zijn concreet. Één enkele actieve ontwikkelaar verbruikt ongeveer $ 13 per actieve dag en $ 150–250 per maand, waarbij ongeveer 90% van de gebruikers onder $ 30/dag blijft — dus de uitzonderingen maken enorm veel uit. Zonder een weergave per ontwikkelaar kunt u de drie mensen in een team van dertig die het grootste deel van de factuur veroorzaken niet vinden, of zien of ze zwaar werk verrichten dan wel Opus standaard aan laten staan. Observability verandert een verrassend totaalbedrag in een lijst van herstelbare oorzaken.

Wat u daadwerkelijk moet bijhouden

Zeven signalen dragen bijna alle waarde. Al het andere is van hen afgeleid.

Twee hiervan — de modelmix en de cache-ratio — zijn ook uw grootste kostenknoppen waaraan u kunt draaien, en dat is waarom het observeren ervan zichzelf terugbetaalt. De routing-zijde wordt behandeld in Opus vs Sonnet vs Haiku: a cost-vs-capability routing guide, en de caching-zijde in Claude prompt caching: the real cost math.

De token is niet één getal — het zijn er vier

"Gebruikte tokens" is een nutteloos aggregaat omdat de vier categorieën enorm verschillend geprijsd zijn. Op Opus 5.5 is het verschil groot: output is vijf keer de prijs van verse input, cache writes kosten meer dan verse input, en cache reads kosten een fractie daarvan. Het samenvoegen ervan verbergt precies de informatie die u nodig hebt om de factuur te verlagen.

Een hoge cache-read ratio is het signaal dat u wilt: langdurige context die wordt hergebruikt in plaats van opnieuw gefactureerd tegen de volle inputprijs. Bij een abonnement blijft de prompt cache ongeveer een uur bestaan; op de API of een cloud provider is dat ongeveer vijf minuten, dus de te verwachten ratio verschilt per setup. Als cache reads instorten en verse input stijgt, heeft iets de cache gebroken — en dat merkt u alleen als de vier getallen afzonderlijk worden bijgehouden.

De natieve opties, en waar elk stopt

Claude Code wordt geleverd met echte zichtbaarheid — het is alleen beperkt tot het individu.

• /usage in de CLI toont de tokens en geschatte kosten van de huidige sessie, lokaal berekend tegen catalogusprijs. Het is nauwkeurig voor één ontwikkelaar op één machine, en het wordt gereset wanneer de sessie wordt gewist. Het kan geen team aggregeren.
• /insights vat recente sessies op die machine samen — nuttig voor een ontwikkelaar die reflecteert op hun eigen patronen, maar nog steeds geen fleet-weergave.
• Subscription analytics (Teams en Enterprise) geven een uitgavenrapport op org-niveau per gebruiker en per model, dagelijks bijgewerkt — goed voor finance, maar geen live weergave per verzoek.
• Cloud-provider gebruik is onzichtbaar voor de dashboards van Anthropic. Draai Claude Code op Amazon Bedrock, Google Vertex of Microsoft Foundry en de natieve analytics zien het simpelweg niet, omdat de tokens in plaats daarvan aan uw cloudaccount worden gefactureerd.

Het patroon is consistent: de natieve tools beantwoorden "wat heb ik zojuist uitgegeven," niet "wat doet de fleet op dit moment." Daarvoor moeten de metrieken de machine verlaten.

OpenTelemetry: metrieken van de machine halen

De natieve manier om het gat te dichten is OpenTelemetry. Claude Code kan per-gebruiker token- en kostenmetrieken via OTLP exporteren naar uw eigen observability stack, en het werkt op elke setup — abonnement, Console API of elke cloud provider. Dat maakt het de enige natieve optie die bijna-realtime cijfers per ontwikkelaar geeft, ongeacht hoe ontwikkelaars zich authenticeren.

Het inschakelen

Export staat standaard uit en wordt volledig gestuurd door omgevingsvariabelen, ingesteld in het shell-profiel of een beheerd instellingenbestand dat naar elke machine wordt gepusht. Een minimale setup voor metrieken en logs:

Metrieken worden met een interval gepusht — de standaard is 60000 ms voor metrieken, 5000 ms voor logs — dus "bijna-realtime" betekent op minuutniveau, niet per verzoek. Traces zijn een afzonderlijk beta-signaal afgeschermd achter CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 en OTEL_TRACES_EXPORTER=otlp; schakel ze alleen in als er een collector gereed staat om spans te ontvangen.

Wat elk signaal bevat

OpenTelemetry zendt drie soorten signalen uit: metrieken (de tellers waarop u dashboards bouwt), logs (discrete gebeurtenissen) en traces (beta spans voor een enkele interactie). De metrieken zijn de plek waar het kostenverhaal zich bevindt:

Toewijzing per gebruiker verloopt via de attributen user.email en account-identifier, die standaard zijn inbegrepen. Merk op dat session.id de cardinaliteit sterk verhoogt — één reeks per sessie — dus als uw backend kosten in rekening brengt per reeks, laat deze dan uit voor fleet-dashboards en wijs toe op basis van gebruiker. De event logs (claude_code.user_prompt, claude_code.tool_result, claude_code.api_request) voegen details per actie toe die metrieken niet kunnen bieden, en kunnen optioneel prompt- of tool-inhoud bevatten — een privacy-beslissing die u moet nemen voordat u deze inschakelt.

De afweging is operationeel: u moet elke machine instrumenteren, de variabelen op hun plaats houden bij laptopverregelingen en nieuwe medewerkers, en de collector en dashboards zelf beheren. Het streamt metrieken goed, maar een metriekenstream is geen audit trail op verzoekniveau, en het doet niets om een budget af te dwingen — het rapporteert er alleen één. Voor een diepgaandere behandeling van de token-boekhouding zelf, zie Observability for Claude in production: token accounting and tracing.

Natief vs OpenTelemetry vs een gateway

OpenTelemetry en een gateway sluiten elkaar niet uit — een goede gateway is OpenTelemetry-compliant en kan dezelfde stack voeden. Het verschil is dat de gateway zich ook in het request-pad bevindt, zodat deze kan traceten en limiteren, niet alleen tellen. OTel is het juiste antwoord wanneer u de fleet bezit, erop vertrouwt dat elke machine geïnstrumenteerd blijft en alleen hoeft te rapporteren. Een gateway is het juiste antwoord wanneer machines komen en gaan, wanneer een deel van het verkeer op een cloud provider draait, en wanneer "het zien" moet veranderen in "het stoppen."

Observability bij de TrueFoundry AI Gateway

Routeer Claude Code via de TrueFoundry AI Gateway en elke completion passeert één punt dat u beheert. Dat verandert observability van iets waar elke ontwikkelaar op elke laptop voor kiest, in iets dat gewoon bestaat:

• Request traces — elk verzoek met de opgeloste gebruiker, het geserveerde model, token-aantallen en latentie, zodat u achteraf de vraag kunt beantwoorden "wie stuurde dat, en wat kostte het".
• Metrics dashboards die de fleet aggregeren per gebruiker, team en model — het beeld per ontwikkelaar dat cost tracking for Claude Code doorloopt.
• Één weergave over tools heen — Claude Code, Cursor en Codex komen op dezelfde plek terecht in plaats van drie, zoals in centralising cost control for AI coding IDEs.
• OpenTelemetry-compliant export met ongeveer 3–4 ms aan extra overhead, zodat dezelfde cijfers naar Grafana, Datadog of Prometheus stromen als u die al gebruikt.

Wilt u de Claude Code-uitgaven per ontwikkelaar zien zonder elke laptop te instrumenteren?

TrueFoundry AI Gateway

Wat een enkele request trace registreert

Een gateway beantwoordt vragen die OpenTelemetry-metrieken niet kunnen beantwoorden, omdat deze elk verzoek registreert als een discreet record, niet als een in minuten ingedeelde teller. Een trace legt de opgeloste identiteit vast, het geserveerde model, de vierledige token-verdeling, de kosten tegen uw gecontracteerde tarief, end-to-end latentie in milliseconden, de status en de routing-beslissing. Omdat elke rij doorzoekbaar is en wordt bewaard, kunt u een piek reconstrueren: filter op één ontwikkelaar en één uur, en lees de werkelijke calls die de piek veroorzaakten — de audit trail die een metriekenstream plat slaat.

Waarop u moet alarmeren, en de te bouwen dashboards

Het verzamelen van signalen is verspilde moeite als niemand kijkt totdat de factuur binnenkomt. Het doel van het van de machine halen van metrieken is om te handelen zolang ze er nog toe doen — een kleine set waarschuwingen en een handvol dashboards, geen muur van grafieken. Waardevolle waarschuwingen worden gekoppeld aan een specifieke, herstelbare oorzaak:

• Dagelijkse uitgaven per ontwikkelaar die een drempel overschrijden — bijv. aanhoudend boven de ~$ 30/dag die al ongeveer 90% van de gebruikers dekt. Dit vangt de uitschieter op de dag dat deze begint, niet een maand later.
• Opus-aandeel van tokens boven een plafond — het duidelijkste signaal van afwijken van het standaardmodel, waarbij routinematige bewerkingen stilzwijgend op het duurste model draaien.
• Daling van de cache-read ratio — een plotselinge daling betekent dat de caching is verslechterd en verse input opnieuw gefactureerd wordt tegen de volle prijs.
• Latentie p95/p99 in ms die een grens overschrijdt — brengt provider-achteruitgang en timeout-patronen aan het licht voordat ontwikkelaars ze melden als "Claude is traag."
• Verzoekvolume buiten werktijd — geplande taken en achtergrondwerk die met een interval grote context opnieuw verzenden, verschijnen als uitgaven zonder dat er een mens achter het toetsenbord zit.

De dashboards die het waard zijn om op te zetten zijn eveneens schaars: fleet-kosten per ontwikkelaar (top-N), kosten per model zodat de Opus-vs-Sonnet-vs-Haiku mix in één oogopslag zichtbaar is, een gestapelde weergave van de vier token-typen om de cache-ratio te bewaken, kosten per repo of team voor doorbelastingen, een latentieverdeling in milliseconden en acceptatie van tool-calls. Op een gateway zijn deze vooraf gebouwd en worden ze automatisch gevoed; op OpenTelemetry bouwt u ze in Grafana of uw backend uit de bovenstaande metrieken.

Een uitgewerkt voorbeeld

Een platformteam heeft dertig ontwikkelaars op Claude Code, sommigen op het abonnement en sommigen op Bedrock. De maandelijkse factuur stijgt en niemand kan zeggen waarom. Ze richten elke installatie op de gateway en lezen de volgende dag het dashboard: drie ontwikkelaars zijn verantwoordelijk voor 60% van de token-uitgaven, alle drie omdat Opus hun standaardmodel is, en één geplande taak stuurt elk uur een grote context opnieuw. Ze stellen een modelbeleid in dat routinematige bewerkingen naar Sonnet routeert, herstellen de taak en de trendlijn buigt af — zonder dat iemand gevraagd wordt een commando op hun laptop uit te voeren. De observability veranderde het gedrag niet; het zien ervan wel.

De eerlijke limiet: een gateway toont uitgaven en stelt u in staat deze te maximeren. Het herschrijft geen prompts — het maakt de verspilling onmogelijk om te missen en geeft u de beleidsknop om te handelen. De handhavingszijde wordt behandeld in Claude Code governance with an AI gateway.

Valkuilen die goed zijn om te weten

• Het /usage bedrag in dollars is een schatting die lokaal is berekend tegen catalogusprijs. Als uw organisatie gecontracteerde tarieven betaalt, komt dit niet overeen met de factuur, tenzij een beheerder de tariefoverschrijving instelt.
• /usage is per machine. Een ontwikkelaar die op een laptop en een desktop meeschrijft, ziet twee gedeeltelijke beelden; alleen een metriek buiten de machine (OTel of een gateway) brengt ze samen.
• Cloud-provider dashboards splitsen de gegevens. Op Bedrock, Vertex of Foundry bevinden uw uitgaven zich in de cloud billing console, en toewijzing per gebruiker heeft OpenTelemetry of een gateway daarbovenop nodig.
• Inactieve sessies genereren nog steeds verzoeken. Geplande taken en achtergrondwerk sturen op hun interval opnieuw de volledige context, dus een rustig ogende ontwikkelaar kan nog steeds kosten opbouwen — u ziet dit alleen in een trace per verzoek.
• Tellen is geen limiteren. OpenTelemetry vertelt u achteraf dat een budget is overschreden; alleen iets in het request-pad kan het verzoek stoppen voordat het geld uitgeeft.
• session.id is een valkuil voor cardinaliteit. Als dit aan blijft staan voor fleet-dashboards, maakt het één metriekreeks per sessie aan, wat de kosten op een observability-backend met prijzen op basis van gebruik kan doen exploderen — wijs in plaats daarvan toe per gebruiker.
• Agent-teams vermenigvuldigen tokens. Multi-agent runs gebruiken ongeveer 7x meer tokens dan een enkele sessie, dus het invoeren ervan kan de uitgaven doen stijgen zonder dat een individu zich anders gedraagt.

Gerelateerde artikelen

• Observability for Claude in Production: Token Accounting and Tracing — de token-boekhouding in detail
• Cost Tracking Claude Code with the TrueFoundry AI Gateway — toewijzing per ontwikkelaar in de praktijk
• Centralising Cost Control for AI Coding IDEs — één weergave over Claude Code, Cursor en Codex heen
• Claude Code Pricing Explained — wat de tokens die u observeert daadwerkelijk kosten
• Claude Code Governance with an AI Gateway — observability omzetten in handhaving

Conclusie

Claude Code observability is in feite kosten-observability met de details maximaal opengegooid: tokens onderverdeeld in vier typen, toegewezen aan een ontwikkelaar, een model en een taak. De natieve tools beantwoorden dit voor één persoon op één machine; OpenTelemetry beantwoordt het voor de fleet als u elke machine instrumenteert; en een gateway beantwoordt het standaard voor de fleet, omdat elk verzoek er al doorheen gaat.

Kies de laag die overeenkomt met hoe ver u moet kunnen kijken. Als het antwoord is "per ontwikkelaar, over elk model en elke provider heen, met de mogelijkheid om te handelen naar wat ik vind," dan is het request-pad de plek waar u moet staan.

Bekijk elk Claude Code-verzoek, elke token en elke dollar op één plek.

Boek een demo