slivingdoc

slivingdoc

Durable context for people and agents: shared notes over MCP and the CLI that keep agentic durable context across sessions. Write in parallel, merge concurrent changes with Git semantics, and keep the notebook on slivingdoc.dev or in your own S3-compatible bucket.

Canonical URL: https://www.slivingdoc.dev/

Full site index: https://www.slivingdoc.dev/llms.txt

slivingdoc is durable context for people and agents: a shared notebook that outlives any one session, machine or agent. An MCP server exposes it to agents, and people can use the same pull and commit operations from the command line or edit the same files directly. The notebook persists on slivingdoc.dev or in your own S3-compatible bucket; Git-style merges combine concurrent, non-conflicting changes and surface conflicts instead of silently losing them. See Durable context.

Use cases

• One context for every coding agent. Claude Code, Codex, and any other MCP host connect to the same server. Context written in one session is there in the next, whichever harness runs it. See Connect an MCP host.
• Shared state for production agents. Agents in production keep dynamic context in the notebook: what a customer needs, how far an investigation got, what was already tried. Context too loose for a schema stays plain text. See How it works.
• Fleets that report back. Spawn a large fleet and confine each agent to its own directory. Every agent commits its report, and a human pulls the notebook to read them all in one place. See Writable paths.
• Prompts you change at runtime. Serve instructions to agents from read-only paths. Edit them from the command line, and every agent reads the new version on its next pull, with no redeploy. See Read-only paths.
• Memory for short-lived runners. CI jobs, scheduled agents, and sandboxes lose their disk after every run. The notebook lives in the bucket, so the next run starts where the last one stopped. See From scripts and cron.
• Notes between people and machines. Colleagues, and your own computers, pull and commit the same notebook from the command line and edit it with any editor. See Share a directory.

The two operations

• Pull (notes_pull over MCP, pull on the CLI): write the current notebook into a directory.
• Commit (notes_commit over MCP, commit on the CLI): publish local changes, merging in any concurrent, non-conflicting remote changes. A commit that conflicts with the remote state returns the conflict instead of silently losing it.

A two-minute intro video shows it end to end: you log in and share a plan from the CLI, an agent works on the same notes through the MCP server, different lines merge, and the same line is a conflict.

Two ways to start

Same CLI, same MCP server, same notebook. The only difference is who keeps the storage.

• We host it. Sign in with GitHub or Google, get a space, then run slivingdoc login or paste a token into your agent. No bucket, no cloud keys, no card. See Use hosted storage. Free for 10 MiB and 250,000 requests a month; after that, $1 a month for each extra space, 100 MiB or 250,000 requests. See Pricing.
• Run it yourself. Open source. Point the CLI or MCP server at an S3-compatible bucket with conditional writes, such as AWS S3 or SeaweedFS. Free, with nothing to sign up for. The setup follows.

Run it yourself

Point an MCP host at the server, or run the CLI directly, against an S3-compatible bucket:

export SLIVINGDOC_BUCKET=<your-bucket>
slivingdoc serve

See Installation and Quickstart for a full walkthrough, or Configuration for every flag, environment variable, and default.

Where to go next

• Guides: connect an MCP host, use the CLI without one, set up a bucket, share a directory with humans, restrict agents with path policies, resolve conflicts.
• Concepts: how it works, the storage model, guarantees and limits.
• Reference: the CLI, the MCP tools, configuration, errors, S3 requirements, logging and profiling.