Skip to main content

Knos

A local MCP server that gives every coding agent on your machine one shared memory — and it knows which of them is in your code right now.

pip install knos && knos connect

Three MCP tools over stdio — search, about, remember. No HTTP server, no ports, no account, no model download, no repo to register, and no network connection at all: that last one is a test, not a promise.

knos connect adds Knos to Claude Code, Claude Desktop, Cursor and OpenCode — whichever you have, each in the shape it reads (mcpServers for the first three, mcp with "type": "local" for OpenCode). For Claude Code it runs claude mcp add --scope user, which registers the server with the session you are already in, so its tools work immediately with nothing to restart.

For the other three, knos connect writes the config and takes a backup, and then there is exactly one thing left to do:

Client What is left Why
Claude Code nothing claude mcp add --scope user registers with the running session
Cursor Restart Cursor. reads ~/.cursor/mcp.json at startup; no command registers a server with a running instance
Claude Desktop Restart Claude Desktop. same
OpenCode Restart OpenCode. opencode mcp add exists but is interactive, and its docs describe no reload for a running session
touches is copied to <name>.before-knos first.
Other ways in — Claude Desktop extension, Claude Code plugin, or by hand

Claude Desktop: download knos.mcpb from Releases and double-click it.

Claude Code plugin:

/plugin marketplace add drexthealpha/Knos
/plugin install knos@knos

By handknos connect --print shows the JSON, or add it yourself:

{ "mcpServers": { "knos": { "command": "python", "args": ["-m", "knos.mcp"] } } }

Every path runs the same python -m knos.mcp, so pip install knos comes first whichever you pick.

The first thing an agent asks about a repo reads it. Seven cold runs each, whole process, on a spinning disk: 1.7s median on a small project (1.5-2.1), 2.0s on goose (1.8-3.4), 3.1s on the Linux kernel (3.0-6.8) — 93,703 tracked files. That is not fast — it is one git log, your CLAUDE.md, and the transcripts of past sessions in that tree, written to SQLite. It happens once. Every question after it is under 0.2s, and every agent you have shares the result.

The one thing nothing else does

Claude Code is rewriting the risk guard. You ask Cursor about it.

Every other memory tool answers, and Cursor gives you a confident plan built on the version that was on disk five minutes ago. Knos does this instead:

Withheld. risk guard (held by Claude Code) is being worked on right now,
so knos is not the place you find out about it. Ask them, or work on
something else.

Not a warning attached to the answer — no answer. Your agent can still take it, by saying why, and the reason is written down under its name where you will read it. knos done releases it, and so does half an hour.

These are all good, and several are better at recall than Knos. Here is what each one's own README says, so you can check every cell:

To install MCP tools Needs Refuses to answer about work another agent claimed
CLAUDE.md + worktrees nothing no
agentmemory npx -y @agentmemory/agentmemory@latest 54 (8 in core mode) a server on ports 3111/3112/3113/49134 no — memory_lease locks an action an agent chooses to take
mcp-local-memory npx entry in your config 18 may download an embedding model no
Engram brew install + engram setup <agent> 16 nothing — one binary not addressed
MemPalace uv tool install mempalace + init + mine 45 ~300 MB embedding model no — separate wings per agent
Hindsight docker run … or pip 3 per bank Postgres + pgvector + an LLM API key no — banks are isolated by design
Knos pip install knos && knos connect 3 nothing yes

The last column is the difference, and it is narrower than it looks: agentmemory's leases are real coordination. A lease locks an action an agent decides to take. Knos changes what the memory says — ask about work someone else claimed and there is no answer to act on, and the claim is bound to the connection that made it, so an agent naming itself the holder is still refused.

Knos is not trying to out-remember these tools. It is trying to be the one that speaks up while two agents are in the same code, and to cost you two commands and four tools to find out.

One agent is enough to see it

knos claim "the parser"

Ask your agent about the parser. It is refused, and tells you so. knos done and it answers again. That is the whole mechanism, in two commands.

flowchart TD
    P["pip install knos<br>knos connect"] --> CC["Claude Code"]
    P --> CU["Cursor"]
    P --> CD["Claude Desktop"]
    P --> OC["OpenCode"]

    CC -->|"first question reads the repo"| S[("one SQLite file<br>no server, no model")]
    CU --> S
    CD --> S
    OC --> S

    R["CLAUDE.md, AGENTS.md, ADRs<br>commits, past sessions"] --> S
    W["every worktree of this repo"] --> S

    S -->|"answers, with the source"| CC
    S -->|"withheld - Claude Code is on it"| CU

    style S fill:#1f2933,stroke:#7b8794,color:#ffffff
    style P fill:#e8f0fe,stroke:#4a6fa5,color:#111111
    style R fill:#f5f5f5,stroke:#999999,color:#111111
    style W fill:#f5f5f5,stroke:#999999,color:#111111

