PaperlayerView exact revision on arXiv

Source-linked AI summary

CodeNib: A Multi-View Data System for Serving Repository Context to Coding Agents

Zhongming Yu, Hengjia Yu, Boqin Yuan, Shuting Zhao, Yizhao Chen, Aryan Dokania, Mihir Jagtap, Jiayu Chang, Yitong Ma, Yash Jayswal, Wentao Ni, Hejia Zhang, Zhaoling Chen, Gangda Deng, Jishen Zhao

arXiv:2607.25431v1cs.SE

TL;DR

Repository-context systems lack coordinated handling of heterogeneous views, incremental freshness, and bounded agent delivery. CodeNib unifies reusable repository views and serves search, navigation, and context, achieving faster matched-view maintenance and navigation with reduced trajectory tokens.

  • Problem

    Repository-context systems coordinate heterogeneous indexes, semantic tools, and prompt state poorly, leaving lifecycle management across retrieval, navigation, and delivery insufficiently unified.

  • Method

    CodeNib materializes lexical, dense, and structural views per commit, maintains selected views across edits, and serves ranked search, navigation, and bounded context.

  • Results

    Across lifecycle analyses, matched graph and vector updates achieve 8.67× and 25.44× median speedups, compatible static navigation is 4.72× faster, and policies use 50–87% fewer trajectory tokens.

  • Takeaways & Limitations

    The results frame repository context as a measurable serving problem with explicit, operation-specific validity boundaries rather than one unqualified notion of reuse.

  • Takeaways & Limitations

    Static navigation does not reproduce every live response, so callers requiring workspace semantics must retain a live LSP path.

Abstract

from arXiv · show

Coding agents repeatedly search, navigate, and retain context from evolving repositories, but disconnected indexes, language servers, and task-local histories force repeated discovery and obscure lifecycle costs. CodeNib builds reusable lexical, dense, and structural views per repository commit, maps outputs to repository-relative source ranges, maintains selected views across edits, and serves ranked search, symbol navigation, and bounded context through one runtime. Across 100 snapshots, we map quality-cost frontiers across the repository-context lifecycle. When outputs match an independent rebuild, graph and vector updates are $8.7\times$ and $25.4\times$ faster at the median. On the static-navigation subset matching normalized live-server locations (63% of 1,000 requests), the median per-request live/static latency ratio is $4.7\times$. Across five models, selected context policies preserve localization with 50--87% fewer trajectory tokens than paired grep/read. Together, these results support multi-view repository-context serving with explicit, operation-specific validity boundaries.

1 INTRODUCTION

CodeNib treats repository context as a coordinated data lifecycle: reusable lexical, dense, and structural views serve distinct agent operations while preserving shared source-linked state. It introduces view-specific construction and maintenance plus a runtime that delivers ranked results, navigation, and bounded context under explicit cost and quality analyses.

  • Motivation: Repository artifacts have distinct layouts, costs, update paths, and output contracts, making coordination across retrieval, navigation, and prompt state a data-lifecycle problem.Retrieval yields ranked candidates, whereas navigation yields source locations.
  • System design: CodeNib builds lexical, dense, and structural views independently and maps their outputs to common repository-relative source ranges.The system records which views are available for each commit.
  • Agent runtime: The runtime connects ranked plans, static/live navigation providers, and bounded context policies to agent tools through reusable repository views.It exposes static and live symbol providers through one location interface and tracks view, provider, and token usage.
  • System design: View-specific incremental maintenance uses Git/LSP-assisted graph repair and content-addressed vector reuse, comparing timed updates with independent rebuilds only when outputs match.This preserves update fidelity while measuring speedups against an independent rebuild baseline.
  • Evaluation: Evaluation spans retrieval, reranking, dense-index construction and search, navigation, incremental maintenance, and bounded context delivery without collapsing quality, compatibility, fidelity, latency, and token usage into one score.The analyses use stage-separated Pareto and quality–cost comparisons across the repository-context lifecycle.

