cloud / systemen
Als een codingagent werkt, is er in de terminal meestal volop beweging. Opdrachten verschijnen, bestanden veranderen en nieuwe berichten komen binnen. Toch zijn de vragen die ik beantwoord wil zien vaak kleiner: welk model gebruikt deze sessie? Hoe vol is de context? Kijk ik naar de sessie die ik denk te zien? En wat kost dit werk me?
Het laadicoon beantwoordt een andere vraag
Mijn eerdere ETA-verhaal ging over het plannen van mijn eigen tijd: moet ik wachten, van onderwerp wisselen of later terugkomen? Een statusregel pakt een ander deel van hetzelfde probleem aan. Voordat ik beslis wat ik hierna doe, wil ik duidelijk zicht op de sessie voor me.
Een laadicoon vertelt me dat er iets gebeurt. Een lang verslag vertelt me wat er gebeurd is. Geen van beide geeft me noodzakelijk in één oogopslag de feiten die ik zoek.
Wat de statusregel zichtbaar maakt
De bijgeleverde terminalweergave maakt het idee concreet. Eén regel brengt de gekozen route, het vastgestelde model, het contextgebruik en de kostenschattingen samen. Project- en accountidentificatoren zijn vervangen door neutrale voorbeelden.
Het routeringslabel en het model waarnaar het verwijst zijn verschillende gegevens. In deze weergave loopt de route via OpenRouter en komt die uit bij een OpenAI-model. Dit is een uitgebreide configuratie, geen uitspraak over de standaardinterface van Claude Code.
De contextweergave toont 186.551 van 1.000.000 tokens, weergegeven als 19,0%. Dat maakt een abstracte capaciteit begrijpelijker. Maar 19% context betekent niet dat de taak voor 19% klaar is en zegt op zichzelf niets over de resterende minuten.
De kostenvelden zijn expliciet schattingen of aanbiederspecifieke tellers. Die hebben hun eigen definities nodig; ik zou een getal in een statusregel niet verwarren met een gecontroleerde factuur. De prognose en automatische modus zijn extra signalen in deze configuratie, geen functies van de minimale renderer die hier wordt besproken.
Kostenbeheersing hoort in dezelfde regel
Inzicht in kosten is een van de nuttigste redenen om een statusregel toe te voegen. Een agent kan actief blijven terwijl ik het overzicht verlies over het aantal pogingen, herhalingen of parallelle sessies dat ik heb gestart. Dat wil ik merken voordat ik de rekening bekijk.
De schermafbeelding toont ‘est. $6.61’ en ‘OR today $9.31’. Dat zijn twee verschillend benoemde tellers, geen bedragen die ik zomaar moet optellen. Voordat ik erop vertrouw, moet ik hun reikwijdte, prijsbron en verversgedrag kennen. Schattingen helpen me bijsturen; de gebruiksregistratie van de aanbieder blijft de plek om de werkelijke kosten te controleren.
Mijn praktische routine zou eenvoudig zijn:
- Stel vooraf een controlepunt voor uitgaven in. Bepaal wanneer je pauzeert en verdere runs beoordeelt, in plaats van op een onaangename verrassing te wachten.
- Vergelijk de kostengroei met bruikbare resultaten. Als het bedrag blijft stijgen terwijl dezelfde test blijft mislukken, beperk dan de taak of onderzoek de blokkade voordat je om een nieuwe brede poging vraagt.
- Kies bewust de volgende stap. Een kleinere vervolgstap, een passend model of een handmatige controle kan genoeg zijn. Bij elke modelwissel blijven dezelfde kwaliteitscontroles nodig.
Een zichtbare teller is geen automatische budgetlimiet en stopt geen verzoeken. API-kosten, abonnementen en aanbiederspecifieke saldi moeten ook apart blijven. Het doel is uitgaven een bewust onderdeel van het werk te maken, naast tijd en technische kwaliteit.
Een percentage moet een bruikbare beslissing ondersteunen
Een oplopende contextwaarde is een aanleiding om over continuïteit na te denken. Zijn de volgende stappen duidelijk? Zijn belangrijke beslissingen ergens duurzaam vastgelegd? Zou een korte overdracht helpen voordat het volgende deel begint?
Er is geen universeel percentage waarbij een sessie slecht wordt. Een compacte, duidelijk afgebakende taak en een breed onderzoek stellen verschillende eisen aan het gesprek. Ik zou het getal als oriëntatie gebruiken en daarna het werk zelf bekijken.
Een contextmeter kan me ook niet vertellen of de agent toestemming of een beslissing nodig heeft. Daarvoor is een expliciet aandachtssignaal nodig, een apart onderwerp in deze reeks.
Onbekend is een bruikbaar antwoord
De minst nuttige weergave verandert ontbrekende informatie ongemerkt in een geruststellend getal. Als een veld niet beschikbaar is, moet de regel dat melden.
De schermafbeelding toont beschikbare waarden. Als een waarde ontbreekt, zie ik liever een duidelijk ‘niet beschikbaar’ dan een groene nul. Dat vertelt me welke informatie ik niet heb, in plaats van precisie te suggereren die de weergave niet kan waarmaken.
Klein genoeg om te bekijken en te verwijderen
Claude Code ondersteunt een instelbare statusregel: een lokale opdracht leest de sessie-JSON en toont de weergave. De officiële documentatie beschrijft model- en contextvelden. Dat biedt een praktisch vertrekpunt zonder nog een dashboard nodig te hebben.
Voor een minimale versie zou ik beginnen met model en context, en pas een kostenraming toevoegen als bron en reikwijdte duidelijk zijn. De renderer moet aangeleverde velden gebruiken: geen repositoryscans, geen netwerkopzoekingen en geen gespreksarchief. Dat zijn ontwerpkeuzes voor dit voorbeeld, geen beloften over iedere statusregeluitbreiding.
Voordat ik een renderer inschakel, zou ik die met bekende invoer proberen en controleren of ontbrekende waarden zichtbaar ontbreken. Voor mij zijn begrijpelijke signalen het nuttige vertrekpunt, niet een zo groot mogelijke verzameling getallen.
Het doel is minder te hoeven onthouden
Een statusregel laat een agent niet beter redeneren en vervangt geen beoordeling van zijn wijzigingen. Wel kan hij een kleine, vaste plek bieden voor informatie die ik anders moet onthouden of opzoeken.
Dat is voor mij de interessante richting voor agenttools: minder onderbrekingen om de basiscontext vast te stellen, en meer aandacht over voor beslissingen waarvoor werkelijk een mens nodig is.
Wat zou jij in één rustige regel onder je codingsessie zetten?
Bron
Officiële documentatie over de statusregel van Claude Code, gecontroleerd op 27 oktober 2026.