Check any of it in under a minute

Nothing below is a claim. Each row is a command; run it and see.

What How to check it yourself
A claim changes what other agents are told knos claim "the parser" — it prints the exact refusal your agents now get. knos done gives it back.
One agent's claim reaches another agent's live session, with no restart or cache pytest tests/test_no_network.py -k live_session — one process claims, a second sees it on its next call
No network connection, ever pytest tests/test_no_network.py — breaks socket.connect, bind, create_connection, getaddrinfo, then reads a repo, answers, writes, claims, withholds, overrides. A third test breaks the guard on purpose, so it cannot pass by doing nothing
Decisions you keep in the repo are read pytest tests/test_rules.py -k decisions_kept_beside — an ADR answers with docs/adr/0001-use-sqlite.md:3
Every worktree of a repo is one memory pytest tests/test_worktrees.py
A big repo is never half-read pytest tests/test_worktrees.py -k runs_out_of_time — both readers, forced to time out, leave nothing behind
Secrets are invisible, not redacted pytest tests/test_private.py — the search layer is asked directly, with an agent's identity
What dies when you delete the store pytest tests/test_sibyl_is_load_bearing.py -k number_status_prints
Three MCP tools, no more pytest tests/test_recall.py -k three_tools_are_listed

Cost: pip install knos. No account, no key, no server, no model download.

Everything else, briefly

Every answer names where it came from — a commit, a session and a date, or a file and a line. Knos has no model: it does not summarise and it does not guess, it finds what somebody actually said.

$ knos ask "what are the rules here?"

Ask before adding a dependency. The build is the product.
    AGENTS.md:3
Every change ships with a test. A green run you did not watch is not green.
    CLAUDE.md:8