2 BACKGROUND AND POSITIONING

CodeNib positions repository context as manifest-linked, source-anchored lexical, dense, and structural views served through one local runtime. It distinguishes curated physical routes and explicit validity boundaries from general fact systems, live providers, and learned exploration.

  • Multi-view repository serving: CodeNib catalogs specialized text, vector, and graph indexes behind a manifest, using curated physical routes rather than cost-based plan search.This adapts materialized-view reuse to changing repository commits while mediating heterogeneous operators.
  • Code intelligence systems: CodeNib combines dense and sparse retrieval with serialized code-intelligence ideas in a local runtime, without claiming Glean-scale storage or a general fact language.The comparison includes LSP, LSIF, SCIP, Glean, Sourcegraph, and Zoekt.
  • Incremental maintenance: CodeNib repairs source-anchored graph facts and retains Tree-sitter source ranges when semantic coverage is absent, while recording semantic-navigation availability in the manifest.Independent rebuilds qualify reported speedups offline rather than running on the maintainer path.
  • Multi-view repository serving: CodeNib links ranked retrieval and structural navigation views to the same repository commit, unlike systems that use these capabilities separately.Its positioning spans dense retrieval, graph exploration, structural context, and navigation-oriented codebase indexes.
  • Evaluation boundaries: The evaluation holds candidates fixed while varying initial delivery and one-time compaction, restricting static/live latency to matching normalized locations and token savings to paired localization margins.These claims do not extend to learned exploration or patch correctness.

3 SYSTEM OVERVIEW

CodeNib separates commit-indexed view construction and maintenance from query planning and agent-runtime context delivery, joining them through a repository manifest. Its design also makes publication boundaries, capability-driven loading, provider choice, and limits on transactionality and live-navigation equivalence explicit.

  • Repository View Compiler: The Repository View Compiler builds or maintains commit-indexed graph, vector, BM25, and optional Zoekt views, while the manifest M_c catalogs each view’s commit, status, profile, and capabilities.View builders derive source-linked units; maintainers use Git diffs for graph repair or content-addressed vector reuse. M_c is a runtime lookup boundary, not a payload container.
  • Publication and Maintenance: Initial builds publish M_c only after all requested builders finish, whereas graph and vector delta maintainers update their own stores.Optional-view failure does not invalidate successful siblings, and the two publication boundaries let evaluation vary one physical path independently.
  • Request Plane: Ranked retrieval lowers queries to dense, lexical, structural, or fused plans returning ordered source-linked blocks, while symbol navigation returns normalized locations from static or live providers.Provider choice remains visible in traces, even when returned locations share a normalized interface.
  • Agent Runtime: The agent runtime reads M_c, loads only required prebuilt views as process-local state, and delivers context through tools or policies that preload ranked L2 blocks and retained observations.MCP resources load once per process, while selected skills determine which indexes the agent path loads; the runtime does not build views or insert code into history.
  • Scope and Limitations: CodeNib does not choose edits or judge tests, its manifest is not transactional, and static navigation cannot reproduce every live response, so workspace-semantic callers must retain a live LSP path.Compilation records a commit without locking the worktree, and rebuild comparisons occur only after timing rather than on the maintainer path.

4 REPOSITORY VIEWS AND REQUEST SEMANTICS

