Memory

Point the client, memory happens. Pin when you care. Same Strix key for chat and MCP.

The idea

Strix memory is gateway-native. You point Cursor, Claude Code, Codex, or any OpenAI-compatible client at https://api.strixgate.dev/v1 with a strix_… key. Completions extract short facts, embed them, and inject a recall block on later turns. There is no Python/JS memory SDK and no Notion connector.

Pin when you care. Silent derive is the default.

How to use it

Point the client. Pick strix-auto (or another public id).
Keep working. After a few turns, derived facts show in Dashboard → Memory.
Optional: send x-strix-project (or we infer git remote / workspace). Recall is this project + default so shared prefs do not leak across repos.
Optional: pin a fact from the dashboard or MCP memory_add.

A completion may include x-strix-memory-hits. Treat it like other x-strix-* headers.

Projects

Field	Source	Default
`project`	`x-strix-project`, or git remote / workspace in the turn, else `default`	`default`

Forget-all stays account-wide. Forget this project tombstones that container and deletes its Vectorize vectors.

Builder includes 5 projects; Team includes 50. Limits apply to explicit pins, not silent derive.

HTTP (same key as chat)

POST /v1/memory — { content, kind?, importance?, project?, metadata?, categories?, ttl_days? } pin (verbatim; no deriver)
POST /v1/memory/batch — { facts: [...] } up to 20
GET /v1/memory — ?project=&kind=&category=&includes=&excludes=&metadata=&cursor=&limit= (metadata is a URL-encoded JSON object of exact-match flat primitives)
GET /v1/memory/:id — one fact + provenance (source_event_ids)
GET /v1/memory/:id/history
POST /v1/memory/:id/feedback — { value: "up" | "down" | "clear" }
PATCH /v1/memory/:id — { content?, importance? }
DELETE /v1/memory/:id
POST /v1/memory/recall — { query, project?, kind?, category?, includes?, excludes?, metadata?, limit? }
GET / POST /v1/memory/settings — enabled, retention_days, extract_instructions
POST /v1/memory/export
POST /v1/memory/forget — omit body for account-wide; { "project": "…" } for one project

extract_instructions is one account-level textarea prepended to the deriver. Not a dual user/agent instruction API.

ttl_days accepts 1–3650 days. Expired facts stop appearing in list and recall even before the cleanup job tombstones them. Category includes require every named category; any excludes match removes the fact. Metadata filters use exact key/value equality.

The dashboard exposes the same primitives: combine project, kind, category, and key=value metadata filters; pin categories/metadata/TTL; paste up to 20 newline-separated facts; page with Load more; and clear existing feedback. The table keeps categories, metadata, and expiration in dedicated sortable columns.

MCP (optional)

Same Worker, same key:

{
  "mcpServers": {
    "strix-memory": {
      "url": "https://api.strixgate.dev/mcp",
      "headers": {
        "Authorization": "Bearer strix_…"
      }
    }
  }
}

Tools: memory_search, memory_add, memory_list, memory_update, memory_delete, memory_forget_project, memory_history, memory_feedback.

Users who never enable MCP still get silent inject.

vs Mem0

Mem0 is a sidecar SDK (add / search) plus mcp.mem0.ai. Strix is the router you already call. Memory follows the API key.

Mem0	Strix
`add` / `search` / `get` / `update` / `delete`	Same via `/v1/memory*` and MCP
`history(memory_id)`	`GET /v1/memory/:id/history`
metadata + categories	Flat `metadata`, category include/exclude filters on pin/list/recall
feedback	`POST /v1/memory/:id/feedback`
custom extract instructions	`extract_instructions` on settings
`user_id` / `agent_id` / `run_id`	API key tenant + `project` (+ session fingerprint on events)
graph / entity KG	Not in Strix. Use Mem0 or a graph store if you need relations
Notion / file connectors	Not in Strix. Facts are short derived statements, not a corpus

See Strix vs Mem0.

Security

Every D1 and Vectorize read is scoped to the authenticated user_id.
Event payloads store role only (not tool args or full messages).
Vectorize metadata is tenant filters (userId, project_key, kind, factId) — not fact text. Metadata is flat primitives only.
Recall hydrates fact text from D1 after the Vectorize filter.
History, forget, and purge stay user-scoped. GDPR forget deletes history too.
MCP requires a strix_ key. Read-scoped keys cannot mutate.

Supported vs not

Supported	How
Silent extract + inject	Every public catalog model on the same `strix_` key
Project scopes	`x-strix-project` or inferred git/workspace + `default`
Pin / list / patch / delete	Dashboard, HTTP, MCP
Search (recall)	Vector + lexical + rerank
History + feedback	Per-fact audit and helpful/not
Batch pin	Up to 20 verbatim facts over HTTP or Dashboard (one per line)
Expiring pins	Optional `ttl_days` on HTTP, MCP, and Dashboard
MCP on the Worker	Same key as chat — optional
Forget project / account	Tombstone + Vectorize ids

Not supported	Use instead
Frontier in Auto	Type `strix-frontier` if you want it; Auto never picks it
Entity / knowledge graph	Mem0 or Graphiti
Notion / Drive / Gmail connectors	Short facts, not a corpus
Python/JS memory SDK	The gateway is the API
`user_id` / `agent_id` / `run_id`	Tenant is the API key; extra axis is `project`
Document RAG	Do not dump files into memory

Public cheap catalog (memory learns on all of these): strix-auto, coding, quick, deep, bug-hunt, visual, writing, research, uncensored. Hidden ids (strix-frontier, composers, mr-*) still route if typed.

Dashboard: off, delete one fact, export, forget project, or forget everything. Account delete also purges Vectorize ids. Forget by project_key deletes those vectors.

See privacy and errors and evidence.

Memory

On this page