Skip to content

fix: strip profile embedding vectors from memory tool output and profile API - #304

Closed
share121 wants to merge 4 commits into
tickernelz:mainfrom
share121:fix/strip-profile-embeddings
Closed

share121 wants to merge 4 commits into
tickernelz:mainfrom
share121:fix/strip-profile-embeddings

Conversation

@share121

Copy link
Copy Markdown
Contributor

Summary

Each profile item persists two 768-dimension embeddings (centroid and anchor) that are only used internally for similarity, dedup and drift detection. Both the memory tool's profile mode and GET /api/user-profile serialized the raw profileData, so they shipped those vectors to callers. A populated profile (18 items: 8 preferences + 8 patterns + 2 workflows) serialized to ~591 KB, which exceeded the tool-output limit and got truncated — the profile result was unusable and burned model context (observed as a truncated ~594 KB tool response).

This change strips centroid/anchor from serialized profile data. The vectors are still stored and used internally; they are only removed from what leaves the process.

Changes

  • src/services/user-profile/profile-utils.ts: add stripProfileEmbeddings(data) that deletes centroid/anchor from every item in preferences/patterns/workflows.
  • src/index.ts: apply it to the profile read branch of the memory tool.
  • src/services/api-handlers.ts (handleGetUserProfile): apply it to the API response that feeds the Web UI.
  • tests/profile-utils.test.ts: cover stripping across all three item types plus missing/malformed sections.

Testing

  • bun test tests/profile-utils.test.ts — 2 pass
  • bunx tsc (build) — clean
  • bun test — 465 pass / 2 fail; both failures are Windows-environment only and unrelated to this change:
    • tests/onnxruntime-resolve.test.ts — EPERM creating a symlink
    • tests/turso-legacy-migrator.test.ts — EBUSY unlinking a locked db file
  • bunx prettier --check on the changed files — clean
  • Manual: live profile payload 361,121 → 4,313 bytes after stripping; GET /api/user-profile returns 4,812 bytes with no centroid; memory search still returns the expected results.

Notes

  • No behavior change other than response size; stored profile data is untouched.
  • Observed locally on Windows, opencode-mem 2.26.0. No upstream issue was filed for this.

Signed-off-by: share121 <me@s121.top>
OpenCode v2 resolves plugin-directory entrypoints from the root
index.ts/js/mjs file and does not read package.json exports, so a
local checkout configured via plugins was silently skipped. Re-export
the built entrypoint from the repository root so the directory loads.
OpenCode v2 no longer emits the deprecated session.idle event, nor an
idle session.status, so the V1 idle handler that drives auto-capture and
user-profile learning never fired. Map a finished session execution
(succeeded/failed/interrupted) back to session.idle so the existing idle
pipeline runs again.
@EyJunge1

EyJunge1 commented Oct 1, 2026

Copy link
Copy Markdown
Collaborator

Thanks @share121 — the embedding-strip approach here was correct and fixed a real truncation problem.

Closing in favor of #343, which rebases the core change onto current main and also:

  • strips embeddings from snapshot + AI-cleanup responses (while keeping them in pendingCleanups for apply)
  • uses toPublicProfileData (clone + strip) to avoid in-place mutation of retained objects
  • drops the unrelated index.js / v2 idle commits that conflicted with fix: restore OpenCode v2 auto-capture (#331) #332

Credit for the original fix remains with you.

@EyJunge1

EyJunge1 commented Oct 1, 2026

Copy link
Copy Markdown
Collaborator

Superseded by #343 (clean rebase + remaining API leak paths).

@EyJunge1 EyJunge1 closed this Oct 1, 2026
EyJunge1 added a commit that referenced this pull request Oct 1, 2026
Keep centroid/anchor for internal similarity and pending cleanup apply,
but omit them from memory-tool profile reads and profile API payloads
so responses stay small enough for the model and UI.

Based on work by share121 in #304.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants