Your Claude Code session has no clock

Scroll back through a Claude Code session and try to answer a simple question: how long did that refactor take?

You can't. Nothing on the screen says. The messages sit there in order, one after another, with no indication whether the gap between two of them was eight seconds or eleven minutes. The session you started this morning and the one you came back to after lunch look identical in the scrollback.

I noticed this about twenty times before I did anything about it. Usually while trying to reconstruct an afternoon for an invoice, or answering "did that actually get faster?" with a shrug.

The model can't tell you either ​

Here is the part that surprised me more. The agent has no clock at all.

A conversation, to the model, is a list of messages with no times attached. It knows today's date, because the system prompt says so. It has no idea whether your previous message arrived thirty seconds ago or last Tuesday.

Ask it how long the last tool call took and it will guess, confidently, the way it guesses everything else. There is no timer to read. The context window is a transcript, and a transcript is timeless.

So when you ask an agent to reason about time, you are asking a system with no world model to reason about a dimension nobody ever handed it.

Both ends of the conversation are flying blind on this. You have your memory of waiting, which is unreliable. The model has nothing.

Nobody is measuring, including the people measuring ​

This matters more than a missing timestamp usually would, because the entire argument about whether coding agents make you faster runs on self-report.

METR published the number everyone quotes: experienced open-source developers took 19% longer with AI tools while believing they had been sped up by 20%. That result is from early 2025, and METR has since marked it out of date themselves, with a continuation published in February 2026. Worth knowing before you cite it at your next stand-up.

Skip past the new estimate to the reason they had to change the experiment design. Their February 2026 update reports that "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."

Read that again. A research organisation running a randomised controlled trial, paying developers to record their screens, could not get clean time data out of agentic sessions. Because people wander off while the agent works. That is exactly what you do, and you are not recording your screen.

Everything anyone tells you about agent speed, including what you tell yourself, is a memory of watching a spinner.

So I built the clock ​

claude-timestamp is a Claude Code plugin that puts a marker in front of every assistant message: local time, and how long the turn took from the moment you pressed enter.

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

Once a turn crosses a threshold you set, the duration changes colour, so a slow turn catches your eye on the way past. Step away for an hour and the gap gets labelled on its own line, which means a session you returned to the next morning still reads in order. On exit it reports what the session cost:

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

Tool timing is off by default, because it is the one setting that costs something per tool call rather than once per message. Everything else is free.

Install is two commands, the dependency list is jq and bash, and /timestamps tokyo or /timestamps 12 hour clock changes settings from inside the session without restarting anything.

Two hooks, two audiences ​

The design point worth stealing has nothing to do with clocks.

The marker you see is drawn by a MessageDisplay hook, which Claude Code documents as display-only. It replaces what is painted on your screen and leaves the stored transcript and the model's view untouched. So the timestamps cannot confuse Claude, cannot be misread as part of its own output, and cost zero context.

The time the model gets is a separate channel: a UserPromptSubmit hook that adds one line saying when the prompt was sent. That one does reach the model, appended as context rather than folded into what you typed, so it reads as metadata. It sends the time and the zone only, since the date is already in the system prompt and paying tokens for it twice would be silly.

Those are deliberately different mechanisms for deliberately different readers, and either can be switched off without touching the other. If you have ever wondered which mechanism to reach for, this is a clean example of the answer being "both, for different jobs". The hooks guide covers the lifecycle they hang off.

One implementation note, because it took me a while to get right. MessageDisplay fires repeatedly as a message streams, once per batch of completed lines. Only the first batch gets stamped. The rest return nothing at all, which the docs define as the way to leave the original text on screen.

Echoing the text back unchanged would have been a wasted round trip on every batch of every message, which is a strange way to pay for a feature that exists to tell you where your time goes.

What the numbers are, and what they aren't ​

I have exactly one recorded session as I write this, because the history file was written this afternoon: 27 minutes, five turns, ten and a half minutes of it waiting. Almost 40% of that session was me watching a cursor.

One session proves nothing. That is rather the point. Ask me in a month and I will have a number, which is more than anyone arguing about agent productivity on the internet currently has.

Be careful what you do with it, though. Wall-clock waiting is not productivity, and the summary cannot tell you whether the agent helped. A turn that took four minutes and produced a correct migration beats one that took twenty seconds and produced a plausible mess. If you turn "time waiting" into a number you optimise, you have reinvented measuring the wrong thing with a different unit.

What it does tell you is where your attention went. Which sessions had you sitting there. Which tools eat the wall clock. Whether the afternoon that felt productive was thirty minutes of work and two hours of waiting, or the other way round.

The clock does not make you faster. It just stops you guessing.