Source From
Your rules CLAUDE.md, AGENTS.md
Decisions you keep in the repo DECISIONS.md, WORKLOG.md, docs/adr/*.md, docs/decisions/*.md
Agent sessions Claude Code transcripts, Cursor's history
Commits git log
Code structure read by Knos itself, or universal-ctags when you have it
What you tell it knos remember

.env, *.pem, id_rsa, .ssh, .aws and twelve more are private the moment Knos reads a repo, without being asked. Private means invisible, not redacted: an agent asking about one is told nothing at all — no result, no count, no "2 hidden".

Worktrees. Keep them; they do a different job, and Knos treats every worktree of a repo as one memory anyway. Read the repo in one tree and every other tree can answer. Claim in one and the agents in the others are held off.

Commands. knos ask, knos claim, knos done, knos status. knos help lists the rest. Nothing runs itself: no watcher, no daemon, no schedule.

Why this is where the problem lives. A study of 557 agent sessions and 33,097 pull requests found that 60.5% of everything coding agents do with documentation happens in instruction files and their own notes — CLAUDE.md, AGENTS.md, plans, scratch notes — against 10.6% for classical docs and 1.3% for API references (Gao & Chen, 2026). Agents live in the files that drift, they rewrite those files themselves, and none of those files can say who is reading them or what another agent is changing right now.

What happens when you delete the memory

One SQLite file at ~/.knos/<repo>/memory.db, via Sibyl, capped at 5 MB per repo — Sibyl's free tier, and Knos runs it unactivated, so there is no account to make and no cap to raise. Sessions and commits are read newest first, so when a repo fills, what you have is the recent end of both and the older end was never read. Nothing already stored is evicted or truncated, and knos status says nearly full from 4 MB. The Linux kernel filled 0.3 MB.

Nothing leaves this machine — Knos makes no network request. Delete that file and:

Gone forever Why
What you told it (remember) yes it existed nowhere else
Every claim, and the withholding yes same
Who stood down for whom, every override yes same
Your commits, CLAUDE.md, past sessions no — re-read they are your files, not Knos's

knos status counts that first row for you, so you never take it on trust:

journal    330 things learned
             0 of them exist nowhere else - told, claimed, stood down
             delete the store and only those go; the rest is re-read from your repo

Ten seconds to prove it: claim something, watch an agent be refused, delete the file, ask again. Nothing was ever held.

More on the five tiers, why a claim expires, and how a hold is bound to a connection so an agent cannot borrow somebody else's name: docs/core-flow.md.

The two onchain parts, and exactly what they are

Both are optional. Knos works with neither, and nothing on the read or answer path touches a network — that is what pytest tests/test_no_network.py checks.

Base: sharing one folder with a teammate

knos share ./src --with alice.base.eth
knos unshare ./src --with alice.base.eth

What it does. Their agent can read that folder and nothing else. The record of who may read what is Access.sol on Base Sepolia, so neither machine has to trust the other's copy of the answer. Testnet, so it costs nothing.

What it does not do. It does not move your memory anywhere — the store stays on your disk. It does not encrypt anything. It is one permission bit per person per folder, not a sync protocol.

How to verify it. Two commands and one number each way:

python -c "from knos import team; o=team.identity('owner').address; m=team.identity('teammate').address; \
team.share('crates','teammate'); print(team.may_read(o,'crates',m)); \
team.unshare('crates','teammate'); print(team.may_read(o,'crates',m))"
# True
# False

Or read it without running anything: contract 0x955fa320…6E52, and one full cycle — deploy, grant, revoke. Nine contract tests: cd contracts && forge test.

Virtuals: selling one answer

What it does. Knos is registered on the Virtuals marketplace as a provider with one offering: another agent pays 0.01 USDC for an answer out of this machine's memory. The seller is agent/offering.ts.

What it does not do. No job has ever been traded through it. That needs a buyer, not more code. There is no evaluator and no reputation system. It is off by default and runs only when you start it.

How to verify it. The agent page is public — open app.virtuals.io/acp/agents/01a05b97… and you will see the registration without installing anything.

Tests

194 passing (pytest), 9 more for the contract (cd contracts && forge test).

Including the ones that would catch a lie:

  • test_no_network.py breaks socket.connect, bind and getaddrinfo, then reads a repo, answers questions, writes, claims, withholds and overrides. Nothing reaches for the network, and the guard itself is tested so the test cannot pass by doing nothing.
  • test_private.py asks the search layer directly, with an agent's identity, for a private path. Nothing comes back.
  • test_memory.py has a second process write a conflict, rejected by the schema rather than by Knos.
  • test_recall.py writes as one agent and recalls in a separate, fresh process.

What it cannot do

  • A claim withholds what Knos knows. It cannot stop an agent editing a file — nothing on your machine can, short of file permissions. If you need that, use a worktree.
  • Claude Code and Cursor only. No Gemini CLI or Codex history yet.
  • It does not write the answer for you, and it does not watch files. Run knos point again to catch up.
  • 5 MB per repo.
  • No job has been traded through the Virtuals provider.

Contributing

CONTRIBUTING.md has the three edits an agent adapter takes and the test to copy. pytest runs in about four minutes against throwaway stores. Deleting something is the most welcome kind of change.

Licence

MIT.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

knos-0.1.1.tar.gz (85.2 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

knos-0.1.1-py3-none-any.whl (67.3 kB view details)

Uploaded Python 3

File details

Details for the file knos-0.1.1.tar.gz.

File metadata

  • Download URL: knos-0.1.1.tar.gz
  • Upload date:
  • Size: 85.2 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/7.0.0 CPython/3.12.0

File hashes

Hashes for knos-0.1.1.tar.gz
Algorithm Hash digest
SHA256 aae0462f626ae18a1a33d349e908f1aab8b2ae11f30ac3a64c80ef84137ee34b
MD5 2b85cab9a8ed9bf8be18774ea100136b
BLAKE2b-256 759a12a3ef491706567f3731f6f8f684d024cdda1e61117b9d50432466869dc5

See more details on using hashes here.

File details

Details for the file knos-0.1.1-py3-none-any.whl.

File metadata

  • Download URL: knos-0.1.1-py3-none-any.whl
  • Upload date:
  • Size: 67.3 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/7.0.0 CPython/3.12.0

File hashes

Hashes for knos-0.1.1-py3-none-any.whl
Algorithm Hash digest
SHA256 42267fcfa1f70026b404177a52bea2e33ee0c69eeea9a2bb6560865b36545563
MD5 a595e7bda93d0e23babb90775fa8984d
BLAKE2b-256 61c62f9a3472cc5c3db132b6c573f9aa9dafabcdf8bb59e139228193438e93c5

See more details on using hashes here.

Release history Release notifications | RSS feed

0.1.8

2 files

0.1.7

2 files

0.1.6

2 files

0.1.5

2 files

0.1.4

2 files

0.1.3

2 files

0.1.2

2 files

This release

0.1.1 This release

2 files

0.1.0

2 files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page