Notes on what we are seeing in agent research, from the team building Koragraph.
A code graph does not spend most of its effort storing structure. It spends it deciding: which neighbour to expand, whether an edge is relevant to a query, how far a change is likely to reach. TypeSafe’s new model, Jev, is the first thing cheap and fast enough to answer millions of those questions without a token-billed model ever touching the retrieval path, which is the property that makes it worth studying rather than simply adopting.
We build KoragraphMCP as a local, multi-repo code graph for coding agents, and the graph is deliberately deterministic. There is no model in it. That constraint is the reason Jev is interesting to us instead of routine. A conventional language model on the hot path would break the design outright, because it is slow, priced per token, and free to hallucinate an edge that does not exist. A typed decision model is a different kind of object, and the rest of this piece is about where that difference helps and where we expect it to fail.
What is Jev, and why does it change the economics of a graph?
Jev is what TypeSafe calls a System One model, a name borrowed from Kahneman’s fast, intuitive mode of thought. It does not generate text one token at a time. It takes structured state in and returns a single typed decision out, drawn from a schema fixed in advance: a Choice over up to 255 options, a Score on a rubric, or a yes-or-no probability. Every output arrives with a calibrated confidence value, and because the output space is bounded to the schema, the model cannot return something off the menu. TypeSafe reports end-to-end latency between 70 and 500 milliseconds, input priced at 0.042 dollars per million tokens, and output cheap enough that they decline to meter it.
The number that matters for graph work is not the accuracy figure. On TypeSafe’s own evaluations Jev lands near 68 percent agreement with reference answers, a little below frontier chat models such as Claude Opus 5 at roughly 73 percent, and those are vendor-reported figures that no third party has replicated yet. The number that matters is the price of a single decision. When one local judgement costs a fraction of a cent and returns inside a tenth of a second, you can afford to ask a learned question at every node and every edge of a graph, which is exactly the budget a code graph never had before.
There is one architectural detail to hold onto, because two of the three ideas below turn on it. Jev is a non-autoregressive model: it produces its outputs in parallel, in a single pass, rather than one step at a time, and separate decisions do not see each other. That independence is what buys the speed. It is also an assumption with a long research history, and assumptions are where the research is.
Can a learned reranker improve code-graph retrieval without adding tokens to the hot path?
The first idea is the safe one, and it is safe precisely because it respects the independence assumption. When an agent calls explore, Koragraph returns candidates ranked by structure: call counts, import distance, co-change frequency mined from git history. Structure is a strong prior and a blunt one. Whether a given symbol is relevant to this query is a judgement, and judging one candidate does not require judging the others, so a per-candidate Score is a natural fit for a model that answers questions independently.
The proposal is to keep the deterministic graph as the retriever and add Jev as a reranker over the top forty or so candidates it already produces. Graph-aware reranking is an active research line: G-RAG treats reranking as a problem over a graph of connected passages (arXiv:2405.18414), and later work reranks through the corpus graph directly (arXiv:2406.11720). What is new here is the cost profile. Prior rerankers are cross-encoders or language models, which put a paid model on every query. A System One reranker at Jev’s price keeps the token count on the retrieval path at zero, which preserves the one property that makes a local code graph worth running in the first place.
The claim to test is narrow and measurable. Take a repository, a set of real queries with known relevant files, and compare structural rank against Jev-reranked order using normalised discounted cumulative gain and recall at ten. If a free reranker moves the right file up the list, the graph keeps its determinism and gains a calibrated sense of relevance it never had.
Does a blast-radius query survive being predicted as independent decisions?
This is the idea we care about most, because it is where we expect the model to break. blast_radius does not ask for one node. It asks for the set of code a change is likely to reach, which software engineering has studied for decades as change impact analysis over a program dependence graph (arXiv:2607.23355). The defining feature of that set is correlation: whether node B belongs depends on whether node A did, because B may only be reachable through A. The answer is a joint object, not a bag of independent picks.
Jev answers independently. Ask it, in parallel, whether each candidate belongs in the blast radius, and nothing in the model ties one answer to the next. The worry is concrete: independent yes-or-no decisions can return an incoherent set, one that includes a node whose only route in was a node the same pass excluded. This worry is neither new nor ours. Parallel generation research has studied it for years under the name the multimodality problem: a model that produces every output at once and treats those outputs as conditionally independent cannot represent a target whose parts are correlated, and the result is internally inconsistent output. The paper that introduced non-autoregressive translation identified this failure directly (arXiv:1711.02281), and the survey literature since has treated it as intrinsic to independent parallel decoding rather than a training artefact (arXiv:2204.09269). Jev is a non-autoregressive model pointed at graph decisions, so the open question is whether the multimodality problem returns when the correlated output is a subgraph rather than a sentence. Graph learning offers a topological cousin of the same idea, where a structure forces the signal a decision needs through connections too narrow to carry it and the signal is lost, what that literature calls over-squashing (arXiv:2111.14522). We would not claim the two mechanisms are identical, only that both predict the same symptom: correlated structure degrades when it is forced through a channel that cannot represent it.
There is a tell that the concern is real rather than theoretical. TypeSafe’s own high-cardinality mode does not stay fully independent: it scores options independently and then adds an explicit selection stage on top, which is a quiet admission that pure independence has limits once choices interact. The experiment is to make that interaction visible. Measure the coherence of a Jev-predicted blast radius against Koragraph’s deterministic ground truth, using set precision and recall alongside a reachability-consistency check that counts included nodes with no included path back to the change. If coherence falls as the correlated set grows, we have a clean, small-scale demonstration of over-squashing in graph-based agent decisions, and a reason to prefer joint prediction over parallel independence for this class of query.
What happens when every edge in a code graph carries a calibrated weight?
The third idea is the one that turns retrieval into mathematics, and it starts from a gap in the graph. Koragraph’s edges are typed but unweighted: a call, an import, an inheritance link, and a co-change edge all count the same when you walk the graph. A calibrated Score per edge, conditioned on the query, turns the flat multigraph into a weighted graph, and a weighted graph is the object the classical toolkit was built for.
Once edges carry trustworthy weights, retrieval becomes a walk rather than a lookup. Personalised PageRank seeded at the query’s entry points gives a principled relevance ordering over the whole repository, and the algorithmic groundwork for computing it at scale is well surveyed (arXiv:2403.05198). The word doing the work in that sentence is calibrated. Spectral methods and random walks are only as sound as their weights, and a model that is overconfident poisons the stationary distribution quietly. This is why Jev’s calibration training matters more than its raw accuracy: calibration is the property that makes downstream graph mathematics trustworthy at all, and the reliability of confidence estimates has been the central question in the calibration literature since Guo and colleagues framed it (arXiv:1706.04599). The test is a comparison of walk-based retrieval on the Jev-weighted graph against the deterministic structural ranking, on the same queries and metrics as the first idea, with expected calibration error reported for the edge scores themselves.
Where this leaves us
The three ideas line up along a single axis, which is how much correlation the query carries. Reranking is a set of independent judgements, and independence is where Jev is strongest. Blast radius is a joint object, and independence is where we expect it to break. Weighted-graph retrieval sits between them, recovering global structure by letting a walk do the correlating that a single decision cannot. Read in order, they are a way of mapping the boundary of what a fast independent decision model can and cannot do on a graph, which is a more durable contribution than any one benchmark.
We landed on the independent-versus-joint framing while thinking about our own blast_radius tool, before wiring any of it up, and the tooling to run all three now exists: Jev is live through OpenRouter’s decisions endpoint, and a few dollars covers thousands of real decisions against a real repository.