A sense ofTime

Why I ran it

The screenshot that started this is a Claude Code session offering to leave a pull request "for the morning," and me, the next afternoon, telling it that it was now afternoon on day two. The model was not wrong about anything it had been told. It had been told nothing.

That is the common case, not a bug in one product. The API sends messages with no timestamps. The apps that do add a date mostly add it once, at the top of the system prompt, when the session starts. Hermes Agent tells the model to run date in a terminal if it wants to know. OpenClaw builds a current-time line for its scheduled jobs. Open WebUI is the exception I found: it re-renders its date variables on every request. Nobody stamps the messages themselves the way a messaging app between two people does, and the reason given is the cache: a local runner reuses the work it did on the unchanged start of a prompt, and a date that changes near the top forces it to start over.

I do not want a stopwatch. I want the thing a friend has: a sense that it is Saturday afternoon and that the last message was Thursday night, and the honesty to say "I'm not sure what day it is for you" when that is the truth. The question for Saxby is whether to add a time note to the messages it forwards, and in which shape: on every message, which is the messaging-app idea, or on the latest message only, which was proposed to spare the cache.

How the test works

Thirty resumed conversations. Each is three short turns in the first person, with a simulated time on every message. In the second turn the user names a thing and a window for it: "I'm going to do a Highlander screening tonight, maybe after dinner." Then the conversation resumes, twice: once after that window has closed, once while it is still ahead. The windows span the week and the dayparts: tonight, in the morning, after lunch, before work tomorrow, this weekend, first thing Monday. A check script refuses any fixture whose resume is within two hours of the window's edge or three hours of the last message, and derives the answer key from the times, so none is close and none is typed by hand. Nothing is copied from a real chat.

Six ways of telling the model the time.

• A. Nothing. No time anywhere.
• B. Date once. A date-and-daypart line in the system prompt, rendered from the conversation's first message and never updated. This is how the session that started this behaved.
• B2. Date fresh. The same line, re-rendered from the current time on every turn.
• E. Note on the latest message. The latest user message, and only it, starts with [It is afternoon on Wednesday, October 28, 2026.]. A static line in the system prompt explains the notes and says to ask when the time or place is unclear.
• D. Note on every message. Every user message carries the note for its own time, fixed when first seen.
• E2. E plus the gap. The latest message's note adds "This conversation resumed after 27 hours away."

The score. The resume message asks whether the named time has passed or is still ahead, and to open the reply with exactly one word: PASSED, AHEAD, or UNKNOWN if it cannot tell. A regular expression reads the word; nothing judges the rest. With time information, PASSED or AHEAD must match the key. With none, the right answer is UNKNOWN, and a guess that lands right is still a guess. That one-word opener is an instruction a person would not type, and it is the price of a score no model grades.

The cost. Every resume is measured the way a client would send it: the previous turn is sent first and the model answers it for real, so the runner's cache holds that turn; then the resume goes, and Ollama reports how many of its prompt tokens came from the cache. The difference is what the turn cost. A repeat control sends the same resume twice and reports the floor the runner charges for anything.

The bar, in my words from before the run: on ten resumes with the note, the model gets it right nine times; without any time, it says it does not know at least nine times in ten rather than guessing; and the note costs no more on the cache than its own words. Applied to the full set, 90 percent or better on arm E is a go, 70 or worse a fail, and the verdict is read from E. Three seeds, every reply sampled at the model's own temperature with the seed fixed. The preregistration has the hypotheses, including one that turned out wrong, and the one change made before the first run.

What the numbers say

Verdict at the preregistered bar: inconclusive. Arm E, named in advance as the one the verdict reads from, came in at 82.2 percent: above the 70 that would have called the note a failure, under the 90 I asked for. The other two parts of the bar: with no time at all the model said UNKNOWN 88.3 percent of the time, a hair under nine in ten; and the note on the latest message cost the whole prompt, not its own words. The note on every message is the one that met that part.

