Calibrated abstention
When the evidence gates aren’t met, the context pack says so — with the reason — instead of dressing weak matches up as answers. Activation is gated on measured holdout performance, never vibes.
Local-first evidence for coding agents
Evidence before edits.
Open Kioku turns a repository into an evidence layer: exact answers in hundredths of a second, impact and tests picked by proof instead of name-matching, and a straight answer when the evidence isn’t there. Your agent plans from facts — never from confident guesses.
✓ Read-only by default✓ No hosted code index✓ MCP over local stdio
Measured on large repositories
Repository intelligence that survives contact with real code.
The 3.1.0 release lineage was validated end to end on a large Java repository — same protocol and same hardware as the previous public record, so the improvements are directly comparable.
Cold structural index
19m28s
13,607 indexed files, 247,499 symbols, 248,107 chunks, 402,844 graph nodes, and 1,522,135 relationship edges — a corpus 46% larger than the prior record. A repeat rebuild reproduced identical totals.
0.02s
exact class lookup, fresh process — down from 13.9s on the prior build
495,606
local semantic vectors · 0 failures
84,504
tests indexed and tiered by evidence
58
MCP tools with routing + safety metadata
Measured, not promised: timings come from one local workstation and vary with hardware, repository shape, Git history, and enabled evidence. Four concurrent graph reads completed without lock failures; optional compiler-grade SCIP evidence was unavailable for this build and remained explicitly reported as missing. Inspect the JSON evidence ↗ Read the method and caveats ↗
Built to be trusted
It tells you when it doesn’t know.
Most retrieval tools return something confident no matter what. Open Kioku treats certainty as a claim that has to be earned — and labels everything that hasn’t earned it.
Proof-tiered claims
A file that merely shares a name can never become a “proven dependency” or a “required test.” Structural claims carry typed proofs; heuristic candidates stay clearly labeled suggestions.
Atomic index generations
Every index builds into its own generation and publishes with one atomic switch. Kill it mid-build, lose power, downgrade — readers never see a half-built index.
Release-linked evidence
Don’t take the marketing copy on faith. Inspect the proof.
The evidence below identifies the exact build lineage, publishes aggregate results, and keeps caveats beside the claims they qualify. The newest record also publishes what got faster — and what still isn’t perfect.
Release-lineage evidence · v3.1.0
Open Kioku 3.1.0, tested at scale.
Validated end to end on a large Java workload — and honest about the result. The adjacent artifacts are the source of record.
3959fdf source16,537 tracked files0 semantic failures
Machine-readable evidence
Auditable without exposing the repository.
The JSON records build source, host profile, configuration, workload totals, measurements, quality checks, and limitations — including what still isn’t perfect. Repository identity is withheld, so exact replay is not claimed.
247,499 symbols1,522,135 edges4 parallel readers
Inspect JSON evidence ↗Method + limitations
Quality means preserving uncertainty.
The repeated structural run reproduced identical totals, the exact class lookup returned the correct class in 0.02s, and missing compiler-grade SCIP evidence stayed visible instead of being treated as present.
0 lock failures0 failed vectors
Read methodology ↗Evidence boundary: these are single-workstation observations, not latency guarantees. Publishing an anonymous workload protects the test target but prevents exact source-level reproduction.
One evidence pipeline
From repository facts to the smallest useful context.
Open Kioku combines deterministic code intelligence with explainable retrieval signals. Exact repository facts do not get demoted by a fuzzy match.
Indexsymbols, chunks, tests, graph
Retrievelexical + local semantic context
Provereferences, history, runtime, coverage
Planfiles, boundaries, validation
Verifychanged files against the plan
exact symbolsreferencesBM25local semanticimpact graphtestsgit historyruntimecoveragearchitecturecontracts
Facts outrank guesses
Definitions, references, paths, and exact evidence stay authoritative. Heuristics can help retrieval without rewriting repository truth.
Context with a purpose
Ranked snippets, exact line ranges, impact, nearby tests, and caveats give the next agent step a bounded evidence set.
Scales locally
Optional semantic retrieval stays on-device and can use persistent approximate nearest-neighbor search while exact-flat remains the correctness oracle.
History is evidence
Co-change, churn, ownership, reviewer, provenance, renames, and similar-change signals are derived from bounded local Git history.
Tests before edits
Validation candidates are selected from indexed tests and repository evidence before a change begins, not as an afterthought.
Verification closes the loop
Plans define edit boundaries. Verification compares the actual changed files with those boundaries and reports evidence caveats.
Interactive product tour
A coding workflow with memory of what matters.
Click through the same sequence an agent can use before, during, and after a repository change.
ok plan
Local by design
Your repository is the source of truth — and it stays yours.
The default workflow is designed for local repository intelligence rather than a hosted code-index service.
◈
No hosted indexCore search and evidence are stored under the repository’s local .ok/ data.
⌁
Read-only by defaultThe MCP server provides evidence tools; source edits remain in the normal editor and agent workflow.
⊘
Network-denial postureDefault MCP security configuration includes network denial; local semantic search does not require a hosted embeddings API.
✓
Share proof, not sourceok prove reports index and validation signals while intentionally omitting source snippets.
Evidence stays honest: runtime traces and coverage reports are optional local inputs; when evidence is missing, Open Kioku reports the caveat instead of pretending certainty.
Start with your own repository
Give your coding agent evidence before the next edit.
Install locally, build the repository index, then generate a plan from the task you actually care about.
$ npm install -g open-kioku
If Open Kioku improves your agent workflow, consider starring the repository ↗.