awgraph — the code graph your agent reads instead of grepping

Docs · Source · pip install awgraph · The Aither World

The Aither World is an operating system for agents — a Linux you can hand to one, the runtimes it works in, and the tools it works with. awnix is the Linux underneath it; awgraph is one of its 33 bricks — each installs on its own, runs offline, and needs no account.

Start here: Index one repo and ask it who calls one function.

An agent asked to fix a bug does not know which files matter, so it greps, opens whatever matched, and spends most of its context window on code it will not change. awgraph indexes the repository into a graph of symbols — functions, methods, classes, their calls and callers — and answers a natural-language task with the handful of chunks that task actually needs.

pip install awgraph

Python 3.10+. Nothing else is required to index and query.

What it costs, measured

The interesting question is not "is a graph better than grep" — it is what does each cost to reach the same answer. The task is a real commit message with the answer filenames stripped out; the truth is the set of files that commit actually modified. k is the result budget, and it is swept for both retrievers, because k bounds grep's output too — sweeping it for only one arm manufactures a win.

Measured on two corpora, because the answer depends on how big your repo is. That is the first question anyone asks about a graph retriever, and it deserves a number instead of an intuition:

Both are subtrees of one Python monorepo, and both retrievers are confined to the same subtree, so they search the same universe. Neither ever sees the truth set while retrieving.

Small corpus — 76,527 lines

awgraph reaches the same ceiling as exhaustive grep — recall 1.000 — for 16x less context. But grep is the better finder at this size: it hits 1.000 at k=50 while awgraph is still at 0.939.

Large corpus — 1,233,731 lines

The ranking flips with scale. At 76k lines grep wins recall at every matched budget. At 1.2M lines awgraph wins it outright at k=10 and k=25 — the budgets that fit in a context window — while costing 245-296x less. So the honest answer to "does this only pay off on a big codebase?" is: it pays off on both, but for different reasons. On a small repo it buys you the same answer for far less. On a large one it buys you a better answer at any budget you can actually spend.

Read the rest honestly, because the shape matters more than the headline:

• grep still wins at large k, and cannot be used there. Its 0.950 at k=400 costs 4,835,491 tokens per task. Nothing accepts that in one window, so it is a recall you cannot spend. awgraph's 0.887 costs 54,560.
• awgraph did NOT reach grep's ceiling on the large corpus. On the small one it closed to 1.000 at k=400; here it tops out at 0.887 against grep's 0.950. A sweep that fails to close the gap is a result, not a run to discard.
• The two costs diverge, and that is why scale flips it. Going from the small corpus to the large one, grep's k=400 bill grows 6.6x (735,727 → 4,835,491) while awgraph's grows 1.2x (45,269 → 54,560). grep pays for the repository; awgraph pays for the budget you set.
• awgraph's token count is for previews, not whole function bodies — signature + docstring + a body preview per chunk. An agent that then reads the full body of its top hits pays more than the number above. grep's figure is whole files, which is what an agent actually has to read. The comparison is fair at the retrieval step and generous to awgraph after it.

Do you actually need the embeddings? Ablated on the small corpus — same 33 tasks, same index, semantic half off:

So yes at small k, and less so as the budget grows — which is the regime that matters, since the whole point is a small k. Embedding on CPU is the slow part of setup, and this is what it buys.

Caveats, because a benchmark without them is marketing: n=33 and n=40, one repository, Python only, and k is a knob a caller chooses rather than something the tool tunes for itself. Two more worth stating plainly:

• This measures retrieval, not resolution. No patch was written and no test was run. Files-retrieved and tasks-fixed are different axes.
• The graph arm is not perfectly deterministic, and the spread is ±0.025. In a single run on the large corpus, the same k=10 query set scored 0.608 in the headline pass and 0.633 in the sweep — same code, same tasks, same process, because the semantic arm times out on some queries under load. Anything smaller than 0.025 here is noise, including differences we would rather were real.

Two things measured and not confirmed, recorded because a benchmark that only reports its wins is an advertisement:

• Embedding coverage was not the gap. Going from 33.3% of chunks carrying vectors to 100% moved recall@10 from 0.800 to 0.803. The earlier claim that partial coverage understated the result is refuted.

• A naive fusion did not work. Run the graph, fall back to grep when it returns few files: 0.894 recall at 348,389 tokens — worse recall than grep AND nearly grep's full cost, because the fallback fires on almost every task and pays both bills. A trigger keyed on result count cannot help; it fires when the graph is confidently wrong and stays quiet when the graph is confidently right. It behaves the same way at 1.2M lines: +0.050 recall over the graph alone for 216x the tokens.

  The cost model was the flaw, and fixing it is measured. Treating grep's output as a RESULT SET commits the agent to reading whole files. Used instead as SEEDS — git grep -il returns paths, and the previews for those files come from the index — the same fallback costs 16,444 tokens instead of 387,865, a 23.6x cut, at 0.633 recall against the naive version's 0.658. So seeding is the right way to pay for a fallback and it did not buy recall over the graph alone (0.633 either way). Score-keyed triggering remains untested.

