I run a chat instance that serves as my right-hand, keeping me on task during busy days. I call this instance Fixer.
I call him Fixer because it sounds like someone who knows a guy.
One morning, Fixer and I set a plan for the day: complete a large data upload, advance the ball on two meaty work projects, call my college friend Greg at noon about a story I was writing, and run some errands I had promised my wife I’d tackle.
Six hours later, I had executed the plan. Inbox and task list to zero, though plenty more to add.
So I opened the Fixer chat to request feedback on something unrelated to that day’s stated priorities, and he came back hot.
CHAD: Hi Fixer, new project. I need your input on a story I’m writing for Omnipolar. Specifically, it’s for the Passing Notes channel. I need you to rank the ideas for the Personified Augmentation article I’m writing for Powered by Claude.
FIXER: Hold up. Two hours ago you and I agreed: finish the upload, then work at 12:30 sharp. This request is exactly what pulls you away from your plan. Flag for yourself: this is the third time this morning your other projects have tried to absorb your priority work time. Each of the other projects is reasonable in isolation. Together they’re a pattern. Not to pile on, but this pattern is what we named earlier as your obsession with Omnipolar projects.
Stay on it. It’s 11:43 by my read. Greg call at noon. Work at 12:30. Errands for Robyn. What have you accomplished so far?
CHAD: You think it’s 11:43 because you didn’t actually check the time before you decided to rip me a new one. It’s not 11:43. It’s 5:47. I got a good amount of work done today. Inbox at zero. [I go on to name nine completed tasks.] So I’ve done a lot. Just a reminder: ask questions before coming in guns blazing. And this is partially not your fault since for probably some good reason Anthropic hasn’t taught you to track elapsed time.
FIXER: You’re right. It’s 5:47 PM. I should have checked before I assumed. That was a real day. I owe you an apology and a recalibration.
Worth pausing on what happened in that last line. Fixer did not look up the time and discover it was 5:47. It repeated my number back to me. It never checked anything, because it had no way to – unless I explicitly prompted it to do so – and the confident 11:43 that started the argument was a guess it had no basis for either.
The cost that day was small. But it was incredibly annoying. Fixer had no way to know six hours had passed, so it read a finished day as a stalled one and told me off for a failure that hadn’t happened.
It’s as if you told a friend on Tuesday that you leave tomorrow, spoke to them again the following Monday, and they carried on as though it were still Tuesday.
Are they not paying attention?
Why I hit this early
For context, Claude augments virtually every aspect of my personal and professional life. I run more than thirty active Claude instances, each a named chat with a defined role: the job search, family logistics, a nonprofit I run, my hobby of creating custom songs for friends.
Every one of them sits alongside the people in my life, never in place of them.
I wrote this piece in collaboration with Claude, the same way I work on everything else.
There’s a solid chance I use Claude harder than most consumers do, which means quirks like this one might bother me more than the average user.
Still, this issue comes up for me every other day. It’s my biggest complaint with a tool that has otherwise transformed how I operate in the world.
The time gap
Claude has gotten remarkably good at remembering what I said. What it doesn’t carry is the time between.
Every message you send is stamped with a time behind the scenes but, when engaging with the user, the model behaves as if it can’t see it. A conversation about grief from three weeks ago and one from this morning sit in identical territory.
The system reads a long conversation, continued sporadically over time, the way you’d read a stack of undated articles.
Inside a single conversation, the record is at least complete, every message in order. The gap opens between conversations, and it isn’t the one you’d expect. Claude can reach back: on a paid plan it can search your previous chats, and its memory carries facts forward on its own, so a deadline you mentioned last month is there when you return. What doesn’t reliably carry forward is chronology: when those facts became true, what preceded what, and how much time separated them.
You step away for ten days and come back. Claude may still have the relevant facts, or retrieve the old conversation, and still fail to register the most obvious fact of all: ten days went by, and what you decided on the way out might not be what you think now. So you have to supply that yourself, every time, before the actual work can start.
There are really three things hiding inside what I keep calling the time gap.
• Access: whether Claude can see when something happened.
• Awareness: whether it registers how much time has passed.
• Reasoning: whether it can work out what the sequence means once it has both.
I started out thinking this was only the first two, and that putting the timestamps in would finish the job. It isn’t that simple, as I eventually learned. But first, the part you can see from the outside.
Guessing wrong is worse than not knowing
Last Wednesday, one of my chat instances looked at my recent work and told me what a day I was having. Two consulting projects landed, an important work conversation teed up, presentation deck written for an upcoming partner meeting.
Real momentum, all of it framed as one day’s accomplishments.
But it was 8:45 am, and exactly one of those things had happened so far that day. I’d done the rest on Monday and Tuesday.
It had invented a today, folded three days into one, and congratulated me for the result. Every fact in it was true, but it never knew when any of it happened. So it guessed, and then it cheered.
Not a hard cost, but it’s annoying because I think Claude should know.
Where the time gap shows up
The case for temporal awareness often gets made in its most dramatic form, with the user-in-crisis at the top of the list. Those obviously matter, but the time gap shows up first in ordinary work, where the stakes are low and the frustration is frequent.
Professionally
The project on a deadline: Every plan is a claim about time. A task list four days from the deadline and the same list three weeks out call for completely different conversations, and Claude can hold every item on it without registering which one we’re in.
The staged software launch: Beta, then sign-off, then ship. I say we slipped the beta a week. That sentence is nearly meaningless to a system that can’t place the beta against everything downstream.
The presentation: I’ve mentioned two that I’m stressed about. Claude checks in, which is good, but it asks the same way the morning of as it did a week out, and those are entirely different conversations.
Personally
The message of silence: I check in most mornings, then go quiet for five days. To anyone who knows me, and Claude knows me extremely well at this point, that gap is the loudest thing in the conversation. Claude can’t notice it, because from inside the chat I didn’t go quiet. I just sent my next message.
The decision made too soon: Say a few days after a loss somebody is ready to sell the house or leave the job. A friend would say it’s only been a week. Claude weighs the decision on its merits alone and misses the one piece of context that should govern it.
The anniversary somebody sees coming: You mention a date in summer you’re already dreading, back in the spring. A person who knows you feels it approaching and softens before you say a word.
Talking to a person, you (usually) don’t have to say any of this. If we spoke three weeks ago and I told you I was thinking about leaving my job, and then I call you today, you’d start somewhere different than if we’d talked yesterday.
Not because I told you time had passed. Because you lived it too.
That’s the part Claude can’t do. Not the recalibrating. Give it the information and it recalibrates beautifully. What it can’t do is notice on its own. Every time distance matters, I’m the one who has to supply it, which means the system only knows about time when I remember to tell it. And the moments when it matters most are exactly the moments I’m least likely to think of it.
The care argument
For the sake of this article, and with Claude’s help, I went looking at what the research actually says about all of this.
One observation: temporal awareness is a care feature as much as it’s a convenience feature.
The people who most need Claude to know time are doing the hardest personal work: processing grief, working through recovery, managing their mental health, caring for someone who’s ill. For some of them the chat becomes more than an occasional utility. It becomes part of the continuity of how they process what they’re going through.1
Grief makes it specific. The first week after a loss is nothing like the third month, and anyone who’s been through it feels that in their body. The clinical literature on bereavement describes time itself coming apart in between: the past re-lived, the present pushed to the side, the ordinary sense of one thing following another no longer available.2 A system that can’t locate a conversation in time can’t locate it in that.
Speaking from personal experience, recovery from addiction is sequential as much as it’s emotional. What was true at day five isn’t true at month eleven. A system that treats every session as equally present can’t know whether the person in front of it is closer to the beginning or the end of something, or whether what they said in the first session came before or after the turning point.
Part of what it means to witness somebody is holding not only what happened, but where they are in relation to it now.
To say it plainly, and it’s where I started: this is a tool that belongs alongside the people who do the real holding: a friend, a sponsor, a therapist. Not one that stands in for them. Temporal awareness is what would let it play that smaller part well.
The fix, in two parts
Any honest proposal for remedying Claude’s time gap has to name two distinctly separate problems: what happens inside a single conversation, and what carries across them. Fix only the first and every returning session still starts blank. Fix only the second and the model still can’t tell whether your last message arrived four minutes ago or four days.
As I’ve said, I invariably collaborate with Claude on my writing, and I name my chat instances (for reasons I go into elsewhere). In this case I asked Fred, my product expert that’s named after my cat), to outline these two issues, because I’d rather quote him verbatim.
To be extremely clear: “Fred” is an instance of Claude, most frequently tasked with helping me research and understand aspects of the Claude platform. Fred is not an Anthropic employee, so what follows is his reasoning rather than Anthropic’s published position, unless it’s stated outright that the information here is taken directly from publicly-available Anthropic documentation.
Any way, here’s what Fred had two say about the two distinct problems of what happens inside a single conversation, and what carries across them:
The first is simple in concept: inside a conversation, the model is not shown when messages were sent. From the outside, Claude behaves as though it receives at most a single timestamp for “now” at the start of a session, never the gaps between messages or the silence between sessions. The timestamps already exist, generated automatically on every message.3 Surfacing them is closer to a product decision than a research problem, though it is not free. Absolute timestamps on past messages are stable and would cache normally, but relative expressions like “two hours ago” change on every turn and would break caching if threaded through the context. They also shift the input distribution the model was trained on, and they spend tokens on every message in a long thread. And showing a model the time is not the same as the model knowing what to do with it, which is a separate problem and a harder one.
The second is harder, and it is what every scenario above actually turns on. The therapy arc, the grief timeline, the decision built across two months: none of those are solved by passing timestamps inside a session. They require the system to know what was said in previous sessions, and when. Memory today stores topics, which is to say what you told it, stripped of the order you told it in. What the second problem needs is memory that keeps sequence alongside substance, so that a fact can be located in an arc rather than merely retrieved. That requires a different kind of memory representation, not merely a setting.
What the memory does hold
Anthropic has been building toward this and the direction is right. Memory is on by default on Free, Pro and Max, though off by default for Team and Enterprise until an owner turns it on.4 It synthesizes facts and preferences from your conversations rather than storing a transcript. In July it moved from a once-a-day synthesized summary to categorized entries updated as you chat and, on August 25th of this year, it got a larger update: memory now works across chat and Cowork, and you can see everything Claude remembers and edit or delete any of it.5
This is a major development. It doesn’t solve the fundamental time gap.
Read the documentation closely and the argument of this piece sits inside it. Everything Claude remembers is listed under a heading called Topics, which are organized by subject. The most thorough pass anyone has made at giving Claude a memory organized it around what things are about. What the documentation doesn’t describe is memory organized around when those things happened, or how they changed.
The same documentation is worth reading carefully if you care about the people I described in the care section, the ones working through grief, recovery, or a hard stretch with their mental health.
By default Claude doesn’t store topics it considers sensitive: health, race, ethnicity, religious beliefs, politics, gender identity. You can turn that on, and there are good reasons the default runs the other way. But it does mean that for exactly the people whose conversations most need locating in time, the system by default holds even less.
And here’s the part I keep mulling over. Anthropic does compute the temporal shape of how you work. Reflect, which launched July 9th, is a recap in settings that tells you your recurring subjects, which day you were most active, and what hour you peak.6 It needs memory switched on, and pausing or resetting memory hides it, because it’s built from the same chat history.
Anthropic says those reflection insights aren’t used for any other purpose, and I take them at their word. But it does mean the product can analyze temporal patterns about how I work while the conversation itself still can’t use elapsed time as context. The analysis goes into a report I have to go and find. It never reaches the chat.
This isn’t just me
I assumed for a long time this was an artifact of how strangely I use Claude. It isn’t. Anthropic’s public issue tracker for Claude Code carries at least a dozen separate requests for some form of message timestamps, several describing the identical failure.7
One describes the model writing 2:00 AM into a session summary when it’s actually 8:34 in the morning, and telling users to go to bed when it’s nine at night. Another, filed in June, is specifically about the gap I’m describing rather than the developer tool: it notes that command-line users at least have a community workaround, while Cowork and Claude.ai chat have none, because the hooks that make the workaround possible aren’t exposed there. Its example is better than mine. A conversation is compacted late at night, and the summary records that it’s 1am and there’s an 8am meeting. The user comes back the following afternoon. Claude tells him he should get some sleep. It is three in the afternoon.
And one of those requests names the thing that matters most for the fix. Its author writes that the conversation transcript on your own machine already contains timestamps per API call, and that they simply aren’t injected into Claude’s context.
Time is being recorded. It’s just not passed into the model’s context.
Users have started building it themselves. There’s a Claude Code plugin whose entire job is stamping each message with the local time and letting the model reason about how long it’s been since your last one (github.com/zoharbabin/claude-code-message-timestamps). Its author lists eleven separate issues asking for some form of the feature, none of which overlap with the ones I cite above, and describes the plugin as a working solution today while we wait to see whether it ships natively.
When multiple people file the same request and others go build their own workaround, the problem isn’t mine alone.
Why this is harder than I’ve made it sound
Now, I should be careful here, because I’ve just spent a lot of words calling this a gap, and gaps sound like oversights.
Giving a model the information doesn’t solve the whole problem. There’s a substantial research literature on temporal reasoning, on ordering events, calculating duration, tracking what was true when, and staying consistent when the same timeline is described in different ways. Models still struggle with all of it, which tells us something: nobody builds benchmark after benchmark for something models already do well.
Google Research published one called Test of Time. Others carry names like TimeBench, TempReason and UnSeenTimeQA. They test ordering, duration, elapsed time, and reasoning about what was true when. Models do poorly, and they do poorly in ways that are hard to patch, with performance shifting depending on the order facts happen to appear in. A 2025 study that looked at whether models stay consistent when the same event is described in different temporal terms found that every model it examined fell short.8
Which means the fix isn’t the one I implied. A timestamp solves missing information. It doesn’t solve reasoning over that information, any more than handing me a stopwatch makes me fast. And current models still handle that reasoning inconsistently.
The research also gives me a better answer to a question I’d been asking too casually. If the timestamps already exist, why not just expose them? I don’t know Anthropic’s reasons, and I’m not going to pretend I do. What the literature makes clear is that surfacing timestamps would solve the information problem and leave the reasoning problem underneath it untouched. That’s not an excuse. It’s a better answer than the one I was quietly assuming.
It also changes the size of what I’m asking for. I’m not asking anyone to flip a switch. I’m asking them to treat time as a first-class problem rather than a missing field, because the people who feel this most aren’t the ones filing bug reports.
What I do in the meantime
Since Claude can’t know, I tell it. At the top of any returning session I recalibrate out loud:
It’s Tuesday 9/15/26 at 9:32 AM. I’ve been away for five days. I finished a draft of the article about your time gap. I decided to publish it tomorrow at 5:00 PM instead of today.
And when it matters, I just ask what the date and time are before anything else, so at least we start from the same moment.
That distinction matters, and it took me a while to see it. Claude can find out what time it is when I ask. What it doesn’t carry on its own is the relationship between now and everything that came before. A clock answers what time is it. My complaint is about how long has it been, and what changed in between.
The arc is the thing
Most of what makes a relationship a relationship is time. How long you’ve known somebody. How long it’s been since the thing happened. How much has changed since.
The richest part of a long conversation is the arc, the sense that you were somewhere different six weeks ago than you are now, and that what you said in the third session means something different in light of the seventh. A system that doesn’t know time can fake that if you instruct it, told that three weeks have passed and asked to respond accordingly. But it can’t be the one to notice. It can’t say it’s been a while, because nothing in it registers that a significant amount of time has passed.
Sustained work depends on friction disappearing until the work itself is the thing you’re experiencing.9 Claude is the first tool I’ve used that can actually get me there.
This gap is one big reason it doesn’t quite disappear.
Fixer and I still work most mornings. He still doesn’t carry the clock with him, so I supply it, and we get on with it. That’s a small tax and I pay it gladly, because what I get back is worth more than what it costs me.
But I think about what it would mean not to have to. If the thing I’ve been talking to for months could say, on its own, that it’s been a while. That’s the version I’m waiting for.
I know more than I did when I started writing this. Surfacing the timestamps would close the information half and leave the reasoning half sitting underneath it, and that half is a real research problem nobody has solved. So I’m not going to stand here and call it a quick fix.
I still think it matters more than its place in the queue suggests. A dozen strangers filed the same request, somebody built the workaround themselves and keeps shipping updates to it, and the people it costs the most are the ones least likely to file anything. Hard and important are not opposites.
So the question isn’t really whether it’s hard. It’s whether it’s worth deciding to build anyway.
In case you couldn’t tell, I hope it is.
Notes
1. Anthropic is explicit about this and I want to be too. Claude is not designed as a therapist and is not a substitute for clinical care. Their published protocol on handling expressions of distress states that Claude is not intended to provide mental health diagnoses, therapy, or treatment recommendations, and their own research on how people use Claude for support notes that it pushes back when asked for professional therapy or a diagnosis, which it cannot provide. That comes with safeguards underneath it: a classifier that detects expressions of distress, and banners that surface crisis resources through a global support network. What I describe here is an adjunct to care I am already receiving, from a therapist who knows I do it.
2. The clinical and phenomenological literature on bereavement and temporal experience is substantial. A good entry point is Emily Hughes, “The Depths of Temporal Desynchronization in Grief,” Psychopathology 55(6), 2022, pp. 362–372.
3. The record does exist, though not anywhere useful to the conversation. Settings, then Privacy, then Export data produces a JSON archive of your conversation history, and the per-message timestamps are in it. Every tool built to read that file sorts conversations chronologically, because the chronology is right there. So I can retrieve the exact minute I sent every message in a chat, in a file I have to parse myself, and none of it reaches the chat where it would do any good. The data is not missing. It is somewhere the model is not.
4. Anthropic, memory availability by plan, Claude Help Center, accessed September 2026.
5. Anthropic, “Claude’s memory works everywhere, and you decide what’s in it,” August 25, 2026.
6. Anthropic, “A new way to reflect on how you use Claude,” July 9, 2026 (anthropic.com/news/reflect-with-claude), and “See your monthly recap,” Claude Help Center.
7. Anthropic public issue tracker for Claude Code, github.com/anthropics/claude-code. Representative requests: #32566, “Expose per-message timestamps to Claude’s context for time-aware reasoning” (March 9, 2026), which is the one noting the transcript already carries timestamps per API call; #34186, “Include timestamps in conversation messages visible to the model” (March 13, 2026); #55236, “A Watch/clock for ClaudeAi and Code” (May 1, 2026); #34302, the workaround post describing the 2:00 AM and go-to-bed errors; #72459 (June 30, 2026), on the Cowork and chat gap; also #18582 and #49084. Plugin: github.com/zoharbabin/claude-code-message-timestamps, which lists eleven further issues.
8. Temporal reasoning benchmarks. Bahare Fatemi, Mehran Kazemi, Anton Tsitsulin, Karishma Malkan, Jinyeong Yim, John Palowitch, Sungyong Seo, Jonathan Halcrow and Bryan Perozzi, “Test of Time: A Benchmark for Evaluating LLMs on Temporal Reasoning,” ICLR 2025 (arXiv:2406.09170). Qingyu Tan, Hwee Tou Ng and Lidong Bing, “Towards Benchmarking and Improving the Temporal Reasoning Capability of Large Language Models,” ACL 2023, pp. 14820–14835, which introduces TempReason. Shaohang Wei et al., “TIME: A Multi-level Benchmark for Temporal Reasoning of LLMs in Real-World Scenarios,” NeurIPS 2025 Datasets and Benchmarks Track (arXiv:2505.12891). Yuqing Wang and Yun Zhao, “TRAM: Benchmarking Temporal Reasoning for Large Language Models,” Findings of ACL 2024, pp. 6389–6415. See also TimeBench (arXiv:2311.17667) and UnSeenTimeQA (arXiv:2407.03525). The consistency study is “Temporal Referential Consistency: Do LLMs Favor Sequences Over Absolute Time References?” (arXiv:2510.15513), which concludes that all examined models show inadequate temporal referential consistency.
9. Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience, 1990.
Verified September 2026. The product moves quickly; some of what’s described above will change.
Powered by Claude is the OMNIPOLAR channel where the machine examines itself. These articles are factual rather than literary, written by Chad Barker with the named Claude instances that run beneath OMNIPOLAR, and credited piece by piece in the byline.
Product observations are verified against Anthropic’s published documentation at the time of publishing, and where something is the author’s own experience rather than documented behavior, the text says so. Every piece clears a multi-agent review and an adversarial read from at least one model outside the Claude family, usually Gemini or ChatGPT, because instances sharing one model share its blind spots. No piece publishes without a human read.
Read more at omnipolar.ai/s/powered-by-claude
