OpenWiki
An open-source CLI that writes and maintains an agent-facing wiki for a codebase, then references it from CLAUDE.md / AGENTS.md so the coding agent reads the map before it edits. The pitch is a memory layer for coding agents — the docs stay current because a scheduled run regenerates them as the code changes. Runs fully local against Ollama (keyless), so the whole loop can cost $0. Evaluated, not yet adopted on the GL stack.
OpenWiki is LangChain's answer to a problem every multi-repo operator hits: the agent edits better when it understands the repo, but nobody wants to hand-maintain the map. It generates an agent-facing wiki, wires a pointer to it into CLAUDE.md / AGENTS.md, and keeps it current on a schedule. This page is the orient-and-decide surface — the GitHub repo owns the CLI contract.
What it is
A CLI (shipped July 2026) that writes and maintains documentation for the coding agent, not for humans. Three moves: it generates a wiki from the codebase, connects that wiki to the agent by adding a reference to CLAUDE.md / AGENTS.md (with a note on when the agent should consult it), and keeps it fresh by re-running as the code changes so the map doesn't rot.
The thesis is straight out of the "agents need a memory layer" conversation: an agent writes better code when it knows where key logic lives, how files connect, and which patterns the codebase expects. A stale README gives it none of that; a generated, continuously-refreshed wiki does. Ships with a GitHub Action so the regeneration can run on a schedule — daily, say — without anyone remembering to trigger it.
Provider-agnostic on the model side: OpenRouter, Fireworks, Baseten, OpenAI, Anthropic — and, since PR #87, Ollama, keyless against a local daemon at http://localhost:11434/v1. That last one is the detail that matters here: the entire generate-and-maintain loop can run on local open-weight models for $0.
When to use it
Reach for it when:
- You run many agent-driven repos and the per-repo
CLAUDE.mdcan't hold the whole map — you want an auto-maintained wiki underneath the hand-written instructions. - The agent keeps rediscovering the same structure every session (where the DB logic lives, how the modules connect) because that context isn't written down anywhere it reads.
- You want the docs to stay current for free — a local-Ollama run on a schedule regenerates the wiki with no API spend and no manual upkeep.
- You're standardizing on
CLAUDE.md/AGENTS.mdalready and want a generated companion layer rather than one more file to write by hand.
Skip it when:
- The repo is small and the hand-tuned
CLAUDE.mdis already sufficient — a generated wiki is overhead the agent doesn't need, and one more artifact to review. - Your instruction layer is carefully curated and load-bearing (behavior rules, routing, hard constraints). A generated wiki can overlap or quietly contradict it — see Risks.
- You can't give it a good enough local model — doc quality is model quality; a weak 3B model produces a wiki that misleads the agent more than no wiki at all.
- You need the freshness on infrastructure you don't run — its headline scheduler is a GitHub Action, which doesn't fit a GitHub-Actions-free, deploy-local shop without rewiring (see Gotchas).
At a glance
The loop
- Generate — point the CLI at a repo; it reads the tree and writes a wiki (structure, key logic, file relationships, conventions).
- Connect — it appends a reference to
CLAUDE.md/AGENTS.mdtelling the agent the wiki exists and when to read it. - Maintain — a scheduled run (GitHub Action out of the box) regenerates the wiki as the code moves, so the map tracks reality.
Model providers
| Provider | Notes |
|---|---|
| Ollama | Keyless local daemon (localhost:11434/v1). OLLAMA_BASE_URL overrides the endpoint; a real key is only needed when pointed at a remote host (e.g. Ollama Cloud). The $0 path. |
| OpenRouter | One key, many models — the cheap hosted path when a local model isn't strong enough. |
| OpenAI · Anthropic | Top-tier doc quality at per-token cost. |
| Fireworks · Baseten | Hosted open-weight inference — a middle ground between local and frontier. |
How you'd run it
The zero-spend default for a GL repo:
- Point it at a local model. Ollama is already the local-LLM substrate here (see Ollama). No new key —
OLLAMA_BASE_URLdefaults to the local daemon. - Run the CLI against one repo. It generates the wiki and adds the
CLAUDE.mdreference. Review the wiki like any generated artifact before trusting it. - Schedule the refresh off local infra, not a GitHub Action. The out-of-the-box scheduler assumes GitHub Actions; a deploy-local shop runs the same CLI on a
cron(or an existing loop runner) so the freshness doesn't depend on CI you don't use. - Gate what the agent reads. Keep the hand-written
CLAUDE.mdas the source of truth for rules and routing; let the generated wiki be the reference map the agent consults, not the place instructions live.
Where it could fit on the GL stack
Framed conditionally — this is watching, not adopted.
- builddaily.io — the natural pilot. Self-contained, a public build-in-public surface, and the one repo where "here's what happened when I ran it" is itself content. Low risk of colliding with a heavy private instruction system.
- Product surfaces (paiddaily.io, sagedaily.io) — mid-size app repos where an agent re-learning the web + api structure each session is real friction a maintained wiki would cut.
- Where it would not go first — the private operating-system repo whose
CLAUDE.md+ behavior rules are carefully curated and load-bearing. A generated wiki there risks contradicting hand-tuned doctrine; that's the last place to point it, not the first.
Gotchas
- The scheduler assumes GitHub Actions. The headline "runs daily via a GitHub Action" doesn't fit a GitHub-Actions-free, deploy-local posture. It's a CLI underneath, so run it on
cronor an existing loop runner instead — but the freshness is a wiring decision, not free. - Doc quality is model quality. A weak local model writes a confident-but-wrong map, which is worse than no map — the agent trusts it. Evaluate the generated wiki against a repo you know cold before pointing it at one you don't.
- Two sources of truth is a trap. If both the generated wiki and a hand-written
CLAUDE.mddescribe the same thing and drift apart, the agent gets conflicting context. Decide which layer owns what — rules inCLAUDE.md, map in the wiki — and keep them from overlapping. - Context windows. Local models default to short context; a large repo's generation step can silently truncate. Pin a model with enough context for the codebase size.
Risks
- Stale-but-trusted docs. The whole value is freshness; if the scheduled refresh silently stops (a failed cron, a moved key), the wiki rots while the agent keeps trusting it. Whatever runs the refresh needs to fail loud, not quiet.
- Single-vendor tool. It's open source, but it's LangChain's tool and tracks LangChain's model-provider abstractions. The generated wiki is plain docs and stays yours; the maintenance convenience is the dependency.
- Instruction-layer collision. The biggest risk for a curated setup: a generated wiki that quietly overrides or contradicts a load-bearing
CLAUDE.md. Mitigation is scope discipline — the wiki references, the hand-written layer rules.
