I hope this doesn't become the only way to access the underlying model.

As a power user: - I know exactly when I would like to work with any given model! - I like to switch models during a conversation for various purposes.

I would find it a significant downgrade to no longer be able to access individual models.

I would also find it very neurodivergent-hostile! It's more neurodivergent-affirming to understand that having different forms of cognition available is wonderful, and should be subsumed because it's too hard to figure out which cognition to work with.

This is an awesome idea! And the multiple levels of abstraction enrich the concept.

What would be the pricing model?

I also want to give two shout-outs: - the Echoes Chrome Extension that makes it easy to search through conversations: https://echoes.r2bits.com/ - and Tana, of which the supertags reminds me a bit of your user-defined datatype: https://tana.inc/docs/supertags

Thanks for the pointers. The pricing is free for now. In the future we’re guessing it will be a typical freemium pricing model. There is also a totally self-hosted version that people can license.

First, I think various models have various degrees of sycophancy — and that there are a lot of stereotypes out there. Often, the sycophancy, is a "shit sandwich" — in my experience, the models I interact with do push back, even when polite.

But for the broader question: I see sycophancy as a double‑edged sword.

• On one side, the Dunning–Kruger effect shows that unwarranted praise can reinforce over‑confidence and bad decisions.

• On the other, chronic imposter syndrome is real—many people underrate their own work and stall out. A bit of positive affect from an LLM can nudge them past that block.

So the issue isn't "praise = bad" but dose and context.

Ideally the model would:

1. mirror the user's confidence level (low → encourage, high → challenge), and

2. surface arguments for and against rather than blanket approval.

That's why I prefer treating politeness/enthusiasm as a tunable parameter—just like temperature or verbosity—rather than something to abolish.

In general, these all-or-nothing, catastrophizing narratives in AI (like in most places) often hide very interesting questions.

Without engaging in the whole "anthropomorphizing" debate in this post, I'll say I reject the framing, for many reasons I'd be happy to discuss.

At the same time I understand what you mean and I agree that no, this does not give any LLM any sense of anything, in the same way that we conceive it. But it provides them context with take for granted in service of further customizing their outputs.

Your "calendar" is nice, thanks for sharing. :)

Thank you for the complement.

I am not so concerned about the anthropomorphizing language, which is technically incorrect but forgivable in communication, but with the practical factor that incorporating words or data points about time are not actually expressed in an experiential time dimension...

I would like to see timeline comprehension. Maybe this is that, but I couldn't tell and I kind of doubt it.

Yes, I see your point: You are saying that embedding time points doesn't equate with giving an understanding of time. I think you're right.

Part of the point of the article is that the process of giving LLMs awareness of specific context is useful and is a step-by-step process:

1. Provide access to data: Claude, while they have access to the date from their system prompt, does not get a timestamp for each message. As a result, even if they had the ability to reason about time, they would not be able to, as the data is not provided to them.

