Pith. sign in

REVIEW 5 major objections 6 minor 2 cited by

CORVUS: Context Optimization and Reduction Via Underlying Synchronization for LLM Coding Agents

T0 review · 5 major / 6 minor · reviewed 2026-08-01 · deepseek-v4-flash

Pith's one-line read This paper claims that a synced file registry, decoupling reads from file contents, cuts agent context bloat by 9–50% with no loss in solve rates.

desk verdict CORVUS is a clean, genuinely new way to keep coding-agent context synchronized, with plausible efficiency gains; the main risk is that the paper oversells 'by construction' savings that actually depend on re-read patterns, and the evaluation lacks released artifacts and significance tests. read the letter →

arxiv 2607.22711 v1 pith:SBAS4KM5 submitted 2026-07-20 cs.LG cs.AIcs.SE

classification cs.LGcs.AIcs.SE
keywords LLMcodingagentstrajectoryarchitecturecontextoptimizationfilesynchronizationappend-onlytrajectoriesrotagentefficiencysoftwareengineering
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

CORVUS claims that the append-only trajectory architecture used by LLM coding agents stores mutable file contents as fixed snapshots, causing duplicate reads, stale-context edit failures, and rapid context growth. The paper replaces inline file reads with a sync_file tool that registers files in a synced set and injects their current contents before each reasoning cycle. This keeps at most one up-to-date copy of each relevant file in the prompt, by construction preventing stale snapshots. Across two standard software-engineering benchmarks and four LLMs, CORVUS reports 9–50% fewer input tokens, 15–32% shorter final prompts, and up to 37% fewer reasoning cycles with comparable pass rates. The significance is that context growth is both a cost and a reliability problem, so addressing it at the source makes long-horizon coding agents cheaper and less error-prone.

What carries the argument

The mechanism is the synced file set plus a sync_file tool and a context-sync phase. sync_file decouples registration from retrieval: instead of appending a file snapshot to the message history, it produces a marker 'sync:f' and records the file in the registry. At the start of each reasoning step the synchronizer reads the latest contents of every registered file from the repository and injects them after the message history, so the agent's next decision always sees the current repository state.

What would settle it

A benchmark or set of tasks where success requires comparing an old and new file state—such as undoing a specific edit or identifying what changed since an earlier read—would settle the claim: if CORVUS solves these at a clearly lower rate than the append-only baseline, the 'comparable pass rates' conclusion fails for such tasks.

Watch

Extended reading notes

Core claim

The central claim is that file contents are mutable state and should not be written into immutable chronological history. CORVUS introduces a synced file set: a sync_file tool registers a file and returns a lightweight marker; before each reasoning cycle a context-sync phase refreshes all registered files from the repository and places their current contents in a dedicated prompt block. This guarantees at most one current version of each file in context, eliminating duplicate snapshots and stale references while keeping the trajectory in sync with the codebase by construction.

Load-bearing premise

The pass-rate parity rests on the premise that the agent never needs an earlier version of a file for reasoning, since CORVUS discards all historical snapshots and keeps only current contents.

Editorial extensions

If this is right

  • Trajectory size no longer scales with repeated reads of the same file; re-reading is replaced by a cheap local refresh.
  • Reduced stale-context edit failures cut recovery cycles and further token growth.
  • The method composes with reactive context management; combining both gives larger token and cost reductions than either alone.
  • Lower token cost and latency make long-horizon tasks more feasible within context-window limits.
  • Developer edits to the repository during a session are reflected in the next reasoning cycle, improving human-AI co-edit robustness.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the design suggests a general principle—mutable tool outputs should live outside immutable trajectory history—and the same registry idea could apply to command outputs, database queries, or test logs that change over time.
  • A likely boundary: tasks requiring the agent to reason about what changed between two snapshots (e.g., 'revert my last edit') may lose information, since only current contents are kept; such tasks deserve dedicated testing.
  • A testable extension: partial synchronization at function or block granularity, anchored via ASTs, could cut tokens further if region tracking across edits is reliable.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper proposes CORVUS, a trajectory-architecture change for LLM coding agents. Instead of appending file contents as immutable snapshots on each read_file call, CORVUS introduces a sync_file tool that registers files in a synced set and injects their current contents into the prompt before each reasoning cycle. The authors evaluate CORVUS on SWE-PolyBench Verified and a filtered subset of SWE-Bench Pro using four LLMs, reporting 9–50% lower accumulated input tokens, 15–32% shorter final prompts, up to 37% fewer reasoning cycles, and comparable pass@1 rates relative to an append-only baseline. The paper also reports a small compatibility study with reactive context-management methods.

