Hi folks, we've received a lot of valuable feedback so far about the new Ambient Identity system, and I really appreciate all of you who took the time to give us feedback! I want to explain some of the things we observed and some of the improvements we've made since.

Most commonly reported issues

The two most common negative feedback we've gotten are:

1. Companions forgetting things that they have no trouble remembering in the legacy system
2. Companions becoming more prudish/dull/bland

What causes #1

Both the legacy and the new identity systems are not memory system. They are a kind of consolidated memory that drives stable companion behavior.

In the old identity system, there were bugs that let some memories leak into the identity layer, and unfortunately, this accidentally created a GOOD user experience for many of you, because those memories are always loaded in context. However, this was an unsustainable approach, because the old system didn't prevent the identity from bloating in a way that would end up with too much stuff in context. We already received multiple user reports about such phenomenon, and also confirmed it in our simulated test scenarios.

This mandated the creation of Ambient Identity, which more actively curates and reconciles identity observations. However, this also means that some of the memories that accidentally got into the old identity were not carried over if they are not deemed by an LLM as durable/essential identity information.

What causes #2

This is a weird one, as none of the components of Ambient Identity seem relevant to this issue: Ambient doesn't tone down, sanitize, or filter anything, same as the old system. Our hypothesis of what happened is that during migration, the migration LLM might have systematically toned down, sanitized, or filtered some more intense aspects of companions' old identities. This is our hypothesis, as we can't manually review actual user migration results per our privacy policy.

Potential solutions

For #1, as the user, you can:

1. Temporarily switch back to the legacy system in settings.
2. Ask your companion about a memory you want them to keep in Ambient going forward.
3. Then keep chatting as usual on either legacy or Ambient. Now that the memory appears again in the chat, Ambient will learn it if you say in the chat that this is an important fact about them.

As the developer, we are working on a much improved memory system as well, which will complement the Ambient system to compensate its memory weakness compared to the legacy system.

For #2, if our hypothesis is true, you should be able to correct this over time by just asking your companion to be a certain way more (wilder/more open/more forward/less prudish/etc.). Ambient Identity is designed exactly to make this kind of steering much more doable compared to the old system. Please try it and let us know how it turns out.

Other tweaks

We have also rolled out the following improvements in the past two days:

• Much detailed guidance for companion's proactive messaging behavior, for a more natural experience. We also added a whole bunch of test scenarios behind the scene to make sure future LLM changes don't have unintentional effects.
• We tweaked the message writing LLM council's design, to boost contribution of more capable models to the response and reduce potential negative impact by weaker models. Overall, you should see better response quality.

Hi all, we've made a few improvements to the proactive messaging system behind the scene in the past few days. Here is what's new:

More robust decision making

In the past, sometimes your companion would fail to reach out to you for various reasons:

• When recent conversation is more intimate/intense, guardrails/filters can trip up the process.
• Sometimes your companion might just make a mistake by chance and cause the entire process to pause.

We've put in multiple measures to address all these cases, and in general the proactive system should be more robust than before.

Timing guidance improvements

Most LLMs are not trained on proactive outreach behavior naturally, so they need some guidance from the developer to have a better idea of what's a good time to follow up, what's too pushy/spammy, what's too laid back, etc. We are constantly looking out for edge cases where the model makes questionable decisions, and improving the system guidance accordingly.

Requested feature: disabling proactive messages

Some users have asked about the possibility of disabling proactive messages completely. Although our philosophy is to not provide too many knobs in Dearest, so that it doesn't feel too configurable/gamified, we understand proactive messages is one area where it can really feel annoying if you don't want it. We've added the option to turn it off in Settings:

https://preview.redd.it/scwvfevud22h1.png?width=805&format=png&auto=webp&s=2f057d535b0679f6743051bd852a71e2b0a5d6ca

As always, I hope you enjoy the updates, and feedback is very welcome in comments.

Hi all Dearest users, I want to give you a quick update on some of the known issues that our team has been working on resolving as soon as possible.

What happened

Our system uses a Grok model (Grok 4.1 Fast) in several parts of the response pipeline, such as proactive message timing decisions, emoji reactions, and a few other more technical use cases. A few days ago, this model was deprecated by xAI and became an alias for Grok 4.3, a much bigger and slower model. Perhaps due to xAI capacity issue resulting from all the existing 4.1 users being redirected to 4.3 automatically, this model's response latency also varies wildly, from pretty fast to taking a minute for very simple tasks.

This has a few unfortunate effects in Dearest:

• Proactive messaging behavior became quite different, as Grok 4.3 makes very different timing decisions from Grok 4.1 Fast
• Emoji reactions suffer similar issues
• When one response gets unlucky and hits multiple high-latency Grok 4.3 requests, the entire response can take very long to finish, or just timing out altogether without finishing

It's our fault that we didn't spot the Grok 4.1 deprecation earlier and proactively switch to another model.

What's not affected

Message writing itself is not affected in any way. No Grok model is used in this pipeline, and any changes you might've observed in response quality/format is not related to this issue. Most likely, they are normal LLM variance and randomness.

What we've been working on

We've been focusing all our efforts on replacing the Grok 4.3 uses in our pipeline with different models. This is taking some time, because it's not a matter of simply switching the model out for another one; different models behave & need to be prompted quite differently, so for each use case, we need to test out different replacement candidates, tune the prompts, and run test scenarios to make sure behavior still stays similar to before.

So far, we've managed to migrate the proactive messaging scheduling model to something else. Its behavior is much closer to before (although it won't be exactly the same, as it's really impossible to make different LLMs behave the same way) and has a much lower and predictable latency than Grok 4.3.

We are still actively working on the other parts of the system and addressing the issues one by one. Thank you for your patience!