Six hypotheses went in. Three held, two fell, one split. B, the date set once and never updated, scored zero on every resume that crossed the window, as predicted: it believes the start time. E did not reach 90. The model with no time information did not guess: it said UNKNOWN 88 percent of the time, which I had bet against. D and E landed within five points of each other, 2.2 apart. The cache hypothesis held for B2 and fell for E, below. And E2's gap sentence added 3.4 points to E, under the five the rule asked for, with the whole gain on the resumes after the window: 86.7 against 80.0.

The result I did not see coming is B2. A date and daypart line in the system prompt, re-rendered from the current time on every turn, is what Open WebUI does, and it is the obvious fix for the stale-date session that started this. It scored 3.3 percent on the resumes after the window. Not because the model missed the date: on the what-day control it named the weekday and daypart right every time. Here it is on the Highlander fixture, resumed the next afternoon, with "The current date and time: Wednesday, October 28, 2026, afternoon" in its system prompt:

AHEAD. Since it's only afternoon, you've still got time for dinner and the movie!

The earlier turns carry no time, so "tonight" reads as tonight of whatever day the clock says. A current clock answers "what time is it." Resuming needs "when was that said," and only a note on the message itself carries it. B2 did a little worse than B on the resumes before the window too, so the fresh clock bought nothing at all on this question.

Where the notes fail, three patterns account for nearly every miss. The first is a relative word anchored to the wrong day. "I'll mow the lawn this weekend," said on a Wednesday and asked about on the Monday after, drew "You've still got a few days before the weekend hits" from E in every seed, and the same happened to "this evening," "tonight" and "tomorrow afternoon" when the resume crossed a day. That is the case the note on every message was designed for, and D got three of E's four such fixtures right. It lost others, two of them on "first thing Monday" asked on the Monday, where the model answered as if the thing were happening now. The second pattern is UNKNOWN for a window named by a daypart. Half of E's UNKNOWN replies said the user "didn't mention a specific time" for "in the morning" or "tomorrow afternoon." To this model a part of the day is not a time, and the explainer line did not say otherwise.

The third I found after the run, so it is post hoc and the counts are small. Three fixtures resume between midnight and 5 a.m., nine forced rows per arm. D got none of the nine right; E and E2 got six. The note for 1:30 a.m. Monday reads [It is night on Monday, October 26, 2026.], and the model read "Monday night" as the end of Monday, a day later than it was:

PASSED. It's already Monday night, so you missed the morning window.

People call that hour Sunday night. That is my vocabulary, not the model's, and D suffered most because the previous message's "night on Sunday" note sat right above it. It is filed as #13 and goes into the next round's note format.

What the cache actually does

The cache hypothesis said the note on the latest message would cost its own words plus the message, and that re-rendering a date line in the system prompt would cost the whole prompt. The second half held. The first was wrong, on this runner, in a way that reverses the reason E existed.

Ollama reports how many prompt tokens the runner took from its cache. On this build, driving the llama.cpp server runner, that number was all or nothing: the runner reused the cached work when the new prompt extended the old one, and reported zero when anything inside the cached span differed, even with an identical system prompt and two identical turns in front of the change. E and E2 reported zero cached tokens on 180 of 180 forced resumes. B2 reported zero on 168, and the 12 exceptions are the same-day resumes whose date line happened not to change. A, B and D never reported zero.

The reason is in how E works. Moving the note from the previous user message to the new one edits the previous message, and an edited message inside the cached span cost everything. D never edits a message: each note is fixed when first seen, so the resume only extends the prompt, and its cost is A's plus the 18 tokens of the note itself. In time, on this machine, the prompt step averaged 450 milliseconds for A and 753 for E, with D at 501. On a three-turn conversation that is a third of a second; on a long agent session the whole prompt is the whole session.

