code intelligence for AI coding agents

Your code already has structure. Use it.

Hayvenhurst keeps an always-fresh, private structural index of your codebase — a graph of functions, classes, calls, and imports. 0.65 s for a 362-file repo, 5½ minutes for 94,000-file Kibana, linear all the way, on a laptop. No embedding model, no GPU, no vector database, and nothing ever leaves your machine.

MIT license open source 5 languages 0 runtime deps
hayven — zsh
$ hayven init parsed 362 files → 2,185 entities, 7,250 edges ✓ indexed in 0.65s # no model. no embeddings. no network.   $ git checkout feature/auth && hayven ingest ✓ branch diff re-parsed in 48ms # revisit a seen branch: 1ms, cached   $ hayven affected-tests session/validate SAFE tier → 14 of 412 tests could break

measured, not marketed

Every number comes from a committed benchmark.

The comparison below runs against an embedding-based indexer on real open-source repos. Reproduce it yourself in 60 seconds — the harness ships in the repo.

hayvenhurst embedding-based indexer
Cold index (hono, 362 files) 0.65 s 35.6 s — embeds 3,543 chunks
Cold index (gin, Go) 0.23 s
Cold index (django, 2,967 files) 10.6 s 260 s on fastapi, at ⅓ the file count
Cold index (kibana, 93,923 files) 5.4 min · 3.8 GB RAM — linear
Query latency at 334k entities 0.27 s
Branch switch (re-parse only the diff) ~48 ms re-syncs + re-embeds every switch
Revisit a previously-seen branch 1 ms — cached 0.41 s
Retrieval coverage, novel symptom queries 3 / 3 0 / 3
Dependencies to run none — one Rust binary + SQLite model + torch + vector store

The asymmetry is architectural, not a tuning gap: an embedding indexer must re-embed; we parse and cache per branch, and never embed at all. Every harness ships in the repo under bench/.

see it

Your codebase, as a living graph.

This is the viewer the daemon serves at localhost:7777hono, indexed in 0.65 s: 2,185 entities joined by 7,250 call and import edges, laid out by a local force simulation. SVG-only, under 100 KB of JavaScript, no server compute.

hayven view — honojs/hono
The Hayvenhurst viewer rendering hono's code graph: 2,185 entities connected by 7,250 call and import edges, drawn as a glowing force-directed constellation

what it does

A code graph your agents can actually use.

Grep finds text. Hayvenhurst answers structural questions — what calls this, what breaks if it changes, which tests can catch it — and stays current on every branch, automatically.

affected-tests

Run only the tests that can break.

hayven affected-tests fuses the static call graph with runtime traces — what your code actually does when it runs — to select the tests a change can reach, on Python (pytest) and TypeScript (vitest, bun test). Static analysis alone missed the dispatch-reached tests entirely; the trace-augmented map caught every one.

SAFE tier: 0 missed regressions across ~95 replayed real bugs on 4 repos · trace recall 1.00 vs static ≈ 0
context

Precise slices, not whole files.

hayven context <symbol> returns the minimal graph slice an agent needs — the entity, its real dependencies, line-exact. A drop-in proxy applies the same trick to any Anthropic / OpenAI / Gemini traffic, automatically.

live-measured 78.8% fewer input tokens over a 24-turn agent loop, zero task failures
coordination

Parallel agents, no collisions.

An entity-scoped claim board lets a fleet of agents edit the same repo safely — two agents can work different functions in one file, and work that would break another agent's assumptions is flagged before it happens.

realized conflict rate 2.4% vs ~22% naive · truly-independent work never blocked
always-fresh

Never goes stale. Never phones home.

A native file watcher re-parses only what changed; every branch keeps its own cached index. Peers sync without a server via CRDTs — a representative day of sync measured at ~5.6 KB on the wire. Your code never leaves the box.

watcher idle CPU ≤ 0.0081% on 30K files · daemon RSS ~43 MB

under the hood

One Rust binary, one SQLite file, plain markdown.

The graph's source of truth is human-readable markdown in .hayven/; SQLite is a rebuildable index on top. It runs on a $599 Mac mini — or a Raspberry Pi. And it meets your code where it is: this month's TypeScript monorepo or a decade-old require() codebase get the same graph.

            ┌─────────────────────────────────────────────┐
            │                hayvend (Bun)                 │
   agents   │  CLI · HTTP API · CRDT state · claim board   │
  ───────►  │  SQLite index (FTS5) · .hayven/ markdown SoT │ ◄── peers
   query    └───────┬──────────────────┬───────────────┬───┘     (sync)
                    │                  │               │
            hayven-native (Rust)   graph viewer    trace collectors
            parse · watch · infer  localhost:7777   runtime call edges
py python ts typescript js javascript · esm + commonjs rs rust go go + pnpm / yarn monorepos

philosophy

Five principles, in priority order.

When they conflict, the earlier one wins.

Egalitarian by hardware tier

Useful on a Raspberry Pi and on a 4090. Nobody is locked out.

Data-efficiency first

Every byte on the wire must justify itself. Dial-up before fiber.

Local-first, cloud-optional

Your machine is the primary execution environment.

Original where it matters, boring where it doesn't

Custom CRDT serializer; off-the-shelf SQLite.

Distributable, not centralized

Every daemon is potentially a peer.

quickstart

Sixty seconds to a queryable graph.

Pre-release (0.x) — build from source with Bun and a Rust toolchain. Signed release tarballs land with v1.0.

install & run
$ git clone github.com/Davidb3l/hayvenhurst && cd hayvenhurst $ bun install && ( cd native && cargo build --release )   # in your project: $ hayven init # build the index $ hayven query "session validation" $ hayven daemon start # API + graph viewer on :7777