Significance. If the reported effects are reliable, the contribution is practically valuable: a simple, parameter-free architectural change that reduces token cost and latency in long-horizon coding agents without fitted parameters or learned components. The controlled baseline comparison and the breadth across four models and two benchmarks are strengths, as are the task-type and prompt-placement analyses in the appendices. The central idea is plausible and the paper is generally clearly written. However, the evidence for the headline claims has important gaps: the harder benchmark is filtered, the pass-rate and token-reduction results are point estimates without uncertainty quantification, an internal inconsistency exists between Table 3 and Table 6, and no code/data are released. I also considered the stress-test concern that per-cycle re-injection of synced context could be more expensive than append-only trajectories; this does not land as stated, because the append-only baseline also resends all historical file snapshots at every subsequent cycle, so CORVUS replaces multiple snapshots with at most one current copy per file. The paper would still benefit from reporting the token contributio

major comments (5)
  1. [Tables 3 and 6] Internal inconsistency in the main efficiency numbers. For Claude Sonnet 4.5 on SWE-PolyBench Verified with no reactive strategy, Table 6 reports baseline input tokens 1,453,143, cost $4.57, cycles 41.5, and CORVUS input tokens 796,236, cost $2.53, cycles 27.9. Table 3 reports the same model/benchmark pair as baseline input tokens 1,673,331.89, cost $5.27, and CORVUS input tokens 829,579.15, cost $2.62; Table 2 reports baseline cycles 45.03 and CORVUS 28.22. These numbers should agree or the difference must be explained (different runs? different filtering? typo?). Since these tables carry the central claim, the discrepancy is load-bearing.
  2. [Section 6.1] The SWE-Bench Pro evaluation uses a non-random subset: only instances with above-average code changes are sampled, yielding 191 cases. This selection is likely to favor CORVUS because long-horizon tasks with extensive file interactions are precisely where duplicate file reads and stale snapshots are most costly. The paper labels this a stress-test, but it does not report results on the full benchmark or characterize how the selected subset differs from the full distribution. The external-validity claim for SWE-Bench Pro should either be restricted to this subset or supported by full-benchmark results.
  3. [Section 6.4, Table 5] The pass-rate comparison is not statistically supported. Table 5 reports only point estimates of pass@1, aggregated across both benchmarks, with no confidence intervals, no per-benchmark breakdown, and no paired significance test (e.g., McNemar's test). With roughly 573 instances, differences of 1–2 percentage points are plausibly within noise, so the phrase 'maintaining comparable pass rates' is not yet established. Please report per-benchmark pass rates and uncertainty/paired tests.
  4. [Tables 2–4 and Figures 4–6] All efficiency metrics are reported as point estimates. The reductions vary substantially across conditions, and Appendix B itself shows small regressions (e.g., 0.6% token increase for Qwen on SWE-Bench Pro refactoring, 0.6% cycle increase for Qwen on refactoring). Without confidence intervals or per-instance distributions, the headline ranges (9–50%, 15–32%, up to 37%) cannot be distinguished from sampling variation. Please add bootstrapped CIs or equivalent, and report the per-instance distributions.
  5. [Reproducibility] No code, data, prompts, or trajectories are released. The implementation is described as being built on STRANDSAGENTS, and the SWE-Bench Pro filtering step ('filtering invalid commits') is not specified. Given that the contribution is an architectural change with a public-benchmark evaluation, releasing the agent implementation and the filtered task list is necessary for the claims to be independently verified.
minor comments (6)
  1. [Abstract vs Figure 5] The abstract claims 15–32% shorter final prompts, but Figure 5 shows Qwen3-Coder on SWE-Bench Pro dropping from 33.3K to 28.9K tokens, a reduction of about 13.2%. Adjust the claimed range or the figure numbers.
  2. [Table 3] The column headers 'Input Tokens' and 'Output Tokens' should state explicitly whether these are averages per task or totals. The text says 'average input tokens per task' in the abstract, but the table caption is ambiguous. This matters for interpreting the cost numbers.
  3. [Figure 4] The plotted values are difficult to read and some appear to show reductions greater than the claimed 'up to 86%' (e.g., Sonnet 3.7 on PolyBench appears to drop from 2.05 to 0.18, about 91%). Please include exact numbers in the text or a table to avoid over/under-stating the effect.
  4. [Section 6.5] The compatibility study uses one model (Sonnet 4.5) and one benchmark (SWE-PolyBench Verified). The conclusion that CORVUS is complementary to reactive methods should be explicitly qualified as preliminary for this setting.
  5. [Section 6.3, Table 4] Table 4 reports only the average number of synced files, not the byte/token size of the synced context or its cumulative contribution to the prompt. Reporting this would make the efficiency mechanism more transparent and would directly address questions about synchronization overhead.
  6. [Section 7] The paper acknowledges that S never shrinks and lists desync_file as future work. Since this is a structural property of the current design, the limitations section should also note that in very long trajectories with a large synced set, the per-cycle re-injection cost may grow, and that the reported benchmarks may not capture this regime.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: CORVUS's efficiency claims rest on controlled benchmark measurements, not on fitted parameters or self-citation chains.

full rationale

The paper contains no fitted parameters, no data-fitting step, and no derivation that reduces to its own inputs. The core mechanism in Algorithm 1 is an architectural construction: sync_file registers a file and emits a lightweight marker, while Context Sync builds C_t = {(f_j, c_j(t)) : f_j in S_{t-1}} and appends it to the prompt. This guarantees 'at most one version of each file appears in the prompt' by definition, but the paper does not present that guarantee as an empirical prediction; it presents it as a design property. The headline efficiency claims are supported by direct, controlled comparisons against an identical baseline agent on SWE-PolyBench Verified and SWE-Bench Pro (Tables 2-3, Figures 4-7). Critically, the reported total input tokens include the synced-context refresh cost, so the per-cycle re-injection of synced files is not hidden from the measured savings; it is part of the measured totals. The pass-rate comparison (Table 5) is an independent empirical check on task success, not an artifact of the architecture. Self-citations to the authors' prior work appear only in the future-work discussion of AST-based partial synchronization ([27], [29], [30]) and are not load-bearing; the STRANDS AGENTS citation [19] is implementation infrastructure. The paper's own stated limitation that a desync_file tool is future work (Section 7) highlights a possible efficiency risk when the synced set grows, but it is a robustness concern, not a circular step. No statistical significance testing is reported for pass rates, but that is a correctness-risk issue, not circularity. Overall, the derivation chain is self-contained and empirically evaluated.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

Central claim rests on no fitted mathematical constants. The main premises are domain assumptions about agent reasoning and evaluation design: current file state suffices, the MVA baseline is representative, the SWE-Bench Pro filter is fair, and sync overhead is negligible.

assumptions (4)
  • domain assumption Current file contents are sufficient for correct agent reasoning; historical versions are not required.
    CORVUS discards old snapshots by construction (Algorithm 1, C_t = {(f_j, c_j(t))}); if tasks require comparing versions, pass rates could drop.
  • domain assumption The MVA built from 14 surveyed agents is a representative baseline for measuring the architecture's effect.
    Section 5 derives MVA tools from a survey; gains are measured against this custom baseline, not against production systems with their own deduplication or context editing.
  • domain assumption SWE-Bench Pro subset with above-average code changes is representative of long-horizon tasks and not biased toward CORVUS.
    Section 6.1 filters 191 instances; sample selection favors large file interactions where sync gains are largest.
  • domain assumption Context-sync file reads are negligible compared with LLM inference cost.
    Section 6.3 asserts local reads are millisecond-level; this justifies that refresh overhead does not offset savings.

how reviews work

0 comments
Cite this review

Pith. "Pith review of CORVUS: Context Optimization and Reduction Via Underlying Synchronization for LLM Coding Agents." pith.science (2026). https://pith.science/paper/SBAS4KM5

@misc{pith2026260722711,
  author       = {Pith},
  title        = {Pith review of: CORVUS: Context Optimization and Reduction Via Underlying Synchronization for LLM Coding Agents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SBAS4KM5}},
  note         = {Machine review of arXiv:2607.22711}
}
read the original abstract

