Build Daily

Tinley Park · July 14, 2026
toolLangChainwatching

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.

Updated July 14, 2026

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.md can'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.md already 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.md is 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

  1. Generate — point the CLI at a repo; it reads the tree and writes a wiki (structure, key logic, file relationships, conventions).
  2. Connect — it appends a reference to CLAUDE.md / AGENTS.md telling the agent the wiki exists and when to read it.
  3. 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:

  1. Point it at a local model. Ollama is already the local-LLM substrate here (see Ollama). No new key — OLLAMA_BASE_URL defaults to the local daemon.
  2. Run the CLI against one repo. It generates the wiki and adds the CLAUDE.md reference. Review the wiki like any generated artifact before trusting it.
  3. 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.
  4. Gate what the agent reads. Keep the hand-written CLAUDE.md as 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 cron or 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.md describe the same thing and drift apart, the agent gets conflicting context. Decide which layer owns what — rules in CLAUDE.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.

Related

  • Ollama — the local-LLM substrate that lets OpenWiki generate and maintain the wiki for $0.
  • DSPy — the other half of the "agents need structure, not vibes" thesis: compiled modules for the brain layer, a maintained map for the code layer.