The section defines four repository-context operations with distinct output contracts and costs, then specifies semantics for retrieval, navigation, maintenance, and context delivery. It also bounds interpretation through explicit matching, persistence, and quality-preservation rules.

  • Operation semantics: Four operations—ranked retrieval, symbol navigation, structural maintenance, and context delivery—are evaluated by distinct returned values and measured costs.Their output comparisons do not constitute one shared runtime gate.
  • Ranked retrieval: Retrieval lowers requests into lexical, semantic, hybrid, or structural routes, with route-local fusion, caller-limited output width, optional reranking, and graph expansion only on structural route D.Retrieval fan-out and reranker candidate work are separate because they have different latency and recoverability effects.
  • Symbol navigation: Navigation matches static and live providers only on normalized unique path/start-line locations, so coverage and matched-request latency must be reported separately.A match does not establish full response equality or universal LSP interchangeability.
  • Structural-view maintenance: Maintenance speedups are conditioned on graph-fact equality and deterministic replay after persistence and reload against an independently rebuilt target.The rebuild and comparisons occur offline, are excluded from update latency, and do not cover live-LSP behavior or atomic cross-view publication.
  • Context delivery: Context policies compare grep/read, eager L2 injection, and one-time history rewriting using trajectory tokens and AnswerRecall@5 over the first five deduplicated final-answer spans.Quality preservation requires the lower bound of the paired 95% interval for ΔAR@5 to meet ε = 0.05; among qualifying policies, fewer tokens are preferred.

5 MATERIALIZED REPOSITORY VIEWS

CodeNib materializes separate structural, dense, and lexical artifacts for each repository checkout, linked by repository-relative ranges and commit metadata. A capability-aware manifest isolates builder failures while serving available views, with explicit boundaries for navigation, search, and schema validity.

  • View representation: Each checkout uses separate structural, dense, and lexical artifacts linked by repository-relative source ranges and the recorded repository commit.The views do not share a storage engine or globally meaningful backend identifier.
  • View representation: 14 languages are chunked through an L0/L1/L2 tree-sitter hierarchy supporting file- or callable-level indexing and stable source boundaries across backend symbol IDs.A language may omit L1; evaluation can project callable units to enclosing files.
  • Structural view: The structural graph stores directories, files, and typed symbols with containment plus optional reference, import, and type-use edges, while bounded queries use ranges and edge anchors.Position-to-enclosing-symbol lookup provides a fallback when exact occurrences are absent, and schema mismatches require rebuilding rather than silent migration.
  • Retrieval views: Dense retrieval embeds files or callables into FAISS, whereas BM25 ranks source-unit text and optional Zoekt indexes raw-file trigrams for substring and regex search.MCP normalizes outputs to paths, ranges, snippets, and optional scores; HNSW is restricted to the Q2 ablation.
  • Build and validity: Independent builders record status and metadata in a commit-bound manifest, derive capabilities, and preserve successful views when another builder fails.The manifest does not provide cross-store transactions or certify later worktree state.

6 VIEW CONSTRUCTION AND FRESHNESS

CodeNib constructs repository views with provenance-aware identities, backend-specific semantic coverage, and deliberately separate freshness and publication boundaries. Incremental repairs preserve valid structure where possible, but reported gains are conditioned on independently rebuilt targets and static serving does not automatically replace live responses.

  • Provenance and identity: Every artifact and capability records the repository state, profile, and backend that produced it, while construction and incremental repair retain different freshness and publication boundaries.Repository/commit and artifact-profile identities are distinct, and profiles are nested under source identity.
  • Backend coverage: Backend selection distinguishes syntactic hierarchy from resolved cross-file occurrences, with SCIP and clangd for mature or compiled-language routes and tree-sitter plus text retrieval elsewhere.Exact occurrences enable character-accurate lookup; without them, static serving advertises coarser graph behavior.
  • Incremental repair: Symbol-level repair uses 9→5 displayed LSP requests, four or 44.4% fewer than file-level repair, by preserving stable graph facts and repairing edit-invalidated state.The saving excludes synchronization, documentSymbol, and other protocol messages, and Q4 reports it only for transitions matching an independently rebuilt target.
  • Backend coverage: Compiled-language graph builders fail explicitly when dependencies, compilation databases, or successful builds are unavailable, rather than silently substituting weaker data under the same capability.These preparation requirements define the boundary of semantic coverage.
  • Serving boundary: Static and live providers normalize shared inputs and expose provenance and granularity metadata, but failed all-request equality prevents automatic routing of unseen requests to static serving.The interface retains live JSON-RPC because static responses cannot be predicted to match an unseen live workspace response.
  • Incremental repair: Delta paths do not transactionally advance all views, so each reported speedup is conditioned on offline comparison with an independently rebuilt target.Burst throughput and cross-view staleness remain outside scope.

