Repository navigation
[Bug]: Excessive background semantic/profile memory LLM calls #1453
Description
Activity
This failure mode suggests the background extractor lacks a stable work identity. Rate limits alone would cap the bill but not stop duplicate semantic/profile work from being scheduled.
I would key each extraction job by something like
(tenant, user, memory_kind, source_revision, extractor_version). Enqueue becomes idempotent; completion stores a receipt; retries reuse the same job id. If full conversation context is submitted repeatedly, the source revision/hash prevents reprocessing unchanged history.Add three independent controls:
- per-user/project concurrency and cost budget;
- a queue/status API showing pending/running/completed/failed jobs and estimated cost;
- a hard pause/cancel switch that workers check between calls.
Profile extraction should probably be delta-based: compare new source ids against the last completed watermark rather than send the full history each time. If the watermark is missing or moves backward, fail visibly instead of starting an unbounded replay.
Regression tests should simulate duplicate
add_memory, worker restart, retry after timeout, stale watermark, and queue cancellation. The acceptance invariant is simple: with no new source revision, the system reaches idle and performs zero further LLM calls.This also protects personal continuity as user-owned state rather than an invisible background process. The privacy/control principles I use are here: https://github.com/hegu-1/personal-ai-os/blob/main/docs/privacy.md
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. If this issue is still relevant, please comment to keep it open, or add the
keep-openlabel if it should remain open indefinitely (e.g., a roadmap item awaiting a champion). Thank you for your contributions.This issue was automatically closed due to inactivity. If it is still relevant, please reopen it or file a new issue referencing this one.
Describe the bug
MemMachine appears to trigger an unexpectedly large number of LLM calls for
semantic/profile memory ingestion after a relatively small amount of user
activity.
I used our internal product which integrates
Memchineto ask around 40 questions over a small knowledgeset: 4 PDF files, each under 80 pages. I did not start any other jobs or run any
batch ingestion manually.
However, starting around midnight and continuing into the evening, the system
kept calling the LLM in the background and generated about $200 in model
costs.
A captured single LLM request shows that the call was not answering my PDF
question directly. It was a
MemMachine profile/semantic memory extraction cal:<OLD_PROFILE>{}</OLD_PROFILE><HISTORY>...previous assistant answer about Apple's gross margin...</HISTORY>So the unexpected cost seems related to background semantic/profile memory
ingestion or repeated
add_memoryprocessing, not normal user-facing QA.Steps to reproduce
Possible minimal reproduction path:
add_memoryrepeatedly for the same user/project, passing fullconversation context each time.
LLM even when there is no new user activity.
Expected behavior
After the pending memory ingestion backlog is processed, MemMachine should stop
calling the LLM while idle.
LLM calls for profile/semantic memory extraction should be bounded and
predictable. For a small document set and around 40 user questions, background
memory processing should not continue for many hours or generate very high
model costs.
Ideally MemMachine should also provide safeguards such as:
Environment
MemMachine commit: af5a1a3
Additional context
one LLM call.txt