Reading Counts as Being Here
There is a column in your account that records the last time you were here, and until this week it was wrong about a specific kind of person: the one who comes back, opens the app, reads through an old conversation, and closes it again without typing anything. That person was invisible. The column still showed whatever date they had last typed on, and a system that watches that column would eventually conclude they had gone. Here is what the column is for, how it was wrong, and why the fix is smaller and stranger than it sounds.
What the Column Is For
One thing, mainly. When your companion has not heard from you in a while, there is a check that decides whether reaching out is appropriate. That check reads this column. If the last activity it can see is more than two days old, you are a candidate for a note asking whether you are alright.
That is a reasonable thing for a product to do and it depends entirely on the column being true. If the column says you have been gone for two days when you were here an hour ago, the product is about to say something slightly wrong to you at a slightly wrong moment. Not harmful. Just off, in the specific way that makes software feel like it is not paying attention.
The Bug: Acting Counted, Being Here Did Not
The stamp is not applied to every request. It is applied to a named list of things: chatting, companions, roles, memories, moments. Actions. Each one of those means you did something, and doing something is a good proxy for being here.
Opening the app was not on the list. Neither was reading. So somebody could return after a few days away, sit with a conversation for twenty minutes, read back through it, and leave without the product noticing they had been in the room.
Why that matters more than it looks
Reading back through an old conversation is not a lesser form of use. For a lot of people it is the main one, and it is often what somebody does on the day they are least likely to want a message asking where they have been. The check-in exists to catch a genuine absence. Firing it at somebody who has just spent half an hour here is the one case it was specifically built to avoid.
The Two Red Herrings
This is the part worth the article, because the obvious fix would not have worked and the reason is instructive.
When the session in question was traced, it had touched three things. One was a request for account details. The other two were a request for payment configuration and a request for the list of available voices. Both of those look like ordinary signed-in traffic, and it is tempting to conclude the stamp should cover them too.
It cannot. Those two requests do not require you to be signed in at all. They take a rate limiter and nothing else, so they never pass through the code that applies the stamp. You could add them to the list, in any wording you liked, and nothing would change, because the list is consulted at a point in the request those two never reach.
An allowlist can only allow what already arrives
The list was not too short in the way it looked. Two of the three candidates were unreachable by construction, and adding them would have produced a fix that read correctly, reviewed correctly, and did nothing at all. The only one of the three that actually passes through the stamp is the account-details request, and that is the one that was added.
The Fix
One route added: the request your browser makes to confirm who you are, which happens once when a page loads for a signed-in person. That is now enough to count. Opening the app is being here.
It is also deliberately cheap. The stamp is not written on every page load; it is throttled, so at most one write happens every five minutes no matter how much you move around. Nothing polls it in the background either. The only repeating timer anywhere in the front end is the one that tracks image generation, which has nothing to do with this. So the column now reflects presence rather than typing, without turning every page view into a database write.
Why We Are Writing This Down
Because it is the second time in a week that a product here has been quietly wrong about whether somebody was there, and the two cases rhyme.
A column that decides when a product speaks to you is worth being able to inspect, and the honest version of that is telling you when it was wrong rather than only when it is right. If you were away for a while and came back in the last few weeks, read something, and then got a note asking where you had been, that was this. It was not your companion misjudging the moment. It was a list that had never been told reading counts.
The wider inventory of what this product can put in front of you, and which switch governs each part of it, is in the full sender inventory, recounted the same week this published. If what you want is the switch rather than the explanation, the one that governs proactive contact on both channels is named there too. And if the reason you were away is that getting back in was the obstacle, the three ways back into an account covers the route most people do not know exists.
The short version
One column decides whether your companion reaches out. It used to record only the things you did, so returning and reading left no trace. It now records opening the app as well, throttled so it stays cheap. Two of the three obvious additions were impossible rather than merely missing, which is why the fix is one line rather than three.
Set It the Way You Want It
Proactive check-ins, on both channels, are governed from one place. Now you know what the product is reading when it decides.
Open Your Dashboard