Repository navigation
[Bug]: English timestamped messages produce Chinese/German profile output #402
Description
Area
src/everos
What happened?
I ingested a single conversation consisting entirely of English, timestamped messages between two users. Episode output is generated in English, but profile generation is not. One user’s profile is almost entirely Chinese; the other begins in English and then switches largely to German. No non-English source text was provided.
Steps to reproduce
- Ingest a conversation consisting entirely of English messages between two users via /api/v2/memory/add.
- Give each message an explicit Unix-millisecond timestamp and keep all messages in the same session.
- Call /api/v2/memory/flush for the session.
- Retrieve each user’s profile with /api/v2/memory/get using memory_type: "profile".
- Observe that the source messages and generated episodes are English, but the generated profile content is not consistently English.
- In my current reproduction, first user's profile is generated almost entirely in Chinese, while second user's profile starts in English and then switches to German.
- Re-seeding under a fresh user/session namespace reproduces the problem; an earlier run produced German profile output from the same kind of English-only input.
Environment
macos
python 3.12.13
Logs or screenshots
PROFILE summary: Colin是素食者，不吃肉类，例如火鸡。
[ei_6a764df6d12c94701ca5774e] explicit_info / 饮食偏好
description: Colin是素食者，不吃肉类，例如火鸡。
evidence: Colin提醒Kathryn自己是素食者，不要让他误点含火鸡肉的食物。
======================================================================
colin-v3 / episode
======================================================================
EPISODE 6a764e1fd12c94701ca57774 score=None chars=711 facts=0
On July 28, 2026 (Tuesday), Colin told Kathryn that the dentist had called and said he wanted a bagel. Kathryn replied that they literally have bagels.
[ei_6a764e27d12c94701ca57779] explicit_info / anniversary preference
description: Kathryn bevorzugt kleine, einfache Feiern zum Jahrestag statt teurer oder aufwendiger Veranstaltungen.
evidence: Am 2026-07-27 um 03:53:00 sagte sie explizit: 'Something small. I don't want a giant expensive dinner.'
Activity
6cef commentedon Aug 7, 2026
Discovered this while workong on a project relying on EverOS at the hackathon event in Menlo Park 8/7; event co-sponsored by Evermind.
All input to EverOS was in English via API calls. All output was unusable. Reproducible over several at least 4 runs of the same ~124 plain English text messages; no special characters.
Frustrating.
gloryfromca commentedon Oct 20, 2026
I could not reproduce this on current
main(0d5789e), and there is a plausible reason why — but the run below does not settle it, so I would rather show the evidence than close the issue on it.What I ran. A real
everos server startagainst an isolated memory root with real credentials, following your steps: one session, two users, every message in plain English with an explicit Unix-millisecond timestamp,POST /api/v2/memory/addthenPOST /api/v2/memory/flush, then the generated profiles read off disk. 40 messages between "Colin" and "Kathryn" about dinner plans, film cameras, marathon training and a newly adopted cat. LLManthropic/claude-sonnet-4-5, embedderQwen/Qwen3-Embedding-4B.What came out. Both profiles are entirely English — not a single CJK or non-ASCII letter in either:
Why it may have changed since you reported it. The profile prompts gained two rules after August, both aimed at exactly the two symptoms you saw. Tracing the published versions of
everalgo-user-memory:The first addresses a profile that comes out in a language the participants did not write in; the second addresses a profile that starts in one language and switches partway through.
What this run does not establish. Yours was ~124 messages and mine was 40, it was one run, and the output language depends heavily on which model is behind the extraction — a different LLM may still drift where this one does not. So this is evidence that the hardening works for one model at a smaller scale, not proof that the class of failure is gone.
Could you re-check on a current version? If it still drifts, the single most useful detail would be which LLM and endpoint you are using, since that is the variable this run held fixed. If it is clean now, say so and we will close it.
Thanks for the report, and sorry it cost you the hackathon.