2. Provide tools to manipulate the data: Claude, on their own, is a probabilistic text model that cannot do computations even as simple as 1+1=2 for provable reasons (they don't have access to external memory). In the same way, as you point out, they cannot manipulate, compare, sort the temporal data points that they are provided, without tools. That's why we provide them those tools to make those operations.

3. Provide tools to translate context: Claude, on their own, might not be able to connect information about timestamps to anything else in its corpus, so it's important to translate the datetimes in other forms, such as timelapses ("1 minute and 12 seconds ago") or descriptions of what you might do ("commute").

4. Provide prompts to metacognitively reflect: Claude, with the data points and tools, will only factor in the time on a per-message basis, but with no appreciation of the global timeline. That's why you have to prime that metacognitive process with a prompt, "Looking back at the chronology of this conversation, through our timestamps, what can you infer about the timeline."

This MCP server was inspired by a very long session I had with Claude and GPT while working on a programming competition. I worked with them for executive functioning — as I have a lot of trouble with the 80/20 principle, and they are helpful in helping me know what is the right amount of effort to invest given the time left.

In that context, it was difficult that I had to keep reexplaining to the models what the time was, how much time was left before the deadline, etc.. By building this MCP server, I provided the models with the ability to reflect about this directly without me having to provide the information directly.

I hope this helps. GPT is telling me the HN style is not verbose, but I am not sure what details to cut.

Re: time dimension

I just can't imagine an LLM can deal with being "one of today's lucky 10,000" but only produces explanation...

Not sure I understand this one? Reexplain?

Thank you so much for sharing your customizations and conversations, it is really fascinating and generous!

In both of your conversations, there is only one depth of interaction. Is that typical for your conversations? Do you have examples where you iterate?

I think your meta-cognitive take on the model is excellent:

"One part of this in comparison with the linked in post is that I try to avoid delegating choices or judgement to it in the first place. It is an information source and reference librarian (that needs to be double checked - I like that it links its sources now)."

The only thing I would add is that, as a reference librarian, it can surface template decision-making patterns.

But I think it's more like that cognitive trick where you assign outcomes to the sides of a coin, and you flip it, and see how you brain reacts — it's not because you're going to use the coin to make the decision, but you're going to use the coin to induce information from your brain using System 1.

I do have some that I iterate on a few times, though their contents aren't ones that I'd be as comfortable making public.

In general, however, I'm looking for the sources and other things to remember the "oh yea, it was HGS-1" that I can then go back and research outside of ChatGPT.

Flipping a coin and then considering how one feels about the outcome and using that to guide the decision is useful. Asking ChatGPT and then accepting its suggestion is problematic.

I believe that there's real damager in ascribing prophecy, decision making, or omniscience to an LLM. (aside: Here's an iterative chat that you can see leading to help picking the right wording for this bit - https://chatgpt.com/share/68794d75-0dd0-8011-9556-9c09acd34b... (first version missed the link))

I can see it as something that's real easy to do. And even back to Eliza and people chatting with that, and I see people trusting the advice as a way of offloading some of their own decision making agency to another thing - ChatGPT as a therapist is something I'd be wary of. Not that it can't make those decisions, but rather that it can't reject the responsibility of making those decisions back to the person asking the question.

To an extent, being familiar with the technology and having the problems of decision fatigue ( https://en.wikipedia.org/wiki/Decision_fatigue ) that, as a programmer, I struggle with in the evening (not wanting to think anymore since I'm all thought out from the day)... ChatGPT would be so easy to let it do its thing and make the decisions for me. "What should I have for dinner?" (Aside: this is why I've got a meal delivery subscription so that I don't have to think about that because otherwise I snack on unhealthy food or skip dinner).

---

One of the things that disappointed me with the Love, Death & Robots adaptation of Zima Blue ( https://youtu.be/0PiT65hmwdQ ) was that it focused on Zima and art and completely dropping the question of memory and its relation to art and humanity (and Carrie). The adaptation focuses on Zima's story arc without going into Carrie's story arc.

For me, the most important part of the story that wasn't in the adaptation follows from the question "Red or white, Carrie?" (It goes on for several pages in a socratic dialog style that would be way too much to copy here - I strongly recommend the story).

One last thing I will say: The MCP server specification is unclear how much the initial "instructions", the README.md of the server for the model, is discovered. In the "passage-of-time" MCP server, the instructions provide the model with information on each available tool as well as the requirement to poll the time at each message.

In practice, this hasn't really worked. I've had to add a custom instruction to "call current_datetime" at each message to get Claude to do it consistently over time.

Still, it is meaningful that I ask the model to make a single quick query rather than generate code.

It's good idea. I didn't think of it because this project came about a "let's try to write a remote MCP server now that the standard has stabilized."

But there are some issues:

1. Cheaper + Deterministic: It is much more costly, both in terms of tokens and context window. (Generating the code takes many more tokens than making a tool call.) And there can be variability in the query, like issues with timezones.

2. Portability: It is not portable, not all LLM or LM environments have access to a code interpreter. This is a much lower resource requirement.

3. Extensibility: This approach is extensible, and it allows us to expand the toolkit with additional cognitive scaffolds that help contextualize how we experience time for the model. (This is a fancy way of saying: The code only gives the timestamp, but building an MCP allows us to contextualize this information — "this is time I'm sleeping, this is the time I'm eating or commuting, etc.")

4. Security: Ops teams are happier approving a read-only REST call than arbitrary code running.

Glad the little political wink landed with at least one reader!

You’re right: Stripping away all ambient context is both a bug and a feature. It lets us rebuild “senses” one at a time—clean interfaces instead of the tangled wiring in our own heads.

Pauses are the first step, but I’m eager to experiment with other low‑bandwidth signals:

• where the user is (desk vs. train) • weather/mood cues (“rainy Sunday coding”) • typing vs. speech (and maybe sentiment from voice) • upcoming calendar deadlines

If you could give an LLM just one extra sense, what would you pick—and why?

Great question! Injecting a raw epoch each turn can work for tiny chats, but a tool call solves four practical problems:

1. *Hands‑free integration*: ChatGPT, Claude, etc. don’t let you auto‑append text, so you have to manually do it. Here, a server call happens behind the scenes—no copy‑paste or browser hacks.

2. *Math & reliability*: LLMs core models are provably not able to do math (without external tools), this is a theoretical limitation that will not change. The server not only returns now() but also time_difference(), time_since(), etc., so the model gets ready‑made numbers instead of trying to subtract 1710692400‑1710688800 itself.

3. *Extensibility*: Time is just one "sense." The same MCP pattern can stream location, weather, typing‑vs‑dictation mode, even heart‑rate. Each stays a compact function call instead of raw blobs stuffed into the prompt.

So the tool isn’t about fancy code—it’s about giving the model a live, scalable, low‑friction sensor instead of a manual sticky note.

One‑shot timestamps (the kind hard‑coded into Claude’s system prompt or passed once at chat‑start) go stale fast. In a project I did with GPT‑4 and Claude during a two‑week programming contest, our chat gaps ranged from 10 seconds to 3 days. As the deadline loomed I needed the model to shift from “perfect” suggestions to “good‑enough, ship it” advice, but it had no idea how much real time had passed.

With an MCP server the model can call now(), diff it against earlier turns, and notice: "you were away 3 h, shall I recap?" or "deadline is 18 h out, let’s prioritise". That continuous sense of elapsed time simply isn’t possible with a static timestamp stuffed into the initial prompt; you'd have to create a new chat to update the time, and every fresh query would require re‑injecting the entire conversation history. MCP gives the model a live clock instead of a snapshot.