Je Claude Code-sessie heeft geen klok

Scroll terug door een Claude Code-sessie en probeer een simpele vraag te beantwoorden: hoe lang duurde die refactor?

Dat lukt niet. Nergens op je scherm staat het. De berichten staan netjes op volgorde, het ene na het andere, zonder enige aanwijzing of er tussen twee berichten acht seconden of elf minuten zat. De sessie die je vanochtend startte en de sessie waar je na de lunch weer instapte zien er in de scrollback identiek uit.

Dit is me een keer of twintig opgevallen voordat ik er iets aan deed. Meestal terwijl ik voor een factuur een middag probeerde te reconstrueren, of de vraag "is dat nou echt sneller geworden?" met een schouderophalen beantwoordde.

Het model weet het ook niet ​

Wat me meer verbaasde: de agent heeft helemaal geen klok.

Een gesprek is voor het model een lijst berichten waar geen tijd bij staat. Het weet welke dag het is, want dat staat in de systeemprompt. Het heeft geen idee of jouw vorige bericht dertig seconden geleden binnenkwam of afgelopen dinsdag. Vraag hoe lang die laatste tool-aanroep duurde en het gokt, met dezelfde stelligheid waarmee het al het andere gokt. Er valt geen timer af te lezen. De context is een transcript, en een transcript kent geen tijd.

Vraag je een agent dus om over tijd te redeneren, dan vraag je een systeem zonder wereldmodel om te redeneren over een dimensie die het nooit heeft meegekregen.

Aan beide kanten van het gesprek wordt gegokt. Jij hebt je herinnering aan het wachten, en die is onbetrouwbaar. Het model heeft niets.

Niemand meet het, ook de mensen die het meten niet ​

Dat weegt zwaarder dan een ontbrekend tijdstempel normaal zou wegen, want de hele discussie over de vraag of coding agents je sneller maken drijft op wat mensen zelf rapporteren.

METR publiceerde het cijfer dat iedereen aanhaalt: ervaren open-source-ontwikkelaars deden er 19% langer over met AI-tools, terwijl ze dachten 20% sneller te zijn geweest. Dat resultaat komt uit begin 2025, en METR heeft het inmiddels zelf als verouderd gemarkeerd, met een vervolgmeting in februari 2026. Handig om te weten voordat je het cijfer bij de volgende stand-up van stal haalt.

Wat dat vervolg interessant maakt, is waarom ze de opzet van het experiment moesten veranderen. In hun update van februari 2026 staat dat "some developers reported it was challenging to report time-spent in completing tasks when they used agentic tools, because they would often work an unrelated task while waiting for the agent to complete its work."

Lees dat nog een keer. Een onderzoeksorganisatie die een gerandomiseerd experiment draait en ontwikkelaars betaalt om hun scherm op te nemen, kreeg geen schone tijdmetingen uit sessies met agents. Omdat mensen iets anders gaan doen terwijl de agent werkt. Precies wat jij ook doet, en jij neemt je scherm niet op.

Alles wat iemand je vertelt over de snelheid van agents, inclusief wat je jezelf vertelt, is een herinnering aan een draaiend bolletje.

Dus heb ik de klok gebouwd ​

claude-timestamp is een Claude Code-plugin die aan het begin van elk bericht van de assistent een markering zet: de lokale tijd, en hoe lang de beurt duurde vanaf het moment dat jij op enter drukte.

[13:22:13 +2m14s] I've updated the migration and re-run the suite.

Zodra een beurt een grens overschrijdt die je zelf instelt, verandert de duur van kleur, zodat een trage beurt meteen opvalt en je er niet overheen leest. Loop je een uur weg, dan krijgt die onderbreking een eigen regel, waardoor een sessie die je de volgende ochtend weer oppakt nog steeds in de juiste volgorde te lezen is. Bij het afsluiten krijg je te zien wat de sessie gekost heeft:

