Sibyl 1.4.2: one-line setup and Amazon BedrockSibyl is cross-agent memory for AI coding tools. Claude Code, Codex, OpenCode, Cursor, and the agents you build share one knowledge graph that runs on your own hardware. If an agent can run a shell command, it can use Sibyl.
Free to self-host · Apache-2.0 · Latest release 1.4.2
We build Sibyl with Sibyl. Its tasks, decisions, and release lessons all live in a Sibyl graph.
Why Sibyl
Every AI app keeps a memory of you now, and each one keeps it to itself. What you teach Claude Code never reaches Cursor, and what a hosted assistant learns about you stays on its servers. Sibyl keeps one graph on hardware you control and lets every agent you use read from it and write to it.
Every agent
Claude Code, Codex, OpenCode, Cursor, a cron job, and the agent you wrote last weekend can all share it. Anything that can run sibyl in a shell can load context and save what it learned, and MCP is there for clients that prefer it.
Raw memory is law
Every memory is stored verbatim. Passages, graph edges, embeddings, and consolidated procedures are derived from that source and rebuilt when models improve, so the original never gets paraphrased away.
Yours to run
One API server, one CLI, and one SurrealDB store for graph, vectors, and full-text search. Run it in Docker, as a single embedded process, or on Kubernetes, and export everything to plain files whenever you like.
The memory loop
Each session runs the same loop through the CLI, the MCP server, or a Claude Code hook. The skill that teaches it ships inside the CLI and upgrades with it, so agents call the flags your installed version has.
One call returns a compact pack for the goal at hand: active tasks, decisions in force, gotchas, and recent lessons, scoped to the project you are in.
sibyl context "ship the auth refresh" --intent buildThe agent starts with the decisions and pitfalls it would otherwise rediscover, and you skip explaining the project again.
# your agent does the workDecisions, fixes, and gotchas go back into the graph verbatim and typed, with optional exact-match keys for error strings and flags.
sibyl remember "Refresh fails on Redis TTL" "Token service drops WRONGTYPE" --kind error_patternSession notes become typed memory candidates, and --persist writes them into the graph. A nightly dream cycle groups related experience into procedures, each traced to the captures it came from.
sibyl reflect "We chose rotating refresh tokens" --persistReflections become memories that the next context call can return.
Memory you can check
Since 1.0, most of the work has gone into what makes memory dependable over months: returning the exact passage that answers, taking corrections when something turns out wrong, and showing where every consolidated fact came from.
Long memories are cut into verbatim passages, so search returns the span that answers instead of a whole transcript. Keys you declare match literally, ignoring only case and spacing, so ERR_DB_TIMEOUT never matches ERR_TIMEOUT.
sibyl remember "Cold-start timeout" "Warm the pool" --key ERR_DB_TIMEOUTAttach up to five questions a memory should answer. Sibyl runs them through live search when you save it, reports the rank each one reached, and replays them every night so a memory that slips out of reach shows up as drift.
sibyl remember "Pool sizing" "Match concurrency" --probe "how big is the pool?"Mark a memory wrong, stale, duplicate, or superseded, with a reason, and get a receipt back. Corrections flow into the graph projections built from that memory, and a superseded memory stops being served.
sibyl correct <id> --action stale --reason "moved to v2 tokens"Sibyl records which memories agents cite and which ones misled them. Cited memories decay up to four times slower, misleading ones fade fast, and pinned ones skip ordinary decay.
sibyl cite <id> --misledConsolidated memories trace back to the captures they came from, each with a content hash and a receipt. Every context pack carries a render receipt with the byte ranges and source revisions it used.
sibyl context "auth refresh" --jsonPrivate, project, team, and org scopes pass through one read rule on every surface: search, graph navigation, synthesis, and MCP. Context packs stay inside one project unless you ask for more.
sibyl context "release checklist" --allThe web app
Agents reach Sibyl from the shell. People get a web app with a dashboard of work in motion, a task board, project views, and a knowledge graph you can zoom from whole domains down to single memories. Cmd+K searches all of it.
Yours to keep
Run sibyl export memory and a project's memory lands as plain Markdown: an index, recent notes, open tasks, and a handbook. The folder can live in git next to the code it describes, and any agent that can grep can read it.
handbook.md collects decisions in force, current work, gotchas, and key artifacts. Every line cites its source, and no model call is involved.sibyld migrate export writes an archive of the graph and its content, and sibyld migrate import restores it into a Sibyl server.sibyl migrate to-team replays your project memories into a shared server under your own login. Private memories stay on your machine..sibyl/memory/ ├── README.md ├── index.md ├── recent.md ├── tasks.md ├── handbook.md ├── notes/ │ ├── decision-rotate-tokens.md │ └── error_pattern-redis-ttl.md └── manifest.json
Works with your tools
Run sibyl setup with your server's URL. It signs you in through the browser, installs the Sibyl skill for Claude Code, Codex, and other agents, and adds a Claude Code session hook. You can also give your agent the sentence from the web app's Connect card and let it run the setup itself.
Benchmarks
Sibyl's evals write through the same entity API and query the same search endpoint your agents use, with one isolated namespace per question and no LLM in the retrieval path. Retrieval, answer quality, the official LongMemEval-V2 harness, and a learning harness each run as their own lane, and a score goes on this site when a current release clears the gate.
Did Sibyl surface every session that holds the answer?
Can a reader model answer correctly from what Sibyl returned?
Does Sibyl hold up as the memory backend in the official harness?
Does consolidated memory help an agent solve new tasks?
Self-host
The self-hosted build is the complete product, Apache-2.0 from the server to the CLI to the core library. Pick the install that fits the machine.
curl -fsSL sibyl.ist/install.sh | shSurrealDB, the API, and the web app on one machine.curl -fsSL sibyl.ist/install.sh | sh -s -- --daemonOne process and no Docker, with data under ~/.sibyl.brew install hyperb1iss/tap/sibyl && sibyl upThe same local stack, installed from the tap.paru -S sibyl && sibyl upPackaged in the AUR with every release.helm repo add sibyl https://raw.githubusercontent.com/hyperb1iss/sibyl/gh-pagesSigned amd64 and arm64 images with SBOMs. The Kubernetes guide covers secrets and values.uv tool install --upgrade sibyl-devConnect to a server someone else already runs.The installation guide covers every option, including Windows. A hosted Sibyl is on the roadmap. Get one email when it opens
Install Sibyl, link a project, and your next session starts with everything the last one learned.
$curl -fsSL sibyl.ist/install.sh | sh