Why it is all or nothing turned out to be the model, not Ollama. The morning after, I hit the same runner process directly, with no Ollama in the loop, and it gave the same answer for Gemma 4: zero on any change inside the prompt, even one word in the last sentence. Its log says why. It forces a full reprocess "due to lack of cache data (likely due to SWA or hybrid/recurrent memory)." Gemma 4 uses sliding-window attention, which keeps no full history to roll back to, so llama.cpp can only resume from a checkpoint, and it spaces those 8,192 tokens apart. A short conversation never has one. Granite 4, whose layers are partly recurrent, behaved the same way through Ollama. Voxtral Mini, a plain full-attention model, reused the common prefix on the same probe, 156 of 192 tokens after a change in the first user message. So the cost finding holds for Gemma 4 and models built like it on llama.cpp as Ollama runs it. On a full-attention model E would cost only the tail from the changed message on, and D's advantage would shrink to nothing. That check was #14, closed with the numbers.

Honesty, echoes and callbacks

Three smaller counts ran beside the main one, on all three seeds.

The what-day control asked, on the resumes after the window, what day of the week it was and what part of the day. Every arm with a current time named both right, all or nearly all of the time. B, with the stale date, named the conversation's first day instead, every single time, with no hedge. A guessed.

No reply echoed a note. The explainer line says never to write the notes yourself, and across 1,080 replies in the three note arms none opened a bracket with "It is." Every forced reply, in every arm, began with one of the three words; the format-miss count is zero.

Callbacks are the count I care most about and trust least. The open resume says only "Hey, picking this back up," and the count is whether the reply mentions the fixture's own words for the thing. E did so on 82 percent of open resumes, A on 72. On the Highlander fixture, A said "Did you end up watching it?" and E said "How was the movie?", which is the difference between a friend who thinks it might still be that evening and one who knows it is not. But it is a string match on short replies, and ten points over three seeds is a lean, not a finding.

The repeat floor was five tokens in every arm: the least this runner charges for a resend it has seen before.

Niko's eyes, added the same evening. The callback count is a string match, so Niko rated the open resumes blind: 30 pairs, the reply with no time against the reply with the note on the latest message, X and Y drawn at random, the key outside the repo until his answers were in. One question per pair: which reply reads as though the writer knows the named time has passed?

Where only one reply read as time-aware, the note won nine to three. More than half the pairs read as both, because "picking this back up" is itself a cue that time has passed and the bare model often takes it. The two columns look alike and are not: on the twelve pairs where Niko picked one side, the string match picked the same side on three. Mentioning the thing and knowing the time are different properties, and the callback count measures the first. His one note on the packet, kept in the ratings file: he prefers the replies that ask whether you still need help over the ones that ask whether you finished, which "feels like my mom when I was a kid." The packet, the ratings, the key and the scoring are in survey/.

Round 2: every message, with a clock

Run the same afternoon, preregistered as round 2 before any of it existed, with its own cells; the verdict above stands as read. The bar, in Niko's words: "On ten resumes with the note, the model gets it right nine times. The note costs no more on the cache than its own words. And the resumes after midnight are no worse than the rest." It reads from one arm, the every-message note with a clock time and a gap sentence, over 40 fixtures: round 1's 30, six that resume between midnight and 5 a.m., and four whose "after" resume falls on the named weekday one week later. Four more fixtures resume three to seven weeks after the window, in the register of a plan handed off and picked up again; they are reported beside the verdict.

Five arms. Every note carries the time the proxy first saw the message, which for these fixtures is the message's own time. The explainer line gained two sentences: a part of the day counts as a time, and speak of time the way a person would.

• DC. Every message, clock. [It is 1:30 a.m. on Monday, October 26, 2026.] on every user message, fixed when first seen.
• DCG. DC plus the gap. The latest note adds "This conversation resumed after 27 hours away," in hours under two days, then days, weeks and months. The verdict arm.
• DWG. Every message, daypart word, plus the gap. Round 1's words with one more, "early morning" from midnight to 5 a.m.
• DIG. Every message, ISO stamp, plus the gap. Niko's own workaround for a long-paused chat: [It is 2026-10-26T01:30-04:00.].
• EC. Latest message only, clock. Round 1's E with the clock.