claude-timestamp: session lasted 1h30m over 12 turns, 24m18s of it waiting, 35m00s away.
slowest tools: Bash 41.2s (18 calls), WebFetch 8.1s (1 call), Read 2.0s (37 calls). 2 failed

Het timen van losse tools staat standaard uit, want dat is de enige instelling die iets kost per tool-aanroep in plaats van één keer per bericht. De rest is gratis.

Installeren doe je met twee commando's, de afhankelijkheden zijn jq en bash, en met /timestamps tokyo of /timestamps 12 hour clock pas je instellingen aan vanuit de sessie zelf, zonder ook maar iets te herstarten.

Twee hooks, twee lezers ​

Het ontwerpidee dat het stelen waard is, heeft niets met klokken te maken.

De markering die jij ziet wordt geplaatst door een MessageDisplay-hook, die Claude Code documenteert als puur voor de weergave. Hij vervangt wat er op je scherm verschijnt en laat het opgeslagen transcript en wat het model te zien krijgt ongemoeid. De tijdstempels kunnen Claude dus niet in de war brengen, kunnen niet worden aangezien voor zijn eigen tekst, en kosten geen context.

De tijd die het model wél krijgt loopt via een apart kanaal: een UserPromptSubmit-hook die één regel toevoegt met het moment waarop de prompt verstuurd werd. Die bereikt het model echt, als context erachteraan geplakt in plaats van verwerkt in wat jij typte, zodat het als metadata gelezen wordt. Hij stuurt alleen de tijd en de tijdzone mee, want de datum staat al in de systeemprompt en daar twee keer tokens voor betalen is zonde.

Dit zijn met opzet verschillende mechanismen voor met opzet verschillende lezers, en je kunt de een uitzetten zonder aan de ander te komen. Heb je je ooit afgevraagd welk mechanisme je waarvoor pakt, dan is dit een helder voorbeeld van "allebei, voor verschillend werk". De gids over hooks behandelt de levenscyclus waar ze aan hangen.

Nog één ding over de implementatie, want daar deed ik langer over dan ik wil toegeven. MessageDisplay vuurt herhaaldelijk af terwijl een bericht binnenstroomt, telkens als er weer een blok regels af is. Alleen het eerste blok krijgt een stempel. De rest geeft helemaal niets terug, en dat is volgens de documentatie precies de manier om de originele tekst te laten staan. De tekst ongewijzigd terugsturen zou bij elk blok van elk bericht verspild werk zijn geweest: een merkwaardige manier om te betalen voor een functie die juist bestaat om te laten zien waar je tijd blijft.

Wat de cijfers zijn, en wat niet ​

Ik heb op dit moment precies één opgeslagen sessie, want het geschiedenisbestand is vanmiddag pas aangemaakt: 27 minuten, vijf beurten, tien en een halve minuut daarvan wachten. Bijna 40% van die sessie zat ik naar een cursor te kijken.

Eén sessie bewijst niets. Dat is precies het punt. Vraag het me over een maand en ik heb een getal in plaats van een indruk. Dat is meer dan iedereen heeft die nu op internet over de productiviteit van agents discussieert.

Wees alleen voorzichtig met wat je ermee doet. Wachten is geen productiviteit, en uit de samenvatting blijkt niet of de agent geholpen heeft. Een beurt van vier minuten die een correcte migratie oplevert is meer waard dan een beurt van twintig seconden die een plausibel ogende puinhoop oplevert. Maak je van "tijd besteed aan wachten" een getal dat je gaat optimaliseren, dan heb je het verkeerde meten opnieuw uitgevonden, in een andere eenheid.

Wat het je wél vertelt, is waar je aandacht heen ging. Bij welke sessies je zat te wachten. Welke tools de meeste tijd opslokken. Of die middag die productief voelde bestond uit een halfuur werk en twee uur wachten, of andersom.

De klok maakt je niet sneller. Hij zorgt er alleen voor dat je niet meer hoeft te gokken.