Setup: index once, embed lazily

Two costs, and only one of them scales with repo size.

Indexing is close to size-insensitive — 27x the files for 1.5x the time in the first two columns, because parsing runs across workers. The third column is a different, faster machine embedding against a GPU inference server rather than CPU sentence-transformers, which is the whole difference between 97 minutes and three: the embedding step is the one worth throwing hardware at. It is also optional, cached and incremental — re-indexing reuses stored vectors and only embeds what changed.

Without any embedding backend, queries fall back to keyword scoring and still work. That fallback is silent by design and dangerous by nature — a graph with no vectors looks like a working graph that is merely worse. Check coverage rather than assuming it:

embedded = sum(1 for c in graph.chunks.values() if c.embedding is not None)
print(f"{embedded}/{len(graph.chunks)} chunks carry vectors")

Use it from the terminal

pip install awgraph

awgraph index .                          # parse + persist an index for this repo
awgraph query "retry with exponential backoff"
awgraph callers send_request             # who calls this
awgraph calls send_request               # what does this call
awgraph stats                            # what is in the index
awgraph selftest                         # prove the install works

query prints path:line [type] name and the signature, so results paste straight into an editor. --json on any read command gives machine-readable output for wiring into a tool loop.

Exit codes are meaningful: 0 success, 1 a real negative answer (no match), 2 the command could not run at all — so a script can tell "nothing matched" from "there is no index yet", which are different problems with different fixes.

The index is cached outside your repository — under AWGRAPH_CACHE_DIR if set, otherwise the platform user-cache directory, keyed by a digest of the absolute repo path. Nothing is written into the tree you point it at.

awgraph stats always prints embedding coverage, including 0.0%. Without an embedding backend hybrid_query silently falls back to keyword scoring and still returns ten confident-looking results, so "is the semantic half actually on?" is a question you should never have to answer by reading the source.

Use it from a coding agent (MCP)

pip install "awgraph[mcp]"

then one line in your client's MCP config — Claude Code, Cursor, Windsurf, Zed:

{"mcpServers": {"awgraph": {"command": "awgraph", "args": ["mcp"]}}}

Your agent gains code_index, code_search, code_callers, code_calls and code_stats. It searches by meaning and gets back symbols with file, line, signature, calls and callers — rather than pasting file text into its own context, which is the cost this package exists to remove.

Index once per repository (code_index); it is cached on disk outside the repo. Indexing is never implicit: a search against an unindexed repo tells the agent to index rather than pausing for minutes, because a long silent call reads as a hang and usually gets killed.

Use it from Python

import asyncio
from awgraph import CodeGraph

async def main():
    graph = CodeGraph(root_path="/abs/path/to/repo", auto_index=False)
    await graph.index_codebase("/abs/path/to/repo")   # absolute path required

    for chunk in await graph.hybrid_query("retry with exponential backoff", max_results=5):
        print(chunk.name, chunk.source_path, chunk.start_line)

asyncio.run(main())

index_codebase needs an absolute path. Given a relative one it walks nothing, indexes zero chunks, and returns successfully — so assert on len(graph.chunks) rather than on the absence of an exception.

The query does not need to contain the symbol name. Asking for "backoff policy for flaky calls" against a class documented as "Backoff policy for flaky calls" returns it by meaning, not by string match.

Where it sits

Three packages, three different questions about the same repository:

• awgit — semantic version control. Stable node ids, semantic edit-ops, leases so concurrent agents do not overwrite each other, stacked commits with one PR each. It knows what changed and who is editing it.
• awgraph — code intelligence. Symbols, call paths, dependencies, blast radius. It knows what the code is and what depends on what.
• awdk — the agent runtime that consumes both.

The seam is the useful part: awgit tells you a commit touched RetryPolicy.next_delay; awgraph tells you what calls it and which tests cover it; the agent reads that instead of the repository.

Related work

GitNexus is the closest analogue and worth reading. Its recommended mode augments grep with graph context rather than replacing grep — a conclusion these measurements independently reach. Note its licence is PolyForm Noncommercial (source-available, commercial use forbidden), where awgraph is Apache 2.0. Its published figures measure SWE-bench task resolution; the numbers above measure retrieval recall. Those are different axes and should not be compared directly.

Licence

Apache 2.0.

The aw family

Standalone tools that share one idea: replace something you would otherwise have to trust with something you can check.

Each installs on its own, works offline, and needs no account.

awnix is the ground floor — A Linux you can hand to an agent — immutable base, capabilities included.

The Aitherium ecosystem

Every repository here is public. Each publishes an aither-manifest.json beside its page, so any surface can read every sibling's — the network is browsable from any node in it.