query: crossing the truncation threshold adds EDGE lines that the budget never counted — --budget 8000 emits ~36k tokens (4.5x over)

[PatrickM-git]

Summary

graphify query --budget N stays within budget only while the result is truncated. The moment the budget is large enough that nothing gets cut, the output additionally emits every EDGE line — a section that is entirely absent from the truncated output — and overshoots the requested budget by ~4.5x.

Two adjacent budget values differ by a factor of 6.2 in output size.

Reproduction

graphify 0.9.43, Windows 11 / Git Bash, --code-only graph of a ~930-file TypeScript + SQL monorepo. Same question, same graph, only --budget changes:

--budget	chars	NODE lines	EDGE lines	banner
2000 (default)	6,558	62	0	showing 62 of 217 nodes
4000	12,600	~120	0	truncated
6000	18,590	180	0	showing 180 of 217 nodes
7000	21,644	211	0	showing 211 of 217 nodes
8000	133,475	217	912	none

At ~3.7 chars/token that last row is ~36,000 tokens for a requested budget of 8,000.

Stable across three consecutive runs — 133,477 chars every time, byte-identical.

Cause

The truncated and untruncated paths do not emit the same kind of content:

budget=7000  ->  216 lines total:  211 NODE,   0 EDGE
budget=8000  -> 1131 lines total:  217 NODE, 912 EDGE

Going from 211 to 217 nodes (+6) adds +111,831 characters. Those characters are not nodes — they are 912 EDGE lines that the truncated path never emits at all. Whatever computes "does this fit in the budget" appears to account for NODE lines only, while the untruncated writer also emits the edge section.

So the budget is not merely exceeded — it is computed against a different payload than the one actually written.

Why this matters in practice

The default budget (2000) truncates aggressively and says so:

[!] TRUNCATED: showing 62 of 217 nodes (~2000-token budget).
    The answer may be among the 155 cut nodes — raise the token budget (CLI: --budget)

The banner tells the user to raise --budget. Following that advice is exactly what triggers the blow-up. For an agent workflow the difference is decisive: at the default budget a query costs ~1.8k tokens and is cheaper than reading the files; one notch past the threshold it costs ~36k and is more expensive than reading everything it was supposed to replace.

Note on the threshold

The threshold is not a fixed budget value — it is wherever the result stops being truncated, so it moves with the graph. On this machine it sat between 6000 and 7000 before a graphify watch rebuild and between 7000 and 8000 after it. The jump itself reproduced identically on both sides of that rebuild.

Expected

Either:

1. count EDGE lines against the budget as well, so --budget N is honored on both paths, or
2. emit the same sections on both paths (edges truncated alongside nodes), so crossing the threshold is continuous rather than a step change.

Related but distinct: #2530 (fixed 2000-token default degrades recall) and #2601 (banner printed when 0 nodes were cut). This one is about the untruncated path overshooting an explicitly requested budget.

[AromalBiju1]

I'd like to take this one. Dug into _subgraph_to_text in graphify/serve.py — can confirm the root cause: once the char-budget cut point lands past the last NODE line (cut_count == 0), the function returns the full output string unconditionally, bypassing the budget check for the EDGE section entirely. That's the exact step-change described above — it's not that edges are counted differently, it's that they're not checked against budget at all once nodes stop being cut. That path was introduced by the #2601 fix (which correctly stops a misleading "0 nodes cut" truncation banner from firing) but as a side effect it also silently disabled the budget cap past that point.

Fix I'm proposing: keep the #2601 completeness guarantee (once every node fits, don't drop edges either — an agent shouldn't get a randomly-incomplete answer) but replace the silent bypass with an honest overshoot notice — actual node/edge counts and real token estimate vs. the requested budget, and critically not repeating "raise --budget" advice in that case, since that's what causes the blow-up. Have a patch + regression tests ready (verified the existing #2601 test still passes unmodified). Will open a PR shortly.

[safishamsi]

Fixed in v0.9.46 (on PyPI now) via #2785, thanks @AromalBiju1. Closing.