7 QUERY AND CONTEXT RUNTIME

CodeNib’s runtime separates offline view compilation from manifest-mediated online loading, then serves repository context through a ReAct-compatible tool loop and deterministic retrieval/context policies. The runtime enforces explicit view and location-validity boundaries while supporting bounded context delivery and one-time Compact history rewriting.

  • Runtime setup: Offline compilation publishes manifest-linked artifacts and capabilities; online load_views validates and opens required views without building indexes or inserting retrieved code into model history.A missing required view aborts setup.
  • Agent loop: The agent loop follows ReAct’s reason–action–observation topology, while CodeNib supplies view-backed tools, policy-controlled delivery, and provenance-bearing trace records.Manifest preflight constructs the session tool set and initial history; each turn dispatches tool calls to observations until a terminal answer.
  • Context policies: Q5 fixes k=10 candidates, with Grep/read starting from [S,Q], Eager and Compact from [S,Q,C], and Compact performing one later rewrite to [S,Q,D].After the rewrite, later invocations append normally and can reuse the fixed KV-cache prefix.
  • Query planning: Deterministic ranked-query compilation lowers signals, budgets, and manifest capabilities to a route tuple controlling retrieval width, reranking, and structural expansion.Routes A–D are selected by r; only hybrid C owns RRF, and graph expansion h is available only on structural D.
  • Validity boundaries: Static and live definition/reference serving normalize to one location schema, but Q3 compares normalized location sets before timing because metadata alone does not establish agreement.The MCP surface remains static, and no online classifier predicts compatibility for unseen requests.

8 IMPLEMENTATION

CodeNib is implemented as a Python package suite whose reusable operators support agent skills and stdio MCP serving. Its runtime separates provider selection, resource loading, schemas, history, and traces while making backend choice and unavailable resources explicit.

  • Architecture: Python 3.10+ CodeNib comprises compiler, graph, index, agent-runtime, and serving-adapter packages, including stdio MCP.Evaluation runners own sampling, arm wiring, timing, and post-run output comparisons, while reusable operators and history policies remain in core packages.
  • Runtime resource management: At MCP startup, ServerContext loads vector, BM25, graph, and Zoekt resources once, while agents load only skill-required views.The agent runtime owns provider selection, tool schemas, history state, and per-run traces.
  • Provider selection: LSP-shaped skills use an injected static or live provider, and traces record which backend served each request.Static and live implementations share the agent-facing location schema; MCP currently instantiates static serving, while live JSON-RPC is an agent/evaluation path rather than an automatic fallback.
  • Serving surface: Agent skills and stdio MCP wrap the same operators and normalized results through separate model-facing schemas.MCP exposes semantic, BM25, regex, and Zoekt search; dependency, definition, reference, and route tools; and get_manifest.
  • Serving surface: Missing optional indexes return explicit tool errors rather than silently falling back under the same name.Search returns snippets, whereas LSP-shaped tools return compact locations; authentication, multi-tenancy, and network transport are outside the evaluated stdio implementation.

9 EVALUATION

