scribe
scribe is a single-binary Go command-line tool that mines your git repositories, coding-agent sessions and self-sent links, then compiles them into a private markdown wiki in git that Claude Code, Codex and Amp read before they act.
What is scribe?
scribe is a compiled knowledge base written by a language model instead of by hand: a single Go binary that watches the work a developer already does and turns it into a private markdown wiki. Four streams feed it — git repositories, coding-agent transcripts read through the ccrider FTS5 index plus direct Codex rollouts, links texted to yourself over iMessage on macOS, and drop files an agent leaves inside any project. Discovery is automatic: one walk over the Claude Code and Codex session directories enrols every repository you have opened, each with a stable name, a last-seen timestamp and its provenance.
The pipeline has three stages. Capture collects the four streams on a schedule. Triage scores each session candidate with weighted SQLite FTS5 keyword matching and rejects boilerplate before any model runs, so worthless sessions cost nothing; one published run filtered 142 sessions down to 18. Extraction then applies a two-pass absorb: the first pass grounds atomic facts, the second fans dense sources out into entity-first wiki pages. The compile stage generates wikilinks, a backlinks index and retrieval-context paragraphs spliced into every article, then reindexes the corpus with qmd.
The output is deliberately ordinary. Articles are typed markdown — decisions, patterns, learnings, tools, research, projects — carrying YAML frontmatter and wikilink edges. Those edges follow a closed ten-kind schema (supersedes, contradicts, derived_from, specializes, extends and five more), so an agent can follow why a choice was made rather than keyword-match it. Search runs on qmd, which combines BM25 and vector recall and is reachable from any terminal or from inside Claude Code and Codex through MCP; plain grep still works, because the corpus is files.
Everything runs unattended on macOS LaunchAgents or Linux cron: hourly commits, project extraction every two hours, session mining three times a day, and a weekly Dream consolidation that prunes stubs, merges near-duplicates and surfaces contradictions. Inference is routed per operation to a local Ollama server, a hosted OpenAI-compatible endpoint, or Anthropic through the claude CLI. On the local path a full weekly sync was measured at zero dollars in about 68 seconds. The tool is free, MIT-licensed, and runs on macOS and Linux.
What it does
- Mine git history, coding-agent transcripts, self-sent links and drop files into one knowledge base
- Write typed markdown articles with YAML frontmatter and wikilink edges, without anyone typing them
- Reject boilerplate sessions with SQLite FTS5 keyword scoring before any model is called
- Wire a handshake into CLAUDE.md and AGENTS.md so agents query the base before they decide
- Run the whole pipeline unattended on macOS LaunchAgents or Linux cron
- Route every inference operation to local Ollama, a hosted endpoint or Anthropic, per operation
- Report spend per model, per provider and per knowledge base, and cap it with a daily token ceiling
When to use scribe / When not to
A quick filter to help you decide if scribe is the right fit.
When to use scribe
- Developers who live inside coding agents such as Claude Code, Codex or Amp and keep losing context between sessions
- Engineers working across many repositories, who solve the same problem twice in different projects
- Local-first practitioners who want the entire pipeline on their own Ollama server with no API spend
- Small engineering teams willing to share one git-backed knowledge base, with a secret-scan gate and per-remote approval
- Command-line people already comfortable with git, YAML and cron, who prefer plain files to a hosted product
When not to use scribe
- Non-technical users: there is no graphical interface, no account and no web app, only a terminal
- Anyone who wants to upload a PDF and chat with it; the site itself points those readers to AnythingLLM
- People who want to write and shape their own notes by hand; the site points them to Obsidian
- Teams that need request-time control over retrieval, for whom the site recommends a purpose-built RAG pipeline
- Machines with less than 16 GB of RAM whose owners refuse a hosted endpoint: the local model path will not fit
How to use scribe
A typical end-to-end flow, from setup to results.
- Install the binary with Homebrew: brew tap oliver-kriska/scribe, then brew install oliver-kriska/scribe/scribe
- Install the remaining runtime dependencies the formula does not pull: qmd via npm, the Claude CLI, and Ollama for the local path
- Bootstrap a knowledge base with scribe init --path ~/my-kb --bind, which also writes the agent handshake into CLAUDE.md and AGENTS.md
- Add the operational agent skills inside the base with scribe skill install
- Enrol candidate repositories with scribe sync --discover
- Approve only the repositories this base may read, using scribe projects review
- Preview the pending work and its token cost with scribe sync --dry-run --estimate, before any model is called
- Choose the inference path by editing the llm block in scribe.yaml: ollama, a hosted OpenAI-compatible provider, or anthropic
- Put the pipeline on a schedule with scribe cron install, then verify the whole setup with scribe doctor
- Query the base day to day with qmd query, qmd search, or the qmd MCP tool from inside a coding agent
Pros & Cons
Pros
- Inference can cost nothing: the entire pipeline runs against a local Ollama server, with a published zero-dollar weekly sync
- No lock-in whatsoever: plain markdown in a git repository you own, readable in Obsidian, VS Code, vim or mdbook
- Auditable like code: provenance in frontmatter, raw sources kept verbatim beside each page, and a wrong article deleted with git rm
- Genuinely cross-project memory rather than a silo per repository
- Explicit spending guardrails: dry-run estimates, a daily output-token ceiling, and per-provider cost reconciliation
- Mechanisms against decay instead of promises: contradiction and staleness ledgers, structural lint, weekly consolidation
- Unusually precise and self-critical documentation, including dated comparisons and real billing receipts
Cons
- Developers only: a terminal, git, YAML and cron are mandatory, and there is no graphical interface at any point
- A heavy dependency chain — claude, ccrider, qmd, sqlite3 and git are all required, plus Ollama for local inference
- The dependency check still expects the Claude CLI even on the fully local Ollama profile
- Real hardware demands: the recommended local model pair assumes 32 GB of RAM, and below 16 GB the site advises a hosted endpoint instead
- The Anthropic path can be expensive: 103.57 USD over a single published week, most of it on one team knowledge base
- No legal pages at all, no contact address, and no channel outside GitHub issues
- A single-maintainer project at version 0.5.1, with several multi-machine maintenance jobs left uncoordinated by design
Pricing & Plans
The software is free of charge. scribe is open source under the MIT licence, with no paid plan, no account and no pricing page, and the site's structured data declares a price of 0 USD. The only expense is inference, and it is entirely under the user's control: the local Ollama path costs nothing, a hosted OpenAI-compatible endpoint billed 0.55 USD over a published seven-day run, and the Anthropic path billed 103.57 USD over the same week.
- Free and open source under the MIT licence — the only edition of the tool
- Ollama
- no API key required
- zero spend for the whole pipeline
- any OpenAI-compatible endpoint such as Together
- Groq
- Fireworks or Hugging Face
- billed by that provider
- the default
- routed through the user's own claude CLI sign-in
- switched on with team: true in scribe.yaml
- at no additional cost
- a paid edition still being validated through an interest form
- with no price published
Data, GDPR & hosting
A consolidated view of how scribe handles your data.
GDPR overview
There is no GDPR information at all. getscribe.dev publishes ten pages in total and none of them is a privacy policy, a set of terms, a data processing agreement, a subprocessor list or a legal notice; searching every collected page for the word GDPR returns nothing, and the site exposes neither a contact email nor a postal address. No Article 27 EU representative is named. The absence is not neutral, but it is structurally coherent: scribe is a locally installed command-line tool with no account, no vendor server and no described telemetry, so the controller of any personal data is the user. Anyone routing inference to a hosted provider becomes responsible for that transfer themselves, and the project states plainly that such a provider sees the knowledge base content on every call.
Who owns the data?
scribe publishes no terms of service and no privacy policy, and its architecture explains why: there is no vendor service to receive data. The knowledge base is a plain git repository of markdown files created on your own machine, at a path you choose, and you push it — if you push it at all — to a private remote you own on GitHub, Gitea or Forgejo. The maintainer states the design goal as file over app: the corpus has to outlive the pipeline. Hosted-provider API keys live in a per-machine user configuration file, never inside the knowledge base. In team mode, the shared base is the team's own repository, owned by the team.
Reuse rights
Because the knowledge base is your own git repository of markdown files, you may read, edit, republish or delete anything in it without asking anyone: removing an article is a git rm, not a support request. The tool itself is MIT-licensed, so it can be used, modified and redistributed freely, and the corpus opens in Obsidian, VS Code, vim or mdbook without conversion. What the site never does is define reuse contractually — there are no terms of service, so no document states what a publisher may do with your content, which is consistent with a tool that never receives it. The one case where content leaves the machine is an explicitly configured hosted provider, which the project warns sees the knowledge base content on every call.
Data retention & training
Hosting summary
There is no vendor hosting to describe. The knowledge base is a git repository of markdown files on the user's own machine, at a path chosen at initialisation, and any backup goes to a private remote the user selects — GitHub, Gitea, Forgejo or anything else that speaks git. No hosting country or region is declared on the site, and none could be: the jurisdiction is wherever the user's machine and remote happen to be. On the fully local Ollama path, no data leaves the machine at all; on the Anthropic or hosted paths, content is sent to that provider on each call, under the provider's own terms rather than scribe's. The marketing site itself is served from Cloudflare, whose anycast network resolved to a United States node at the time of review, but that concerns the website only and has no bearing on where a knowledge base lives.
Things to keep in mind
Risks and trade-offs to weigh before adopting scribe.
- A hosted inference provider sees the knowledge base content on every call, so an offhand config change can send your engineering decisions to a third party
- Session transcripts routinely carry API keys and tokens; outside team mode the secret-scan commit gate is off, so a private remote is the only protection
- Set the daily output-token ceiling before pointing the pipeline at a paid provider: an unattended loop on a metered backend can run up a real bill
- The base is written by a model, so a confidently wrong article can be read back by your agents as fact; the contradiction and staleness ledgers help but do not decide for you
- Outsourcing memory to a machine erodes the habit of holding context yourself, and an agent citing a stale decision is harder to catch than one that admits it does not know
- Mining coding-agent sessions can absorb a client repository or an NDA-covered discussion by accident unless allowed_remotes and source approvals are set carefully
- On a second machine, forgetting team: true fails silently: two laptops rewrite the same wiki, and the shared project manifest is overwritten on every discovery run
Setup & Integrations
Technical difficulty
Demanding. Installation is one Homebrew command, but getting to a running pipeline is a multi-step runbook: dependencies (git, sqlite3, ccrider, qmd, the Claude CLI, and Ollama for local inference), YAML configuration across up to three files, source approval, cron installation — automatic on macOS, manual crontab lines on Linux — and Full Disk Access for iMessage capture. The local path also assumes serious memory, around 32 GB for the recommended models. Two things soften it: the runbook is written to be handed to a coding agent that performs the setup, and scribe doctor reports exactly what is missing.
Deployment
Integrations
Behind scribe
Social
Resources
All the official URLs gathered for verification and reference.
Alternatives
Tools that compete with or complement scribe.
Frequently asked questions
Does scribe require an Anthropic API key?
What does it cost to run?
What else has to be installed?
Where is the knowledge base stored?
How do I know that what it writes is true?
Does it work on Linux?
Can a team share one knowledge base safely?
Is this the same product as Scribe by Scribehow?
How is it different from RAG or from Obsidian?
What does the cron schedule look like?
Should you pick scribe?
scribe occupies a narrow and clearly stated niche: durable memory for developers who already spend their day inside coding agents. Its bet is that compiling knowledge on a schedule beats retrieving chunks at query time, and the consequences of that bet are visible everywhere in the design — a curated wiki instead of a vector store, plain markdown in git instead of a hosted service, a keyword pre-filter so that worthless sessions never reach a model. For the right reader this is unusually good value: the software is free under the MIT licence, the whole pipeline can run on a local Ollama server for nothing, and nothing about the output is locked away, since it is a folder of files you can grep, diff and delete. The documentation deserves particular credit. Comparisons are dated, cost figures come from the maintainer's own billing rather than from marketing, and the setup runbook names the traps it knows about. The reservations are just as clear. This is a terminal tool with a long dependency chain, and the local path is genuinely demanding on memory: the recommended model pair assumes 32 GB of RAM. It is maintained by one person, published at version 0.5.1, and the site carries no terms, no privacy policy, no postal address and no contact email — GitHub issues are the only visible channel, which is worth weighing before a team commits its shared engineering knowledge to it. Anyone who wants a graphical second brain, a document-chat workspace, or a product with a support contract should look elsewhere; the site itself says as much and names the alternatives. Anyone who wants their own tools to write their notes, locally and for free, will find few things this deliberate.
- Choosing a selection results in a full page refresh.
- Opens in a new window.