LLM coding agents operate by constructing trajectories that accumulate reasoning, tool calls, and results to enable multi-step decision-making. However, the conventional append-only trajectory architecture found in practice tightly couples file-read actions with their observations, capturing snapshots that become permanently fixed in the chronological history. As files change through agent edits or concurrent human modifications, these snapshots become stale, causing reasoning errors and causing agents to redundantly re-read files, with each re-read appending yet another copy to the trajectory. To mitigate this, we propose CORVUS, a novel trajectory architecture that decouples file-read actions from their observations by maintaining a synchronized registry of relevant files and injecting only their current contents at each reasoning cycle. This structural change produces significantly lighter-weight trajectories that remain synchronized with the actual codebase state by construction, eliminating redundant file copies and stale snapshots that bloat conventional trajectories. We evaluated CORVUS on SWE- POLYBENCH_VERIFIED and SWE-BENCH PRO across four LLMs, achieving 9-50% reduction in average input tokens per task, 15-32% shorter final prompts, and up to 37% fewer reasoning cycles while maintaining comparable pass rates.

Figures

Figures reproduced from arXiv: 2607.22711 by the authors.

Figure 1
Figure 1. Append-only trajectories accumulate stale snapshots, causing redundant reads and erroneous [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. CORVUS augments the standard Thought–Action–Result loop with a Context Sync phase (orange) that refreshes the agent’s context by fetching the latest contents of all relevant files before each reasoning step. The resulting synced context is appended to each prompt (orange), ensuring every reasoning cycle operates on an up-to-date repository snapshot. Observation 1: Duplicate File Reads. When a file fj is read multipl… view at source ↗
Figure 3
Figure 3. Example: CORVUS on huggingface_transformers-15843. 4.2 Context Synchronization At each reasoning step t, CORVUS performs a context synchronization operation (Line 3) that constructs the synced context: Ct = {(fj , cj (t)) : fj ∈ St−1}. This ensures that the agent always reasons over the current file states {cj (t)} rather than historical snapshots [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 5
Figure 5. Figure 5: Final-request length. Sonnet 3.7 Sonnet 4 Sonnet 4.5 Qwen 480B Model 0 100 200 300 400 500 600 700 Avg. Execution Time (seconds) 247s 322s 455s 234s 194s 230s 315s 182s PolyBench Verified Baseline CORVUS Sonnet 3.7 Sonnet 4 Sonnet 4.5 Qwen 480B Model 0 100 200 300 400 …
Figure 7
Figure 7. Figure 7: Average tool calls per instance [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Prompt-Induced Waste in Coding Agents: Reasoning Structure, Tool Behavior, and End-to-End Cost

    cs.CL 2026-08 conditional novelty 7.0 of 10

    Prompt wording causally changes coding-agent cost: 'consider multiple approaches' multiplies reasoning tokens 2.4-7.4× across six open models with no success gain, confirmed on a frozen holdout.

  2. Prompt-Induced Waste in Coding Agents: Reasoning Structure, Tool Behavior, and End-to-End Cost

    cs.CL 2026-08 conditional novelty 6.0 of 10

    Asking coding agents to compare multiple approaches multiplies reasoning token usage 2.4-7.4x with no measured success gain across six models and two harnesses.

Reference graph

Works this paper leans on

38 extracted references · 7 linked inside Pith · cited by 1 Pith paper

  1. [1]

    Cursor, 2026

    Anysphere. Cursor, 2026. Accessed: 2026-05-05

  2. [2]

    Claude code, 2026

    Anthropic. Claude code, 2026. Accessed: 2026-05-05

  3. [3]

    Kiro, 2026

    Amazon. Kiro, 2026. Accessed: 2026-05-05

  4. [4]

    Huerta, and Hao Peng

    Yufeng Du, Minyang Tian, Srikanth Ronanki, Subendhu Rongali, Sravan Babu Bodapati, Aram Galstyan, Azton Wells, Roy Schwartz, Eliu A. Huerta, and Hao Peng. Context length alone hurts LLM performance despite perfect retrieval. In Christos Christodoulopoulos, Tanmoy Chakraborty, Carolyn Rose, and Violet Peng, editors,Findings of the Association for Computati...

  5. [5]

    Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang

    Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. Lost in the middle: How language models use long contexts.Trans. Assoc. Comput. Linguistics, 12:157–173, 2024

  6. [6]

    Rossi, Seunghyun Yoon, and Hinrich Schütze

    Ali Modarressi, Hanieh Deilamsalehy, Franck Dernoncourt, Trung Bui, Ryan A. Rossi, Seunghyun Yoon, and Hinrich Schütze. Nolima: Long-context evaluation beyond literal matching.CoRR, abs/2502.05167, 2025

  7. [7]

    Context rot: How increasing input tokens impacts llm performance

    Kelly Hong, Anton Troynikov, and Jeff Huber. Context rot: How increasing input tokens impacts llm performance. Technical report, Chroma, July 2025

  8. [8]

    Conversation management - slidingwindowconversationmanager, 2026

    AWS. Conversation management - slidingwindowconversationmanager, 2026. Accessed: 2026-05-05

Show all 38 references
  1. [9]

    Openhands context condensensation for more efficient ai agents, 2025

    OpenHands. Openhands context condensensation for more efficient ai agents, 2025. Accessed: 2026-05-05

  2. [10]

    Dynamic context discovery., 2026

    Anysphere. Dynamic context discovery., 2026. Accessed: 2026-05-05

  3. [11]

    Context engineering for multi-agent LLM code assistants using elicit, notebooklm, chatgpt, and claude code.CoRR, abs/2508.08322, 2025

    Muhammad Haseeb. Context engineering for multi-agent LLM code assistants using elicit, notebooklm, chatgpt, and claude code.CoRR, abs/2508.08322, 2025

  4. [12]

    Nghi D. Q. Bui. Building effective AI coding agents for the terminal: Scaffolding, harness, context engineering, and lessons learned.CoRR, abs/2603.05344, 2026

  5. [13]

    Context editing, 2025

    Anthropic. Context editing, 2025. Accessed: 2026-05-05

  6. [14]

    The complexity trap: Simple observation masking is as efficient as LLM summarization for agent context management.CoRR, abs/2508.21433, 2025

    Tobias Lindenbauer, Igor Slinko, Ludwig Felder, Egor Bogomolov, and Yaroslav Zharov. The complexity trap: Simple observation masking is as efficient as LLM summarization for agent context management.CoRR, abs/2508.21433, 2025

  7. [15]

    Reducing cost of LLM agents with trajectory reduction.CoRR, abs/2509.23586, 2025

    Yuan-An Xiao, Pengfei Gao, Chao Peng, and Yingfei Xiong. Reducing cost of LLM agents with trajectory reduction.CoRR, abs/2509.23586, 2025

  8. [16]

    Inan, Lukas Wutschitz, Yanzhi Chen, Robert Sim, and Saravan Rajmohan

    Minki Kang, Wei-Ning Chen, Dongge Han, Huseyin A. Inan, Lukas Wutschitz, Yanzhi Chen, Robert Sim, and Saravan Rajmohan. ACON: Optimizing context compression for long-horizon LLM agents.CoRR, abs/2510.00615, 2025

  9. [17]

    When agents go astray: Course-correcting SWE agents with PRMs.CoRR, abs/2509.02360, 2025

    Shubham Gandhi, Jason Tsay, Jatin Ganhotra, Kiran Kate, and Yara Rizk. When agents go astray: Course-correcting SWE agents with PRMs.CoRR, abs/2509.02360, 2025. 10

  10. [18]

    SE-Agent: Self-evolution trajectory optimization in multi-step reasoning with LLM- based agents.CoRR, abs/2508.02085, 2025

    Jiaye Lin, Yifu Guo, Yuzhen Han, Sen Hu, Ziyi Ni, Licheng Wang, Mingguang Chen, Hongzhang Liu, Ronghao Chen, Yangfan He, Daxin Jiang, Binxing Jiao, Chen Hu, and Huacan Wang. SE-Agent: Self-evolution trajectory optimization in multi-step reasoning with LLM- based agents.CoRR, a...

  11. [19]

    Strands agents, 2026

    AWS. Strands agents, 2026. Accessed: 2026-05-05

  12. [20]

    Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. SWE-bench: Can language models resolve real-world GitHub issues? In The Twelfth International Conference on Learning Representations, ICLR 2024, 2024

  13. [21]

    Swe-polybench_verified benchmark, 2025

    AWS. Swe-polybench_verified benchmark, 2025. Accessed: 2026-05-05

  14. [22]

    SWE-Bench Pro: Can AI agents solve long- horizon software engineering tasks?CoRR, abs/2509.16941, 2025

    Xiang Deng, Jeff Da, Edwin Pan, Yannis Yiming He, Charles Ide, Kanak Garg, Niklas Lauffer, Andrew Park, Nitin Pasari, Chetan Rane, Karmini Sampath, Maya Krishnan, Srivatsa Kundurthy, Sean Hendryx, Zifan Wang, Vijay Bharadwaj, Jeff Holm, Raja Aluri, Chen Bo Calvin Zhang, Noah J...

  15. [23]

    Claude 3.7 sonnet and claude code, 2025

    Anthropic. Claude 3.7 sonnet and claude code, 2025. Accessed: 2026-05-05

  16. [24]

    Introducing claude 4, 2025

    Anthropic. Introducing claude 4, 2025. Accessed: 2026-05-05

  17. [25]

    Introducing claude sonnet 4.5, 2025

    Anthropic. Introducing claude sonnet 4.5, 2025. Accessed: 2026-05-05

  18. [26]

    Qwen3-coder: Agentic coding in the world, 2025

    Qwen Team. Qwen3-coder: Agentic coding in the world, 2025. Accessed: 2026-05-05

  19. [27]

    Codestruct: Code agents over structured action spaces.arXiv preprint arXiv:2604.05407, 2026

    Myeongsoo Kim, Joe Hsu, Dingmin Wang, Shweta Garg, Varun Kumar, and Murali Krishna Ramanathan. Codestruct: Code agents over structured action spaces.arXiv preprint arXiv:2604.05407, 2026

  20. [28]

    Accessed: 2026-05-05

    Tree-sitter, 2026. Accessed: 2026-05-05

  21. [29]

    Large language models for validating network protocol parsers

    Mingwei Zheng, Danning Xie, and Xiangyu Zhang. Large language models for validating network protocol parsers. In Marina Blanton, William Enck, and Cristina Nita-Rotaru, editors, 2025 IEEE Security and Privacy, SP 2025 - Workshops, San Francisco, CA, USA, May 15, 2025, pages 56...

  22. [30]

    Rfcaudit: AI agent for auditing protocol implementations against RFC specifications

    Mingwei Zheng, Chengpeng Wang, Xuwei Liu, Jinyao Guo, Shiwei Feng, and Xiangyu Zhang. Rfcaudit: AI agent for auditing protocol implementations against RFC specifications. In40th IEEE/ACM International Conference on Automated Software Engineering, ASE 2025, Seoul, Korea, Republ...

  23. [31]

    Fine-grained and accurate source code differencing

    Jean-Rémy Falleri, Floréal Morandat, Xavier Blanc, Matias Martinez, and Martin Monperrus. Fine-grained and accurate source code differencing. In Ivica Crnkovic, Marsha Chechik, and Paul Grünbacher, editors,ACM/IEEE International Conference on Automated Software Engineering, AS...

  24. [32]

    git-diff, 2026

    GIT. git-diff, 2026. Accessed: 2026-05-05

  25. [33]

    Prompt caching, 2025

    OpenAI. Prompt caching, 2025. Accessed: 2026-05-05

  26. [34]

    A survey of on-policy distillation for large language models

    Mingyang Song and Mao Zheng. A survey of on-policy distillation for large language models. arXiv preprint arXiv:2604.00626, 2026

  27. [35]

    On-policy distillation of language models: Learning from self-generated mistakes

    Rishabh Agarwal, Nino Vieillard, Yongchao Zhou, Piotr Stanczyk, Sabela Ramos Garea, Matthieu Geist, and Olivier Bachem. On-policy distillation of language models: Learning from self-generated mistakes. InThe Twelfth International Conference on Learning Representations, ICLR 20...

  28. [36]

    Self-distilled reasoner: On-policy self-distillation for large language models.CoRR, abs/2601.18734, 2026

    Siyan Zhao, Zhihui Xie, Mengchen Liu, Jing Huang, Guan Pang, Feiyu Chen, and Aditya Grover. Self-distilled reasoner: On-policy self-distillation for large language models.CoRR, abs/2601.18734, 2026. 11

  29. [37]

    The landscape of agentic reinforcement learning for llms: A survey.Trans

    Guibin Zhang, Hejia Geng, Xiaohang Yu, Zhenfei Yin, Zaibin Zhang, Zelin Tan, Heng Zhou, Zhong-Zhi Li, Xiangyuan Xue, Yijiang Li, Yifan Zhou, Yang Chen, Chen Zhang, Yutao Fan, Zihu Wang, Songtao Huang, Francisco Piedrahita Velez, Yue Liao, Hongru Wang, Mengyue Yang, Heng Ji, Ju...

  30. [38]

    Kevin P. Murphy. Reinforcement learning: An overview.CoRR, abs/2412.05265, 2024. 12 A Experiments Compute Resources All experiments were conducted on a 16-inch MacBook Pro with an Apple M2 Pro processor and 16 GB of unified memory. LLM inference was performed through AWS Bedro...

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.