CodeNib’s evaluation finds operation-specific quality–cost tradeoffs across retrieval, construction, navigation, maintenance, and agent context selection. The results support conditional reuse and model-dependent policies rather than universal replacements or routing rules.

  • Retrieval: 0.705–0.820 file recall and 0.422–0.638 symbol recall at k=10 vary across embedding families, while mean dense-query time spans 26–295 ms.Higher-recall operating points generally incur greater build and query costs.
  • Retrieval: 4.6-point file-recall gain costs 46.6× latency: Jina plus the 4B reranker reaches 0.858 Recall@10 in 4.29 s versus 0.812 in 92 ms for Jina dense.Symbol recall peaks at 0.742 with Qwen3-Embedding-4B plus the 8B reranker at k′=100, requiring 14.1 s.
  • Build and serving: 19.3–285.0 s median L2 construction is 5.0–6.4× within-model L0 construction, while dense-query latency rises from 20.9 to 233.8 ms.The scaling trend is descriptive, and timed index loading is excluded.
  • Navigation: 63.2% of 1,000 navigation requests match normalized locations, yielding static/live p50 latencies of 0.62/2.26 ms and a 4.72× median live/static ratio.Static navigation is lossless only under the matched location projection and requires an online compatibility test.
  • Maintenance: 90.3% of vector source-changing transitions match independent rebuilds with 25.44× median speedup, versus 45.5% and 8.67× for symbol repair.The comparison identifies preserved outputs offline and is not a runtime guarantee.
  • Agent context: 27.9–49.9% of paired grep/read tokens preserve localization, with ΔAR@5 from −0.009 to +0.067 under the selected Eager-or-Compact policies.Compaction is model-dependent rather than uniformly dominant; all reported lower bounds exceed −0.05.

10 DISCUSSION AND FUTURE DIRECTIONS

CodeNib’s future system boundary is a concurrent, resource-aware repository database that preserves explicit view-validity boundaries while coordinating heterogeneous computation. Its recorded serving traces could support post-training data flywheels, but current measurements do not establish these extensions.

  • A concurrent heterogeneous repository database: A full database service should support concurrent agents and updates, per-view versions under atomic publication, recovery, multi-tenancy, and cost-based routing across heterogeneous views.The central challenge is preserving each view’s explicit validity boundary while accommodating heterogeneous hardware and update rates.
  • Agent harnesses, post-training, and a data flywheel: Runtime traces of requests, selected views, tool interactions, delivered context, and costs could provide supervision for retrieval routing, tool use, context selection, and compaction.Evaluated outcomes could feed subsequent data collection and fine-tuning, making the serving layer both an execution substrate and a controlled training-data source.
  • Resource-efficient context serving: A production scheduler should coordinate CPU-oriented retrieval and navigation with GPU-oriented embedding, reranking, and inference under memory, token, and latency budgets.It should decide what to batch, preload, retain, or evict as models and workloads differ in useful context, latency tolerance, and CPU/GPU demand.
  • Scope: Current measurements cover controlled repository, navigation, maintenance, and localization workloads, not concurrent publication, learned online scheduling, or post-training gains.These unestablished capabilities define the next system boundary.

11 CONCLUSION

CodeNib compiles lexical, dense, and structural repository views per commit under explicit validity boundaries, combining repair and reuse paths with cost-visible serving. Its analyses frame repository context as a measurable serving problem while keeping maintenance, navigation compatibility, and policy-dependent localization distinct.

  • Repository view compilation: CodeNib materializes lexical, dense, and structural views per commit under explicit validity boundaries.The compiler’s repository views are maintained across commits rather than treated as a single unqualified reuse mechanism.
  • Repository view compilation: 8.67× and 25.44× median speedups are achieved by graph-repair and vector-reuse paths on transitions matching independent rebuilds.These speedups quantify update performance for the graph and vector views under the stated rebuild-matching condition.
  • Cost-visible serving: 4.72× is the median per-request live/static latency ratio for compatible static navigation requests.The runtime serves ranked plans, static/live navigation, and bounded context policies, with this ratio applying specifically to compatible static requests.
  • Evaluation framing: Pareto and quality–cost analyses keep quality, compatibility, update fidelity, latency, and token usage distinct.This framing avoids collapsing exact maintenance, projection-compatible navigation, and policy-dependent localization into one unqualified notion of reuse.

A DATASET CONSTRUCTION AND GROUND TRUTH

