openwiki + context-mode — pass on local adoption, integrate through OmniRoute only
openwiki + context-mode — pass on local adoption, integrate through OmniRoute only
Decisions (2026-07-04 grill)
| Project | Local adopt? | OmniRoute upstream? | New own-repo? |
|---|---|---|---|
| langchain-ai/openwiki (MIT, 2.2k stars) | No | Yes (issue #6183) | No |
| mksglu/context-mode (ELv2, 18.6k stars, HN #1) | No | Yes (issue #6184) | No |
Also filed upstream on context-mode: relicense-to-MIT/Apache ask (mksglu/context-mode#917).
Why pass on local adoption
openwiki overlaps ~90% with our knowledge/ OKF bundle.
- openwiki generates markdown docs from git-diff + LLM inference; updates AGENTS.md pointer via a daily GHA
- We hand-curate
knowledge/(800+ files, OKF format, decision-first) and update via SOFA workflow +self-update-rule - Both point AGENTS.md at their respective doc surface
- Our approach preserves decision provenance; openwiki'ssurface would drift from human judgment
context-mode overlaps ~90% with RTK + cavemem + fleet memory.
- context-mode: tool-output sandboxing → RTK (48% savings verified, corp-safe)
- context-mode: session memory persistence → cavemem hooks +
chirag127/claude-memoryrepo - context-mode: 17-platform MCP routing → our 3-agent fleet (CC + OpenCode + Kilo) with per-agent
.mcp.json - context-mode: ELv2 license = redistribution risk per
community-packages-firstpreference for OSI-approved
Why the OmniRoute upstream asks
OmniRoute already ships a setup-* command family (setup-cursor, setup-codex, setup-claude-code, etc — docs/guides/CLI-INTEGRATIONS.md). Both openwiki and context-mode are CLI tools that need a model-provider endpoint — OmniRoute owns that. Wrapping their init flow in omniroute setup-openwiki / omniroute setup-context-mode costs OmniRoute ~50 LOC per integration and gives users OmniRoute's combo/fallback/retry semantics for free when they run these tools.
Why no new own-repo
Per no-rebuilding-free-software + dont-recreate-what-exists-freely: neither problem is unsolved by our existing stack. Building an oriz-okf-wiki adapter or oriz-context-guard variant would be NIH duplication.
Re-evaluation trigger
Re-open this decision when:
- openwiki — OKF format lands upstream (i.e.
openwiki --format=okf-v0.2becomes an option); at that point we'd adopt forrepos/frk/*to auto-generate navigation for massive forks (omniroute has 1823 npm packages / 152 providers — hand-mapping is impractical) - context-mode — mksglu relicenses to MIT/Apache (issue #917 or downstream fork) AND RTK stops covering a meaningful class of tool-output we care about
Session artifacts
- Filed: mksglu/context-mode#917 — relicense ask
- Filed: diegosouzapw/OmniRoute#6183 — setup-openwiki
- Filed: diegosouzapw/OmniRoute#6184 — setup-context-mode
Cross-refs
community-packages-firstno-rebuilding-free-softwaredont-recreate-what-exists-freelyagent-configs-workspace-canonical-2026-07-03— our own approach to config-as-code