Repository navigation
Description
Version: eval-97ce23f (v0.9.0+338) · Client: Claude Code · Model: Claude Haiku 4.5
Setting: 300-run benchmark, 2 Java repos (apache/kafka 184k nodes, jackrabbit-oak 132k nodes), warm daemon throughout.
What happens
Graph responses carry total and has_more, and the installed SKILL.md correctly tells the agent:
search_graphresults default to 50 per page — checkhas_moreand useoffset.
In practice agents frequently do not page, and nothing else in the payload signals that an answer is partial. The result is a confidently-worded but incomplete answer, which is harder to notice than a noisy one.
Measured effect
Task class: "which files declare a method whose shortest call chain to X is exactly 2 calls long". Same agent and model, grep only (A) vs grep + graph (B), 5 repetitions per task:
| repo | arm | precision | recall | files listed | true answer |
|---|---|---|---|---|---|
| jackrabbit-oak | grep only | 0.455 | 0.723 | 34.0 | 6.5 |
| jackrabbit-oak | grep + graph | 0.453 | 0.525 | 20.0 | 6.5 |
Precision is essentially identical; recall collapses. The graph arm is not more wrong — it finds less. The grep-only agent over-answers (34 files for a 6.5-file answer) and catches more by sheer volume.
Across all treatment runs, 429 responses carried has_more.
Concrete case
IndexRootDirectory.getIndexesPerPath in jackrabbit-oak; true answer 5 files.
- grep-only agent listed 8 files → found 5 of 5.
- graph agent listed 2 files → found 1 of 5, missing four test files.
The graph had the data: its trace_path(direction="inbound") returned callers_total: 4 correctly, and a later query_graph returned 4 rows. The agent stopped at a partial view and reported it as complete.
Suggestion
Make truncation hard to miss rather than merely reported:
- include the remaining count in the rendered text of the response, not only in a JSON field an agent may skip; or
- return an explicit
truncated: truewith a short human-readable note; or - auto-page up to a bounded limit for
trace_path, where caller sets are usually small.
Any of these would preserve the token savings the tool is built for while removing the silent-incompleteness failure mode.
Activity
DeusData commentedon Aug 3, 2026
Thank you for measuring the recall loss instead of treating pagination as a cosmetic concern. The tools already expose totals, cursors, and
has_more; the requested change is an agent-contract and default-behavior design over those primitives. I have routed it to0.9.2-rcfor a deliberate design pass, without yet committing to automatic page exhaustion for every query.DeusData commentedon Oct 19, 2026
Thank you again for measuring how partial pagination affects recall. I have no new decision on rendering remaining counts or bounded automatic paging. The concern is recorded as a response-contract design issue, without promising that every query will exhaust all pages.
DeusData commentedon Oct 25, 2026
Thank you for quantifying the recall impact. Remaining-count presentation and bounded paging still need a maintainer response-contract decision. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.