CodeNib constructs frozen Base and Synthesis datasets from repository snapshots, with deterministic sampling, extraction, and validation procedures. Ground truth consists of pre-patch modified or deleted source units, evaluated only on base snapshots.

  • Frozen datasets: CodeNib Base contains 100 unique repository–base-commit snapshots from 25 repositories, while CodeNib Synthesis contains 500 rows across five configurations.Both datasets record parquet hashes and canonical row-identity hashes.
  • Upstream provenance: Neither split is a raw SWE-bench agent-resolution workload; Base resamples issue–patch pairs from SWE-bench Verified and SWE-bench Multilingual.The datasets retain repositories, pre-solution base commits, issue bodies, and developer patches, but do not run upstream pass/fail tests.
  • Base sampling: Repositories are sampled within language groups by non-hidden file counts at approximately minimum, quartile, and maximum ranks after excluding repositories with fewer than three candidate issues.Rounded-rank collisions use a deterministic center-out fallback, and issue difficulty is classified as low, medium, or high from issue bodies and fixed-model judgments.
  • Ground-truth extraction: Ground truth retains pre-patch symbols overlapping changed hunks when content changes or when symbols are deleted, rejecting rows with extraction failures, empty targets, required new symbols, or over ten target blocks.Extraction checks out the exact base commit and parses target files before and after applying the developer patch.
  • Evaluation targets: Retrieval runs only on base snapshots, scoring pre-patch modified or deleted source units and enclosing files; added-only code has no retrievable target.Tree-sitter chunks use zero-based inclusive CodeChunk ranges, while dataset exports use one-based inclusive CodeLocation ranges.
  • Synthesis construction: Synthesis selects one snapshot per repository—the one with the most graph symbol vertices—yielding 25 snapshots with 20 queries each.Generation uses fixed seeds, a ten-turn cap, consensus runs, judge-based retries, and deterministic validation of query IDs, targets, and language declarations.

B METRIC DEFINITIONS AND WORKED EXAMPLES … G LIFECYCLE EXECUTION BOUNDARY

The paper defines operation-specific metrics and execution boundaries for repository-context views, then evaluates multilingual materialization, semantic backends, retrieval, maintenance, and lifecycle costs under explicit validity conditions. Strict output contracts distinguish exact correctness from diagnostic agreement, while measured maintenance and serving results quantify the benefits and limitations of reusable views.

  • B METRIC DEFINITIONS AND WORKED EXAMPLES: Recall and match metrics are macro-averaged per instance, so instances with more targets receive no extra weight.The studies expose different output contracts, making their metrics non-interchangeable.
  • C MULTILINGUAL SOURCE UNITS: L0 emits at most one signature-only skeleton per processed file, while evaluated L2 retains top-level leaf declarations and nested members but omits enclosing class or struct declarations.Levels are semantic adapter outputs rather than fixed AST depths shared across grammars.
  • D PARSING AND SEMANTIC-NAVIGATION BACKENDS: Tree-sitter supplies deterministic syntax trees and ranges, SCIP provides persistent semantic artifacts, and LSP supports live reference-provider and repair requests.Files remain available to lexical and dense retrieval when semantic backends are unavailable, with missing capabilities reported explicitly.
  • D PARSING AND SEMANTIC-NAVIGATION BACKENDS: 100 snapshots supply five definition and five reference positions each, with live-provider warmup requiring two to eight rounds until normalized outputs stabilize.Initialization, startup, idle waiting, and warmup are recorded separately from marginal request latency.
  • E RETRIEVAL MODELS AND FROZEN PARAMETERS: All five embedders use Sentence-Transformers with shipped pooling modules and Flat inner-product FAISS, without extra normalization beyond each model’s modules.Recovered cache revisions provide post-hoc provenance for historical runs rather than execution-time locks.
  • INCREMENTAL-MAINTENANCE PROTOCOL: 15/33 symbol and 14/33 file maintenance rows match independent rebuilds under exact graph and serving checks.Four Rust/TS rebuilds reach 99.75% median edge F1 and 99.35% serving agreement, but one remains inexact on changed scope; all 31 vector targets match identities and vectors, while three Rust rows fail exact replay.
  • INCREMENTAL-MAINTENANCE PROTOCOL: 8.67× and 1.95× are the median graph maintenance speedups on transitions matching independent rebuilds.The 14 rows where both paths match yield a 4.25× median file/symbol time ratio.
  • G LIFECYCLE EXECUTION BOUNDARY: Each materialization uses an isolated quiescent checkout and fresh processes but retains host caches and remote model weights, so construction is warm-host rather than machine cold-start.Lifecycle cost includes materializing both L0 and L2, followed by one warmup and three measured repetitions over a 20-session service trace.

