DEV Community: James Wang

Shared Long-Term Memory for Claude Code and Codex, Fully Local: A Hindsight Daemon Setup Guide

James Wang — Fri, 23 Oct 2026 08:30:49 +0000

This is a start-to-finish guide to giving Claude Code and Codex CLI a shared long-term memory that runs entirely on your Mac. It uses Hindsight, an MIT-licensed agent-memory engine, in local daemon mode. Your ChatGPT plan (model gpt-6-luna) does the memory extraction, the database lives in a folder you choose, and only the repositories you list are ever remembered.

I wrote it as the runbook for setting up a second laptop. Follow the steps in order.

Versions used (Oct 2026): @vectorize-io/hindsight-coding-agents 0.8.2, hindsight-api 1.1.0, hindsight CLI 1.1.0, macOS on Apple Silicon, zsh. Newer releases may differ. See the Coding Agents docs.

What you will have at the end

Claude Code ─┐  hooks: SessionStart · UserPromptSubmit · Stop
             ├─►  Hindsight daemon (hindsight-embed)   http://127.0.0.1:9077
Codex CLI ───┘  MCP server: hindsight_* tools          │
                                                       ├─ embedded PostgreSQL (pg0)
                                                       │    data in ~/projects/hindsight-data
                                                       └─ LLM: chatgpt provider, gpt-6-luna