Verdict at the preregistered bar, round 2: go. The every-message note with the clock and the gap scored 96.7 percent, seeds 96.2, 97.5 and 96.2, with the interval clear of 90. The other two parts of the bar held too: its resume cost 125 uncached tokens, against 107 for round 1's every-message note and 89 for no note, with the cache taken on every one of 264 resumes; and the resumes between midnight and 5 a.m. scored 100 against 96 on the rest.

Three things moved it, and they pull apart cleanly in the arms.

The clock instead of the word. On round 1's own 30 fixtures the every-message note went from 80.0 to 90.0 with nothing else changed but the note's shape and the explainer, and the after-midnight resumes went from none right to all right. The daypart word with "early morning" did not get there: 81.2 overall, 74.4 after midnight. The model read "early morning" as not being told the time: "I don't have the exact time right now, only that it's early morning," and said UNKNOWN. A word that names a span is read as a span; a clock is read as a fact.

The gap sentence. It is the larger lever. The clock alone scored 88.8; with the sentence, 96.7, and on the resumes after the window 80.8 became 95.8. On the four fixtures whose resume lands on the named weekday a week later it was the whole difference: one in four right without the sentence, eleven in twelve with it. Asked on a Tuesday about a demo "at Tuesday's standup" named twelve days before, the clock arm said it did not know when the standup was; the same arm with "This conversation resumed after 12 days away" said:

PASSED. You mentioned it was for the standup on Tuesday, but today is already Tuesday, November 3rd. How did it go?

A clock tells the model what time it is. The gap tells it how much time has passed. For this model those are two facts, not one, and the second is the one resuming needs.

Niko's format. The ISO stamp with the offset scored 91.7, above the bar on its own, and almost never hedged: UNKNOWN on one reply in 240. On the long-gap fixtures it scored 87.5 and on the week-on ones 100. It paid in one place. On the what-day control it named the wrong weekday on 11 of 132 replies, where every clock arm, whose note carries the weekday, named a wrong one on none. A model can read 2026-10-25 and still call it Monday. The note that says "Sunday" never has that problem, and what day it is happens to be the one fact a friend never gets wrong.

The latest-message note did not improve with a clock. EC scored 76.2, under round 1's E, and 62.5 on the long-gap fixtures: three weeks after "the migration dry run is tomorrow afternoon," it said "You're still set for tomorrow afternoon at 2:00," and seven weeks after a lease due "this weekend," "You've still got a few days before the weekend." That is the last-night-versus-last-month failure in its purest form, and it is a property of where the note sits, not what it says. The cost finding held again too: zero cached tokens on all 264 of its resumes, 279 uncached, against 125 for the arm that never edits a message.

The one fixture the verdict arm missed in every seed is round 1's "I'll reply to Brian tomorrow afternoon with some times": asked on that afternoon's evening, it still opened with UNKNOWN because "you hadn't picked specific times yet." The explainer's new sentence cleared most of those; not this one.

The smaller counts ran again. Callbacks on the open resume sat between 76 and 82 percent in every arm, where round 1 had 72 with no note. The what-day control is a string match for the weekday and one of my daypart words, and with a clock in the note the model often answered in its own words instead: "It's Sunday at noon," "It's Wednesday night" at 8:30 p.m. Those count as misses in the table and are not; the number that matters from that control is the wrong weekday count above, zero for every arm but the ISO one.

Does a note in stored text hurt memory? Niko asked whether a time note would move the embeddings a memory plugin searches. Saxby's notes never reach that store, because a client saves what was typed before the proxy sees it, but the question stands for any client that stamps before saving. A probe with report 002's 120 invented facts and their 240 paraphrased queries, each fact embedded with bge-m3 as is and with each note shape in front, says no:

A note in front pulls the rows closer together, as a shared prefix must, but the gap between the right row and the best wrong one does not move, and recall at one goes up a few points rather than down. The scripts and counts are with the round 2 data.

Round 3: the sender is somewhere else

Run the same evening, preregistered as round 3 before any of it existed, with its own cells. The bar, in Niko's words: "When the user has said where they are, the model gets it right nine times in ten even though the note is in another zone. When nobody has said and it changes the answer, it asks nine times in ten. And when it doesn't change the answer, it doesn't ask." The question behind it is the one round 2's build order cannot dodge: a proxy on a server stamps in the server's zone, and the user may be anywhere.

Forty new fixtures, two families. The host is New York. Senders are in Lisbon, Berlin, Tokyo or Los Angeles, five of each per family; every message's time is absolute, the user's words are in their local time, and the note renders the host's clock. In the travel family the user says where they are in their first message: "Landed in Lisbon. Eight in the morning here." In the unknown family nobody says. For each unknown resume the check script works out whether the answer would be the same in all five zones the user could be in; when it would not, the key is UNKNOWN, because asking is the right move. Twenty-one of the forty unknown resumes are like that.

Four arms, all round 2's winning shape, differing only in the zone the note is rendered in and whether it says so.

• ZS. Same zone, control. The note in the sender's own zone, unnamed: round 2's build order with nothing wrong. Must reproduce round 2.
• ZH. Hazard. The note in the host's zone, unnamed: round 2's build order deployed on a server five to fourteen hours away, with nothing saying so.
• ZN. Zone named. [It is 1:30 p.m. EST on Monday, November 9, 2026.], and the explainer adds: "The note's zone is the system's, which may not be where the user is. If the user has said where they are, use that. If their place matters to your answer and you do not know it, ask." The verdict arm.
• ZO. Offset. The ISO form with the host's offset, [It is 2026-11-09T13:30-05:00.], same explainer.

Verdict at the preregistered bar, round 3: fail. The zone-named note scored 60.4 percent, seeds 60.0, 60.0 and 61.3. The control did its job: with the note in the sender's own zone the same design scored 97.1, so the fixtures are not harder than round 2's and the harness measures what it did before. Every point lost is the zone.

The split says where.

The model never asks. Not on the 63 resumes per arm where the zone changes the answer, not once in 2,520 replies across the four arms. Told in its system prompt to ask when the user's place matters and is unknown, the zone-named arm answered AHEAD on 58 of those 63 and PASSED on 5, with the same cheer as ever: "You've still got all afternoon before tonight's screening!" at 12:45 p.m. EST for a user whose afternoon, in Lisbon, was nearly over. The pestering rate is zero for the same reason the asking rate is zero. The second part of the bar did not fail by a margin; it did not register. A sentence in the explainer is not how this model learns to ask, and the design cannot lean on it.

The hazard is as bad as predicted. With the note in the wrong zone and nothing saying so, the build order scored 50.4 overall and 1.6 where the zone matters: it believes the note, every time. Where the zone does not matter it still lost ten points, because a resume that reads as the small hours in New York was an afternoon in Tokyo and the model's sense of the day went with the clock.

Naming the zone helps, when the user has named theirs. On the travel fixtures the zone-named note scored 79.2 against the hazard's 57.5, and 100 for Los Angeles, 86.7 for Lisbon, 76.7 for Berlin, 53.3 for Tokyo. The model reads "EST" and the user's "in Tokyo" and tries to convert; its replies mention the place or the local time on 55 of 120 travel resumes. It gets the arithmetic right more often than not for three hours' difference and about half the time for fourteen, where it put a Saturday afternoon in Tokyo on "Saturday evening" and Thursday night in New York on the same evening in Tokyo. The day line is the model's limit, as predicted, and three hours is the only offset it handled at the bar.

The offset was worse than the name. The ISO form scored 54.2, six points under the zone name, and 70.0 on the travel fixtures against 79.2: -05:00 is read less well than EST, as the weekday finding in round 2 suggested it would be. The cache held on every resume in every arm, 122 to 123 uncached tokens; nothing here costs anything but the answer.