H AGENT-CONTEXT PROTOCOL AND VALIDITY DETAILS · I AUTHOR CONTRIBUTIONS · J ADDITIONAL DISTRIBUTIONAL VIEWS

The protocol specifies deterministic context compaction, execution and answer-format controls, while reporting policy contrasts and validity caveats. Additional sections document author contributions and provide distributional views for cutoff sensitivity, latency, and workload-slice effects.

  • H AGENT-CONTEXT PROTOCOL AND VALIDITY DETAILS: Compaction restores the clean issue, deduplicated paths, newest successful read, and a direction cue capped at the latest assistant message’s first 600 characters.The candidate dump and prior assistant/tool messages are removed, while accounting retains all pre-rewrite usage.
  • H AGENT-CONTEXT PROTOCOL AND VALIDITY DETAILS: Local runs use model-specific vLLM versions and token caps, with 48,000-token histories, 4,096-token completion windows, prefix caching, and recorded Gemini controls.Gemma uses a pinned Hub revision and versioned tool template; Gemini 2.5 Flash uses Vertex AI with thinkingBudget=0.
  • H AGENT-CONTEXT PROTOCOL AND VALIDITY DETAILS: 24.4/16.6/13.2% are baseline/eager/compact answer-format trigger rates for 9B, versus 10.8/7.6/3.6% for 27B and zero for Haiku.Gemma and Gemini rates are 12.0/1.8/0.6% and 3.2/0/0%; invalid answers remain in quality metrics with zero recall.
  • H AGENT-CONTEXT PROTOCOL AND VALIDITY DETAILS: 123.3%, 87.6%, and 78.7% are compact/eager token ratios for Haiku/9B/27B, with paired AnswerRecall@5 changes of +0.018, −0.023, and +0.008.Gemma/Gemini ratios are 27.9% and 76.3%, with recall changes of −0.070 and −0.044; all intervals are 95% CIs.
  • H AGENT-CONTEXT PROTOCOL AND VALIDITY DETAILS: Removing five judge-warning queries does not change which policy meets the localization margin, although provider-time drift remains unresolved.Haiku backfill retains the observed model ID and harness.
  • I AUTHOR CONTRIBUTIONS: Zhongming Yu led conceptualization, methodology, software, and supervision across LSP, retrieval, incremental indexes, agent infrastructure, analysis, validation, visualization, and writing.Hengjia Yu contributed software for LSP, incremental graphs, and agent infrastructure, plus investigation, validation, and visualization; the supplied contribution passage also lists Boqin Yuan’s data curation and software roles.
  • J ADDITIONAL DISTRIBUTIONAL VIEWS: Figure 13 visualizes Table 9, while Figures 14 and 15 expose distributions compressed in Figures 9 and 11(c).Figure 13 shows paired mean ΔAnswerRecall@k with snapshot-clustered 95% CIs and invariant Eager/Compact selections across four cutoffs.
  • J ADDITIONAL DISTRIBUTIONAL VIEWS: Figure 14 conditions Q3 latency distributions on the 632 matching requests, excluding startup, loading, and warmup, rather than representing achieved workload speedup.Figure 15 reports descriptive language and query-type intervals for provider-reported tokens and AnswerRecall@5 without defining a subgroup-routing policy.
Loading 2607.25431v1…