hindsight CLI ─────────────────────────────────────────┤
hindsight ui (web control plane, http://localhost:9999)┘

One plugin for both agents. @vectorize-io/hindsight-coding-agents installs three hooks, an MCP server with the hindsight_* tools, and a companion skill into each agent.
One memory bank per repository, named coding-agent::<repo>. Claude Code and Codex read and write the same bank, so a decision made in one is visible in the other.
Automatic capture and recall. A session's first prompt gets a memory synthesis injected. Each session is written back when it ends. Git history and a short codebase survey seed every new bank, and the survey re-runs as the code moves on.
Five knowledge pages per repo: Component map, Conventions and patterns, Core concepts, Key decisions and rationale, and Initiatives and enhancements.
Opt-in only. Repositories you don't list are never touched.

Step 1 — Prerequisites

Requirement	Why	Check / install
Claude Code and/or Codex CLI	The agents being wired	`claude --version`, `codex --version`
Node.js (npx)	Runs the plugin installer and the hooks	`node --version`
uv	The daemon is launched with `uvx`	`brew install uv`
Rust toolchain, current	Daemon mode on macOS builds a dependency (`litellm`) that has no macOS wheel	`rustup update stable`
ChatGPT plan that allows usage in third-party apps	Pays for memory extraction instead of an API key	Confirmed during sign-in (Step 3)
`hindsight` CLI (recommended)	Inspect banks, refresh pages, launch the web UI	`curl -fsSL https://hindsight.vectorize.io/get-cli \

Step 2 — Write the config file first

Create {% raw %}~/.hindsight/coding-agent.json before installing, so the first session already follows your rules:

{
  "optInOnly": true,
  "optInPaths": ["~/projects/my-repo"],
  "pageTriggerCron": "H * * * *",
  "surveyRefreshCommits": 20
}

chmod 600 ~/.hindsight/coding-agent.json

What each key does:

optInOnly: true: memory is off everywhere by default. A repository outside optInPaths is inert: no bank is created, nothing is retained, and nothing is seeded.
optInPaths: path prefixes, with ~ expanded. ~/projects/my-repo approves that repo and its git worktrees. ~/projects would approve every repo under it, each with its own bank. To add a repo later, append its path; there is nothing to reinstall.
pageTriggerCron: "H * * * *": refreshes each knowledge page at most once an hour. This is the default; writing it out makes it easy to change. H is replaced by a value hashed from the bank and page name, so pages refresh at different minutes instead of all at once. A refresh is skipped when nothing new arrived. Each refresh is one LLM synthesis per page. With a local daemon that comes out of your ChatGPT plan, so hourly is affordable. Use "H H * * *" (once a day) if you want to save plan usage.
surveyRefreshCommits: 20: the codebase survey that seeds a new bank's structural knowledge re-runs whenever 20 new commits have landed since the last survey. This is the default. In Claude Code each survey is a headless claude -p --model haiku run capped at $2 (surveyModel, surveyBudgetUsd). In Codex it runs through Codex itself. Set it to 0 to survey each repo only once, when it is first opened. Busy repos will otherwise keep re-surveying.

The installer adds "serverMode": "daemon" to this file in Step 5.

On a company laptop: list only repositories you are allowed to process this way. With the daemon, memory stays on disk locally, but the extraction step still sends transcript text to your LLM provider (OpenAI, through your ChatGPT plan). Each laptop also has its own memory. Two daemons don't sync.

Opt-in list or every repo?

The config file supports two modes. Pick one per machine:

Mode	Config	When to use it
Opt-in only (allowlist)	`"optInOnly": true` + `"optInPaths": [...]`	A work laptop, or any machine where only some repositories may be processed
Every repo (denylist)	Remove `optInOnly` and `optInPaths` entirely; exclude individual repos with `banks.<id>.disabled`	A personal machine where you want memory everywhere

Switching from opt-in to every repo means deleting the two keys:

{
  "serverMode": "daemon",
  "pageTriggerCron": "H * * * *",
  "surveyRefreshCommits": 20,
  "banks": {
    "coding-agent::private-notes": { "disabled": true }
  }
}

The change applies at your next prompt, because the hooks re-read the file on every call. MCP tools pick it up in the next session. From then on, the first session in any repo creates its coding-agent::<repo> bank, seeds it from git history (the most recent commits, 300 by default), and runs a codebase survey. The survey runs again every surveyRefreshCommits (20) new commits. In Claude Code each survey is a claude -p --model haiku run with a $2 budget cap. Every repo's transcripts now go to your extraction LLM. With a local daemon the storage stays on your Mac, but the extraction still happens at the provider. Disable the repos where that is not acceptable.

Optional per-repo controls live in the same file, keyed by bank id:

{
  "banks": {
    "coding-agent::some-repo": { "disabled": true },
    "coding-agent::big-monorepo": { "gitIngest": "full", "retainSessions": false }
  }
}

Step 3 — Sign Hindsight in to your ChatGPT plan

Hindsight's chatgpt provider uses OpenAI's official Sign in with ChatGPT flow. Hindsight registers as its own OAuth client and stores its own credentials, separate from the Codex CLI's login.

uvx --from hindsight-api-slim hindsight-admin chatgpt login

A browser window opens. Sign in and approve plan usage. The command waits for the callback on 127.0.0.1:1455, then saves ~/.hindsight/chatgpt/credentials.json with mode 0600.

You may see warnings that sentence-transformers is not installed. They come from running the admin tool out of the slim package and do not affect sign-in.

Confirm:

uvx --from hindsight-api-slim hindsight-admin chatgpt status
# Signed in: yes
# Plan usage enabled: yes

Tokens refresh automatically. Usage counts against your ChatGPT plan and shows at https://chatgpt.com/settings/usage.

Step 4 — Pin the provider and model in your shell

Add to ~/.zshrc:

# Hindsight daemon: extract memories with the ChatGPT plan, model pinned
export HINDSIGHT_API_LLM_PROVIDER=chatgpt
export HINDSIGHT_API_LLM_MODEL=gpt-6-luna

Open a new terminal and check:

echo "$HINDSIGHT_API_LLM_PROVIDER / $HINDSIGHT_API_LLM_MODEL"
# chatgpt / gpt-6-luna

Why set both explicitly:

Provider. When the daemon starts, the plugin chooses the provider in this order: HINDSIGHT_API_LLM_PROVIDER, then whichever of OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, GROQ_API_KEY is set first, then claude-code if the claude CLI is on PATH. Setting it explicitly guarantees chatgpt, even if an API key happens to be in your environment.
Model. gpt-6-luna is the chatgpt provider's default today. Pinning it keeps it if a future release changes the default. The runtime updates itself daily.
All HINDSIGHT_API_* variables in the environment that starts the daemon are passed on to it. To use a different model only for extraction, use the per-operation variables (for example HINDSIGHT_API_RETAIN_LLM_MODEL).

Step 5 — Install the plugin in daemon mode

From that new terminal:

npx @vectorize-io/hindsight-coding-agents install claude-code codex --server daemon

The output should include local extraction will use chatgpt (from HINDSIGHT_API_LLM_PROVIDER). The installer:

Agent	What gets wired
Claude Code	3 hooks merged into `~/.claude/settings.json`; MCP server registered with `claude mcp add` (user scope); skill at `~/.claude/skills/hindsight-coding-agent`
Codex CLI	3 hooks merged into `~/.codex/hooks.json`; `[mcp_servers.hindsight]` in `~/.codex/config.toml`; skill at `~/.agents/skills/hindsight-coding-agent`
Shared	Runtime copied to `~/.hindsight/coding-agents`; `"serverMode": "daemon"` written to `~/.hindsight/coding-agent.json`

Codex also needs its hooks feature flag. If ~/.codex/config.toml has no [features] section, the installer adds one for you. If the section already exists, the installer prints a reminder instead, and you add the line yourself:

[features]
hooks = true

The installer accepts either hooks = true or the older spelling codex_hooks = true, which some docs still use.

Notes:

The plugin is installed with npx, not through a Claude Code marketplace, so it is not listed under /plugin. Manage it with npx @vectorize-io/hindsight-coding-agents install | uninstall | update | stats.
If an older per-agent Hindsight plugin (such as hindsight-memory) is installed, uninstall it first so only one set of hooks runs.

Step 6 — Start the daemon and verify it

The SessionStart and Stop hooks start the daemon by themselves, in the background, whenever port 9077 is free. Start it once by hand so the slow first run (download, Rust build, model load) happens while you watch:

node ~/.hindsight/coding-agents/dist/daemon-start.js --harness claude-code

Verify:

lsof -iTCP:9077 -sTCP:LISTEN                 # a python process on localhost:9077

PID=$(lsof -tiTCP:9077 -sTCP:LISTEN)
ps eww -p $PID | tr ' ' '\n' | grep '^HINDSIGHT_API_LLM_'
# HINDSIGHT_API_LLM_PROVIDER=chatgpt
# HINDSIGHT_API_LLM_MODEL=gpt-6-luna

Under the hood, the plugin asks hindsight-embed to start the server. hindsight-embed runs hindsight-api --idle-timeout 0 --port 9077 together with an embedded PostgreSQL 18 instance managed by pg0.

Step 7 — Pin the provider in the daemon profile file

The daemon also has a per-profile env file, ~/.hindsight/profiles/coding-agent.env, created on first start. Make it agree with your shell. Then a daemon started from a context that doesn't load ~/.zshrc, such as an agent opened from the Dock, still uses ChatGPT and gpt-6-luna:

f=~/.hindsight/profiles/coding-agent.env
cp "$f" "$f.bak"
grep -n '^HINDSIGHT_API_LLM_' "$f"        # inspect what it currently says

Edit it so it contains these two lines, and remove any HINDSIGHT_API_LLM_API_KEY= line:

HINDSIGHT_API_LLM_PROVIDER=chatgpt
HINDSIGHT_API_LLM_MODEL=gpt-6-luna

chmod 600 "$f" "$f.bak"

Step 8 — Put the memory bank where you want it

By default the database lives in ~/.pg0/instances/hindsight-embed-coding-agent/data. Hindsight has no setting for this path, but pg0 follows a symlink. Here is how to move it to ~/projects/hindsight-data.

Stop the daemon and its PostgreSQL. Never copy a running database.

   kill $(lsof -tiTCP:9077 -sTCP:LISTEN)
   # wait until postgres has exited and postmaster.pid is gone
   pgrep -f 'postgres -D .*hindsight-embed-coding-agent' || echo "postgres stopped"
   ls ~/.pg0/instances/hindsight-embed-coding-agent/data/postmaster.pid 2>/dev/null || echo "clean shutdown"

Copy, verify, then swap in a symlink:

   SRC=~/.pg0/instances/hindsight-embed-coding-agent
   DST=~/projects/hindsight-data
   mkdir -p "$DST"
   cp -a "$SRC" "$DST/"                                       # -a keeps the 0700 permissions PostgreSQL requires
   diff -rq "$SRC" "$DST/hindsight-embed-coding-agent" && echo "identical"
   mv "$SRC" "$SRC.old"
   ln -s "$DST/hindsight-embed-coding-agent" "$SRC"

Restart and confirm PostgreSQL now runs from the new folder:

   node ~/.hindsight/coding-agents/dist/daemon-start.js --harness claude-code
   lsof -p $(pgrep -f 'postgres -D .*hindsight-embed-coding-agent' | head -1) | grep -m1 hindsight-data

Once everything works (Step 12), delete $SRC.old.

Keep ~/projects/hindsight-data out of git and out of iCloud Drive or Dropbox. Live syncing can corrupt a running database. To back it up, stop the daemon and copy the folder.

Step 9 — Seed memory from past conversations

From inside each opted-in repository:

cd ~/projects/my-repo
npx @vectorize-io/hindsight-coding-agents install claude-code --import-conversations
# and/or: ... install codex --import-conversations

The import reads the agent's local transcripts and keeps only sessions whose recorded working directory is this repository.
It uses LLM tokens in proportion to the history (your ChatGPT plan here). It is safe to re-run, because documents are de-duplicated by id.
Git commit messages and a codebase survey are ingested automatically at the next session start. New commits are appended as they land, and the survey re-runs every 20 commits (surveyRefreshCommits).
CLAUDE.md and Claude Code's auto-memory notes (~/.claude/projects/*/memory/*.md) are not imported. CLAUDE.md is loaded into every session anyway. To store a memory note in the bank, ask the agent to save it with the hindsight_ingest_document tool.

Step 10 — Start fresh agent sessions

The hooks read ~/.hindsight/coding-agent.json every time they run. The MCP server behind the hindsight_* tools reads it once, when it starts. After installing, start new Claude Code and Codex sessions. In an already-open Claude Code session, run /mcp → hindsight → Reconnect.

In a new session you should see the Hindsight memory banner. The tools the agent can call:

Tool	Use
`hindsight_search_knowledge_pages` / `hindsight_read_knowledge_page` / `hindsight_list_knowledge_pages`	Look up architecture, conventions, decisions
`hindsight_reflect`	Deep reasoning over all memory ("why is X like this?")
`hindsight_ingest_document`	Save notes or a document into memory
`hindsight_capture_initiative`	Track a new feature or plan as its own page
`hindsight_sync_status` / `hindsight_diagnose`	Check ingestion status and configuration

Step 11 — Point the CLI at the daemon

Without configuration the hindsight CLI targets http://localhost:8888. Point it at the daemon:

hindsight configure --api-url http://localhost:9077
chmod 600 ~/.hindsight/config

Useful commands (<bank> is coding-agent::my-repo):

hindsight health                              # Status: healthy · Database: connected
hindsight bank list
hindsight bank stats <bank>                   # nodes, links, documents, pending/failed operations
hindsight document list <bank>
hindsight operation list <bank>               # retain / consolidation / refresh jobs and their status
hindsight mental-model list <bank>            # the knowledge pages
hindsight mental-model refresh <bank> <id>    # refresh one page now
hindsight explore                             # interactive terminal explorer

The plugin also ships a one-shot status report:

node ~/.hindsight/coding-agents/dist/status.js --repo ~/projects/my-repo
# {"bank":"coding-agent::my-repo","gitlogPresent":true,"chatDocs":…,"pagesCount":5,"surveyDocs":4,"synced":true,…}

Querying another repo's memory (cross-bank)

The hindsight_* MCP tools are bound to the current repo's bank. None of them takes a bank parameter, so an agent working in repo A can't use them to ask what was decided in repo B. Use the CLI against the other bank instead:

hindsight bank list                                    # find the bank id
hindsight memory recall 'coding-agent::other-repo' "how do we handle retries on 4xx?" -o json
hindsight memory recall 'coding-agent::other-repo' "deployment steps" -t world,experience -o json

Use recall, not reflect, for cross-bank lookups. recall returns the stored memories (facts, experiences, observations) ranked by relevance. reflect synthesizes an answer through the target bank's reflect_mission and disposition. Coding-agent banks get a debugging-assistant mission, so reflect answers in that bank's voice instead of showing you what it holds.
-t/--fact-type narrows the types (world, experience, observation). Separate several with commas (-t world,experience) or repeat the flag. -o json makes the output easy for an agent to parse.
Say where a fact came from. When an agent quotes cross-bank results, it should name the source bank (coding-agent::other-repo) so nobody mistakes it for the current repo's own memory.
To make agents do this automatically, add a line like this to your global ~/.claude/CLAUDE.md (and Codex's AGENTS.md):

  - Cross-repo memory: `hindsight_*` MCP tools only see the current repo's bank. To read another repo's
    memory run `hindsight memory recall 'coding-agent::<repo>' "<question>" -o json` (recall, not reflect —
    reflect applies the target bank's mission) and cite the source bank in the answer.

If some of your repos must never inform each other, write that rule next to it. Separate banks keep the data apart, but the agent can still bridge them with this command. The CLI query is the only path across banks, so the rule only has to govern that one command.

Step 12 — Generate the knowledge pages

A new bank's pages show "No content yet." until their first hourly slot comes, which can take up to an hour. To build them right away (this only uses your ChatGPT plan):

B=coding-agent::my-repo
for id in $(hindsight mental-model list $B -o json | python3 -c "import sys,json;[print(m['id']) for m in json.load(sys.stdin)['items']]"); do
  hindsight mental-model refresh $B $id
done
hindsight operation list $B          # wait for the refresh_mental_model jobs to finish

From then on, each page refreshes at most once an hour, and only when there is new material.

Step 13 — The web UI

The CLI can launch Hindsight's web control plane (@vectorize-io/hindsight-control-plane, a Next.js app) against the API URL in your CLI config, which is the daemon. It needs Node.js.

By default it is reachable from your whole network with no login. It binds to 0.0.0.0 and requires no sign-in unless an access key is set. Launch it locked down instead:

KEY=$(openssl rand -hex 16); echo "UI access key: $KEY"
HOSTNAME=127.0.0.1 HINDSIGHT_CP_ACCESS_KEY="$KEY" hindsight ui

HOSTNAME=127.0.0.1 binds it to localhost only, so other devices on the network can't reach it. The startup log then shows Network: http://localhost:9999 instead of 0.0.0.0.
HINDSIGHT_CP_ACCESS_KEY turns on the login page. Opening / redirects to /login, and the UI's API routes return 401 until you enter the key printed above.
The line No API key configured (public access) in the log is about the key the UI sends to the daemon (HINDSIGHT_CP_DATAPLANE_API_KEY). The local daemon needs none. That line does not mean the UI itself is open.

Then:

The first run installs the control-plane package through npx, which takes about a minute. When it is ready it prints Local: http://localhost:9999 and Connecting to dataplane at: http://localhost:9077.
Open http://localhost:9999 and sign in with the key. The dashboard lists your banks. Inside a bank you can browse documents, memories, entities and the memory graph, look at the knowledge pages (mental models), check operations, and try recall and reflect queries.
Stop it when you're done:

   kill $(lsof -tiTCP:9999 -sTCP:LISTEN)

For a quick look without a browser, hindsight explore opens a terminal explorer of the same data.

How it behaves day to day

Start: the SessionStart and Stop hooks of Claude Code or Codex start the daemon in the background if port 9077 is free. Both agents and all repos share one daemon.
Stop: it does not exit when idle. Closing your agents leaves it running, using roughly 1–1.5 GB of RAM and no LLM usage while idle. It stops on reboot and comes back with the next session. To stop it yourself: kill $(lsof -tiTCP:9077 -sTCP:LISTEN).
Changing provider, model or other daemon settings: a running daemon is reused and never restarted, so stop it after any change. The next session (or daemon-start.js) starts it with the new settings.
Updates: the plugin checks npm once a day and updates its runtime. Re-run install only when a release adds new hooks.
Writes are asynchronous: a saved document appears once its retain job completes (hindsight operation list <bank>).
Logs: ~/.hindsight/coding-agents-logs/plugin.log, diag.jsonl (every reflect/retain/page event), usage.jsonl. Summary: npx @vectorize-io/hindsight-coding-agents stats.

Final checklist

[ ] ~/.zshrc: HINDSIGHT_API_LLM_PROVIDER=chatgpt, HINDSIGHT_API_LLM_MODEL=gpt-6-luna, visible in a new terminal
[ ] hindsight-admin chatgpt status: signed in, plan usage enabled
[ ] ~/.hindsight/coding-agent.json: serverMode: "daemon", pageTriggerCron: "H * * * *", surveyRefreshCommits set the way you want (20 by default, 0 = survey once), mode 600. Either optInOnly: true with the right optInPaths, or no opt-in keys plus banks.<id>.disabled for the repos to exclude.
[ ] Cross-bank lookup works: hindsight memory recall 'coding-agent::<repo>' "<question>" -o json returns results
[ ] ~/.hindsight/profiles/coding-agent.env: chatgpt + gpt-6-luna, no API-key line, mode 600
[ ] ~/.codex/config.toml: hooks = true under [features], [mcp_servers.hindsight] present
[ ] Daemon on 127.0.0.1:9077 with the right HINDSIGHT_API_LLM_* in ps eww; hindsight health healthy
[ ] ~/.pg0/instances/hindsight-embed-coding-agent → symlink to ~/projects/hindsight-data/…; PostgreSQL has files open there
[ ] Per repo: status.js --repo … shows synced: true, pagesCount: 5, surveyDocs: 4; hindsight operation list shows nothing failed
[ ] In a new agent session, hindsight_sync_status returns the same numbers as status.js
[ ] Web UI launched only with HOSTNAME=127.0.0.1 and HINDSIGHT_CP_ACCESS_KEY, and stopped when not in use (nothing listening on :9999)

Uninstall

npx @vectorize-io/hindsight-coding-agents uninstall all     # removes the hooks, MCP entries and skills install added
                                                            # (Codex's [features] hooks flag stays, since other hooks may use it)
kill $(lsof -tiTCP:9077 -sTCP:LISTEN)                       # stop the daemon
# memory data: ~/projects/hindsight-data (and the symlink in ~/.pg0/instances) — delete only if you mean it

Choosing Long-Term Memory for Hermes: 10 Options, Trade-offs, and Cloud Pricing

James Wang — Fri, 23 Oct 2026 04:56:07 +0000

Choosing Long-Term Memory for an AI agent starts with a practical question: what should the agent remember, and how will you know that it remembered correctly?

Hermes offers several approaches: curated Markdown files, a local fact database, user-modeling services, knowledge graphs, and directory-based context stores. They solve different problems and charge for different units of work.

This guide compares 10 options, including Hermes's built-in memory, with their strengths, trade-offs, integration paths, and cloud pricing. The pricing snapshot is dated October 22, 2026. All amounts are in US dollars. Annual commitments and annualized monthly prices are labeled explicitly.

This is a documentation-based comparison, not a hands-on benchmark using identical tasks. Vendor accuracy scores use different models, datasets, and cost assumptions, so they are not treated as a common leaderboard.

Start with the memory you actually need

Persistent memory can mean several things:

Personal facts and preferences: time zone, communication style, and long-term goals.
Project decisions and lessons: architectural choices, debugging findings, and working conventions.
History and change: when a preference changed or why a decision was revised.
External knowledge: documents, websites, email, and shared team material.

A small preference store and a traceable engineering knowledge base need different systems. Write down the questions you want the agent to answer before choosing the backend.

The 10 options at a glance

Option	Main use	Deployment	Cloud entry point
Hermes built-in memory	Curated facts, preferences, conversation lookup	Local	No separate memory-service fee
Honcho	User modeling and reasoning-based recall	Cloud or open-source self-hosting	$2 per million ingestion tokens; reasoning extra
OpenViking	Directory-based knowledge and tiered loading	Self-hosting documented	No managed-service quote confirmed in this review
Mem0	Automatic fact extraction and maintenance	Cloud, self-hosted server, or OSS	Free; Starter $19/month
Hindsight	Relationships, time, and synthesis across memories	Cloud or open-source self-hosting	Prepaid usage
Holographic	Lightweight local fact storage	Local	No additional model calls by default
RetainDB	Managed memory, hybrid search, and files	Cloud	Free; Builder $9/month
ByteRover	Project knowledge trees and team synchronization	Local-first, optional cloud sync	Free; Pro $15/month billed annually
Supermemory	User memory, document retrieval, and connectors	Cloud or licensed local server	Free; Pro $19/month
Memori	Tool-aware memory and production governance	OSS or managed deployments	Free allowance; production Team from $60,000/year

Hermes allows one active external memory provider at a time, while built-in memory remains active. Additional MCP tools can coexist, but that does not automatically give them another provider's background synchronization and recall lifecycle. Hermes integration documentation

1. Hermes built-in memory

Hermes stores curated facts and preferences in MEMORY.md and USER.md. Its session_search tool can retrieve earlier conversations. Official documentation

Pros

Human-readable files are easy to inspect, edit, back up, and migrate.
No additional memory account, API key, or service dependency is required.
It provides a straightforward baseline for stable project conventions and personal facts.
It remains available alongside an external provider.

Cons

Resident memory is bounded and needs curation as information accumulates.
Files alone do not provide sophisticated relationship modeling or fact reconciliation.
Sharing memory with other coding tools requires an additional integration.
Historical recall still depends on the agent choosing useful queries.

Pricing: There is no separate SaaS fee. Injected memories still occupy the main model's context and incur its normal token costs.

Best fit: Start here when a small set of stable facts and searchable conversation history may already solve the problem.

2. Honcho

Honcho focuses on understanding users over time. It maintains representations of users and agents and offers reasoning at several depths. It has a dedicated Hermes integration and an open-source core.

Pros

A good architectural match for persistent preferences, goals, and user modeling.
Ordinary context retrieval is separate from deeper reasoning.
Multiple tools can connect to a shared memory layer.
Self-hosting gives control over the infrastructure and stored memory.

Cons

Inferred user attributes require review; they are not equivalent to explicitly confirmed facts.
Frequent deep reasoning can dominate the bill.
Refresh frequency and reasoning depth need deliberate configuration.
Self-hosting transfers model provisioning and operations to you.

Cloud pricing

Operation	Published rate
Ingestion and processing	$2 per million input tokens
Context retrieval	Listed as unlimited
Background Dreaming	Included
Minimal reasoning	$0.001/query
Low reasoning	$0.01/query
Medium reasoning	$0.05/query
High reasoning	$0.10/query
Max reasoning	$0.50/query

The current personal-memory page states that new accounts receive $5 in credits, with another $5 each billing period after adding a payment method. Recurring credits do not accumulate. This uses the live page rather than older cached signup offers. Rates, credit terms

Unlimited context retrieval does not eliminate the main agent's cost of reading that context.

Best fit: A personal assistant that should maintain a coherent understanding of the same user across sessions and tools.

3. OpenViking

OpenViking organizes context as a virtual filesystem under viking://. Agents can browse directories and load L0 abstracts, L1 overviews, and L2 source content progressively.

Pros

The knowledge structure is visible and navigable.
Project or directory scope can narrow retrieval.
Summary-first loading helps control how much material reaches the agent.
Archived sessions and extracted Markdown memories can be inspected.

Cons

Running a service and configuring its models adds operational work.
Generated summaries and retrieval planning can introduce errors.
Directory design may be unnecessary overhead for a small preference store.
Product capabilities and the subset exposed by the Hermes integration should be evaluated separately.

Cloud pricing: This review did not confirm a public first-party managed-service quote. Self-hosting costs depend on compute, storage, embeddings, and language or multimodal models. This is not a claim that other hosting arrangements or commercial agreements do not exist.

Best fit: Larger, clearly structured knowledge collections where inspecting and maintaining the organization matters. Website, Hermes integration

4. Mem0

Mem0 offers automatic fact extraction and memory CRUD operations, with a managed platform and an open-source implementation.

Pros

A direct API for adding user-level memory to an existing agent.
Cloud, self-hosted, and in-process OSS deployment choices.
Explicit free and entry-level quotas make an initial trial easier to budget.
Pro adds graph memory and Dream consolidation.

Cons

Extraction can omit context or update a fact incorrectly.
Lower tiers provide substantially fewer retrieval requests than add requests.
Per-turn retrieval can exhaust the retrieval quota first.
Pro represents a substantial price increase; its capabilities should not be assumed to exist in Starter.
OSS deployments require separate model and storage choices.

Cloud pricing

Plan	Monthly price	Add requests/month	Retrieval requests/month	Projects
Hobby	$0	10,000	1,000	1
Starter	$19	50,000	5,000	1
Pro	$249	500,000	50,000	Unlimited
Enterprise	Custom	Listed as unlimited	Listed as unlimited	Unlimited

Pro includes graph memory, Dream, analytics, and private Slack support. Enterprise adds features such as SLA support, on-premises deployment, audit logs, and SSO. Current pricing

Best fit: Managed fact extraction with a simple API, provided that the retrieval quota matches the intended agent loop.

5. Hindsight

Hindsight separates retain, recall, and reflect: storing information, retrieving it, and synthesizing answers across memories. It also models entities, relationships, temporal changes, and mental models. Open-source project

Pros

A strong architectural match for questions about how a project or decision evolved.
Explicit operations distinguish retrieval from synthesis.
Cloud includes memory-side LLM, embedding, and reranking models.
An upstream-maintained Hermes integration is available.

Cons

Capturing full conversations and tool calls can increase ingestion volume.
Reflection, model refreshes, and long-term storage have separate meters.
Automatically refreshed knowledge pages can generate charges without a manual refresh.
Self-hosting requires operating databases, models, and upgrades.
Synthesized conclusions still need supporting evidence.

Cloud pricing

Operation	Rate
Retain	$10 per million input tokens
Import or restore from an export archive	$5 per million input tokens; no new fact extraction
Recall	$0.75 per million output tokens
Reflect	$0.05/call
Retrieve Model or read a knowledge page	$0.25 per million output tokens
Refresh Model or create/update a knowledge page	$0.05/call
Iris enhanced file extraction	$7.50 per million output tokens, plus normal retain
Memory storage after 30 days	$0.25 per million tokens/month, accrued daily

Cloud uses prepaid credits at $1 per credit. The homepage advertises $5 in initial credits for GitHub signup; this is not a recurring monthly allowance. Standard text extraction avoids the additional Iris charge, but retaining extracted content still costs money. Billing details, what Cloud includes

Best fit: Projects that need temporal context, entity relationships, and synthesis across multiple memories.

6. Holographic

Holographic is a local SQLite fact store combining FTS5, entity resolution, trust scoring, and holographic reduced representation retrieval. The current plugin is maintained by a community maintainer.

Pros

No API key, network access, or additional model calls by default.
Fact versions, provenance, and correction operations support inspection.
A local database is straightforward to back up.
Optional online embeddings can be enabled when needed.

Cons

Keyword and HRR retrieval should not be equated with general language-model semantic understanding.
Large paraphrases, implicit relationships, and complex synthesis need practical evaluation.
Fact organization and keywords affect recall quality.
Online embeddings change both the data flow and the cost.
Community-maintained compatibility is worth monitoring.

Pricing: The default local path has no separate memory-model service bill. Optional embeddings are billed by the chosen provider, and main-agent tokens remain separate. No managed-service quote was confirmed in this review. Current capabilities, Hermes catalog

Best fit: A modest local store of preferences, facts, and explicit decisions with minimal additional infrastructure.

7. RetainDB

RetainDB combines managed memory, hybrid retrieval, file operations, and project features.

Pros

Writes and context reads have separate, visible quotas.
The entry paid tier is inexpensive.
Memory, file knowledge, and collaboration can live in one service.
Higher plans add delta compression and larger team limits.

Cons

The standard route depends on a hosted service.
Delta Compression is not included in every tier.
The Hermes documentation identifies its standalone provider repository as needing a maintainer. That is an integration-maintenance issue, not a claim that the RetainDB service is unmaintained.
Older documentation and current pricing can differ.

Cloud pricing

Plan	Monthly price	Writes/month	Context reads/month	Scope
Starter Free	$0	20,000	5,000	1 project, 1 API key
Builder	$9	75,000	15,000	3 projects, 5 keys, 3 seats, Knowledge Graph
Pro	$29	250,000	75,000	10 projects, 20 keys, 10 seats, Delta Compression
Scale	$99	1,000,000	300,000	Unlimited projects and keys, 50 seats
Enterprise	Custom	Listed as unlimited	Listed as unlimited	Contract-specific

The pricing page also advertises 20% off annual billing. Older Hermes material lists $20/month; this table uses the current vendor pricing page. Overage behavior should be checked at checkout. Pricing, Hermes maintenance note

Best fit: Budget-conscious managed workloads with substantial read/write quotas, after checking Hermes integration compatibility.

8. ByteRover

ByteRover uses its brv CLI to manage a hierarchical knowledge tree. It is oriented toward project decisions, debugging lessons, and reusable engineering practices, with local storage and optional cloud synchronization.

Pros

Knowledge is readable and maintainable.
Selected material can be shared across devices and teams.
Recall sources can be inspected.
The Hermes integration extracts insights before context compression discards them.

Cons

Duplicate and outdated knowledge still needs curation.
LLM-driven search has its own latency and model cost.
CLI installation, login, and synchronization state add operational dependencies.
Hermes lists the standalone provider repository as needing a maintainer; the product and integration have distinct maintenance considerations.

Cloud pricing

Plan	Price	Main scope
Local	Listed as free in Hermes documentation	Local tree; model costs depend on configuration
Free cloud sync	$0	100 context files, device sync, team sharing
Pro	$15/month billed annually	Unlimited context files, priority support
Enterprise	Custom	SSO/SAML, RBAC, on-premises options

The accessible current page explicitly labels $15 as billed yearly. This review did not reliably confirm Pro's monthly-billing price or the seat-billing basis. Older retrieval-based price tables should not be substituted for the current file-based plans. Current pricing, Hermes documentation

Best fit: Coding agents that should share inspectable project knowledge with selective team synchronization.

9. Supermemory

Supermemory combines personal memory with SuperRAG document retrieval and connectors for external sources. Its Hermes plugin is maintained by the vendor.

Pros

One integration ecosystem can cover personal memory and external knowledge.
Supported updates under the same customId bill only newly added content on the token-ingestion meter.
Connectors can reduce the work of ingesting documents and cloud sources.
A local server is available for single-machine workflows.

Cons

Credits, Memory tokens, SuperRAG tokens, queries, and operations are separate meters.
Document identity changes or full replacements can incur fresh ingestion charges.
Advanced PDF extraction and some connectors require higher plans.
The current local server binary comes from a non-public codebase and is free only within its lite license limit. Open-source SDKs do not make the complete server open source.
Local extraction models and available integrations differ from the hosted service.

Cloud plans

Plan	Monthly subscription	Monthly included credits	Main differences
Free	$0	$5	APIs, plugins, 1 seat
Pro	$19	$20	Auto top-up, 3 seats
Max	$100	$130	More credits, Gmail connector
Scale	$399	$600	Advanced PDF, S3, crawler, unlimited seats
Enterprise	Custom	Contract-specific	Dedicated support and deployment options

Usage rates

Meter	Rate
Memory plain text	$5 per million SM tokens
Memory rich content	$10 per million SM tokens
SuperRAG text	$1 per million SM tokens
SuperRAG images, PDFs, audio, and video	$2 per million SM tokens
Search and traversal	$5 per million queries
Operations	$100 per million operations

Subscription credits reset monthly; purchased top-up credits do not expire. An auto-top-up purchase limit is not a hard cap on the total invoice. Workflows can use multiple meters, so budget against the endpoints actually called. Plans and rates

The local server needs your extraction model. Its default embedding model is English-oriented, so multilingual workloads should evaluate alternatives. The reviewed licensing pages did not specify a numerical lite limit; it should not be described as unlimited free usage. Local deployment, Local versus Enterprise

Best fit: Workloads combining memory with documents, websites, or cloud connectors, with room for more detailed usage accounting.

10. Memori

Memori emphasizes execution traces, structured recall, and production governance. Hermes uses an externally supplied hermes-memori CLI/provider integration.

Pros

Tool-aware memory fits production agent workflows.
Production plans include access control, audit logging, observability, and memory pooling.
Deployment choices cover managed multi-tenant, managed single-tenant, customer VPC, and on-premises arrangements.
Free Cloud and OSS routes allow smaller initial experiments.

Cons

Paid production plans are priced primarily for enterprises.
OSS, free Cloud, and production contracts are different offers.
Counts of memories created or recalled are not directly comparable to another provider's API-request quotas.
The current pricing text does not specify the free allowance's renewal period.

Cloud pricing

Plan	Published price	Scope
OSS	Software free	Bring your database, models, and infrastructure
Cloud Free	$0	5,000 memories created; 15,000 memories recalled
Team	From $60,000/year	One production agent, managed multi-tenant
Business	From $150,000/year	Multiple production agents, managed single-tenant
Enterprise	Custom	Customer VPC or on-premises, dedicated infrastructure

Team and Business annualize to $5,000 and $12,500 per month respectively. Those are annual-contract equivalents, not published monthly purchase prices. Production plans list unlimited memories, but agent and deployment scope still differ. Pricing, Hermes integration

Best fit: Organizations buying production governance and vendor support rather than a low-cost personal memory subscription.

Budget for the whole memory loop

The memory provider's price is only part of the bill.

Main-agent tokens: A free or inexpensive recall operation can still return a large context that the main model must process.

Background work: Extraction, reconciliation, reasoning, refreshes, and consolidation may run behind a simple interaction.

Operations and migration: Self-hosting requires backups, upgrades, model configuration, and troubleshooting. Changing a service URL does not necessarily migrate stored memories.

A useful budget is:

Total cost = memory subscription or metered usage
           + extraction, retrieval, and embedding costs not included
           + main-agent tokens used to read recalled context
           + self-hosted infrastructure and maintenance

Requests, tokens, synchronized files, and generated memories measure different things. One conversation is not necessarily one billable operation.

A practical shortlist

These are architectural matches, not measured performance rankings.

Primary requirement	Start by comparing
Minimal maintenance	Hermes built-in memory
Lightweight local facts	Holographic
Inspectable project knowledge shared across tools	ByteRover
Simple managed fact API	Mem0
Long-term user understanding	Honcho
Temporal context and synthesis across memories	Hindsight
Navigable, directory-based knowledge	OpenViking
Memory plus documents and connectors	Supermemory
Low entry price with substantial hosted quotas	RetainDB, with integration validation
Production governance and vendor delivery	Memori and relevant enterprise offerings

Keep built-in memory as a common baseline. Ask each candidate the same questions: did an old preference update correctly, can a decision be traced to its source, does information leak between projects, and does a deleted memory reappear?

Record ingestion, retrieval, background operations, and main-model tokens for a complete session. That connects recall behavior to cost and gives a more useful decision than a cross-vendor accuracy chart.

Snapshot limitations: Pricing and features were checked on October 22, 2026. ByteRover's monthly-billing price, Memori's free-allowance renewal period, Supermemory's numerical lite limit, and an OpenViking managed-service quote were not confirmed. Check the linked official documentation and checkout pages before purchasing or deploying.

Jev, Drex, and Laya: Three System One Decision Models Compared

James Wang — Mon, 19 Oct 2026 02:17:13 +0000

A new kind of model showed up in 2026: the System One decision model. Instead of writing an
answer token by token, it reads a piece of text (the state) plus a set of typed questions, and
returns a probability for each option in a single pass. There is nothing to parse and no free-form
output to go wrong.

Three of them are worth knowing about: Jev from TypeSafe, Drex from Nace, and Laya
from ConvAI. This post compares them as of October 2026.

One protocol, three models

All three speak the same API: POST /v1/systemone with a state and a map of questions. It is
TypeSafe's API, and Jev was the first model on it; Drex and Laya both ship as wire-compatible
replacements, so switching between them is mostly a base-URL change.

They also share the three question types:

Type	Asks	Returns
`choice`	Pick one of these named options	The pick, a confidence, and a distribution
`noul`	Is this proposition true?	P(true)
`score`	Where does this sit on an ordered scale?	Expected level and a distribution

Typical uses: routing a ticket, classifying an email, checking an extracted field, gating an
action behind a guardrail. Code keeps the workflow, permissions, and arithmetic; the model supplies
the judgment.

Side by side

	Jev 1.13 (TypeSafe)	Drex 2.0 (Nace)	Laya (ConvAI)
Weights	Closed	Open, under Open RAIL-M (use restrictions; not OSI open source)	Open, Apache 2.0
Hosted API	Yes (`api.typesafe.ai`; also via OpenRouter)	Yes (`console.nace.ai`)	No first-party API; self-host (`laya-serve`). Third-party: Vercel AI Gateway (free through October 31, 2026, billed after). Plus a demo Space
Model	Not disclosed	Qwen3.6-35B-A3B MoE (35B total, ~3B active)	Encoders: ModernBERT-large 421M, mmBERT-base 322M
Hardware to self-host	n/a	Large GPU: ~70 GB bf16, ~37 GB Q8 GGUF	Small: a T4, or CPU (193–464 ms)
Context	64K per request / 32K per question; 262K with the long-context header	128K state (hosted); self-host defaults to 16K, up to 128K	512 (English) / 1,024; up to 8K multilingual
Latency	236–316 ms p50 (independently measured)	~25 req/s per H100 (vendor)	33–40 ms on a T4 (vendor)
Zero-shot quality	The reference point	Vendor reports ahead of Jev on its Decision Index (61.25 vs 57.96), slightly behind on JevBench (85.7% vs 86.6%)	Weak: 0.362 on typed-decisions, below a 0.461 majority-class baseline
After fine-tuning	Not offered; you steer it through state and instructions	Offered as a vendor service	0.766 vs a third-party-published Jev 0.727 on the same benchmark
Many options	Up to 255; 79.2% on the full Banking77 test (77 labels)	Up to 255	Drops past ~20 options at default settings: 0.425 on Banking77
Calibration	No vendor figure; independent ECE 0.02–0.35 depending on the task	No figures published	Over-confident until temperature-fitted (0.466 → 0.081)
Languages	English primary; others, including CJK, handled less accurately	No list published	100+ (45 of 51 measured languages usable), with a built-in language router
Price	$0.042 per 1M input tokens, output free	Hosted: $0.06 per 1M input tokens (v2.0), output free, $25 signup credit. Self-host: royalty-free for personal or research use, or organizations under $1M revenue and funding; others need a commercial license	Free (self-host)
Rate limits	Set per organization in requests/s and tokens/s; the numbers are in your console, not the public docs. My test: ~850 requests/min sustained (806 calls in 57 s, 4 in flight), no 429s	Free tier: 120 requests/min, 8 in flight. Paid: 600 requests/min, 16 in flight. My test: 429s on the free tier even when paced below 110 requests/min; none after adding credit (~800 calls in about 2 minutes)	None when self-hosted; your own hardware is the limit. AI Gateway limits not published

Jev 1.14 shipped as a preview (jev-preview) on October 14; jev-latest still points to 1.13.

Which one when

Jev if you want it to work zero-shot today with the most mature SDKs and docs, and a hosted-only service is fine.
Drex if you want both doors open: a hosted API priced close to Jev today, and open weights you can move in-house later if data has to stay in your own environment (check the license if your organization is above its $1M thresholds). It also has the largest default context (128K). Self-hosting it takes a large GPU.
Laya if the task is narrow and high-volume, latency matters, and you have labeled examples to fine-tune on. It is the only one that runs comfortably on CPU or at the edge, and the only one that publishes multilingual results.

In one line: Jev is the hosted default, Drex offers the same idea both hosted and as open weights,
and Laya is a very small model you train and run yourself.

Read the benchmarks carefully

Almost none of these numbers are directly comparable:

Drex's figures are self-reported by Nace.
Laya's comparisons against Jev use Jev numbers published by third parties; the model card says they were never measured by the Laya team. The widely quoted "beats Jev" result is for a checkpoint fine-tuned on that benchmark's own training split; the base checkpoint scores below majority-class guessing on it.
Jev's latency, Banking77 and calibration figures come from two independent benchmark repos; TypeSafe itself publishes no accuracy or calibration numbers.

Because the three share a protocol, the honest way to choose is cheap: take 50–100 real decisions
from your own workload, run all three, and compare. Each model also has documented weak spots worth
testing for: injected text shifting Jev's probabilities, Laya's score questions and its noul
following option labels instead of the state.

Sources

Jev models, context and pricing and API reference
Drex, its pricing, limits and rate limits and repo
Laya model card and laya-typed-decisions, and Laya on Vercel AI Gateway
jev-benchmarks and decision-model-benchmark