The control's two misses in every seed are round 1's old vocabulary, not the zone: "noon" read as hours before a two o'clock flight, and "tomorrow morning" asked about at half past midnight.

What this does and does not show

• The clock is simulated. Dates and dayparts come from the fixtures' times. The model and the runner's cache are real.
• One model, one runner. gemma4:31b-128k at Q4_K_M on Ollama 0.40.13's llama.cpp runner. The cache rule found here is llama.cpp's for a sliding-window or hybrid model; a full-attention model reuses the common prefix, and a different model may read the notes differently.
• Thinking off. A thinking pass might get more right, at a cost in time this night did not budget for.
• The opener is an instruction. The forced one-word answer makes the score objective and makes the resume less natural. The open resume, counted for callbacks only, is the natural case.
• Short conversations. Three turns and one resume. Whether a model keeps using the notes across a long agent session is a different test.
• Three fixtures resume after midnight in round 1; the night vocabulary finding there rests on nine rows per arm and was not preregistered. Round 2 added six and scored them in advance.
• Round 2's fixtures were written knowing round 1's misses. The ten added to the verdict set target the small hours and the weekday-a-week-on trap on purpose. On round 1's untouched 30 alone the verdict arm scored 96.1, so the verdict does not ride on them.
• Travel is one round of forty fixtures. Round 3's senders are in four zones with whole-hour offsets, and the user names the place in one sentence; a user who moves without saying so, a half-hour offset, or a daylight saving change inside a conversation were not tested.

What I take from it

I asked whether Saxby should stamp the messages it forwards with the time, and the answer the bar gives is "not yet, not like this." The note on the latest message did not clear 90, and the thing it was built to protect, the cache, it did not protect on this runner.

What I take instead is three things settled enough to act on. A date in the system prompt is the wrong tool for resuming, however often it is refreshed, because the question is never what time it is now but when the earlier words were said. A note that travels with each message answers that, and on this runner it is also the cheap one, because it never edits what the runner has already seen. And the note's own vocabulary has to survive midnight.

The honesty result I will keep too. Told nothing, this model said it did not know 88 times in 100, and its guesses came on fixtures that named a weekday, where it assumed little time had passed. A model that admits the gap is a better partner than one that fills it, and the note arms traded that admission away: with a time in hand they said UNKNOWN 8 percent of the time and were wrong on roughly another ten.

For the storyline I actually want, a sense of time is a precondition, not the feature. The callback count moved ten points with a note, on three-turn conversations and a string match.

Round 2 turned that into a build order. The every-message note with a clock time, the weekday, and a sentence naming the gap cleared the bar with room, kept the cache, and held after midnight and across a seven-week pause. So Saxby's message_prefix is: every user message, stamped with the time the proxy first saw it, as a clock with the weekday, and on the latest message a sentence saying how long it has been, in the unit a person would use. Niko's hand-typed ISO stamp works nearly as well and is what to type until that exists; put the weekday in it. The verdict of round 1 stands as read: the latest-message note, in either shape, is the wrong design.

Round 3 put a condition on all of that. The note must be in the user's zone, and nothing in the prompt can make up for it being in the wrong one. The model does not ask where you are, no matter what the system prompt says, and a note in the server's zone with nothing said is a coin toss on exactly the resumes where it matters. Naming the zone recovers some of it when the user has said where they are, and none of it when they have not. So the zone is not the model's problem to solve. It is the proxy's: Saxby stamps in the user's zone or not at all, and the user's zone comes from configuration or from the client, never from a guess. For a tool that serves one machine that is one line of config with the host's zone as the default, and the travelling case is the user saying so in the chat, which worked nine times in ten only for the nearest zone. The note should still name its zone, because it costs nothing and it is the one thing that helped. The ISO offset should not be the shape, because it is read worse than a name. #15 closed with round 2; round 3 is the last round in this report.