new

Get trending papers in your email inbox!

Subscribe

Daily Papers

byAK and the research community

Aug 11

Hidden Licensing Risks in the LLMware Ecosystem

Large Language Models (LLMs) are increasingly integrated into software systems, giving rise to a new class of systems referred to as LLMware. Beyond traditional source-code components, LLMware embeds or interacts with LLMs that depend on other models and datasets, forming complex supply chains across open-source software (OSS), models, and datasets. However, licensing issues emerging from these intertwined dependencies remain largely unexplored. Leveraging GitHub and Hugging Face, we curate a large-scale dataset capturing LLMware supply chains, including 12,180 OSS repositories, 3,988 LLMs, and 708 datasets. Our analysis reveals that license distributions in LLMware differ substantially from traditional OSS ecosystems. We further examine license-related discussions and find that license selection and maintenance are the dominant concerns, accounting for 84% of cases. To understand incompatibility risks, we analyze license conflicts along supply chains and evaluate state-of-the-art detection approaches, which achieve only 58% and 76% F1 scores in this setting. Motivated by these limitations, we propose LiAgent, an LLM-based agent framework for ecosystem-level license compatibility analysis. LiAgent achieves an F1 score of 87%, improving performance by 14 percentage points over prior methods. We reported 60 incompatibility issues detected by LiAgent, 11 of which have been confirmed by developers. Notably, two conflicted LLMs have over 107 million and 5 million downloads on Hugging Face, respectively, indicating potentially widespread downstream impact. We conclude with implications and recommendations to support the sustainable growth of the LLMware ecosystem.

  • 8 authors
·
Feb 11

How Learning Rate Decay Wastes Your Best Data in Curriculum-Based LLM Pretraining

Due to the scarcity of high-quality data, large language models (LLMs) are often trained on mixtures of data with varying quality levels, even after sophisticated data curation. A natural approach to better leverage high-quality data is curriculum-based pretraining, where the model is trained on data sorted in ascending order of quality as determined by a quality metric. However, prior studies have reported limited improvements from such curriculum-based pretraining strategies. This work identifies a critical factor constraining these methods: the incompatibility between the ascending data quality order and the decaying learning rate (LR) schedule. We find that while curriculum-based training substantially outperforms random shuffling when using a constant LR, its advantage diminishes under standard LR decay schedules. Our experiments show this incompatibility can be mitigated by two simple strategies: (1) employing a more moderate LR decay schedule, where the final LR is only moderately smaller than the peak LR, and (2) replacing LR decay with model averaging, i.e., computing a weighted average of the final few checkpoints. By combining these strategies, we improve the average score on a suite of standard benchmarks by 1.64% over random shuffling, without additional data refinement. Validated on 1.5B-parameter models trained over 30B tokens with various data-quality metrics, our findings call for a re-evaluation of curriculum-based LLM pretraining and underscore the potential of co-designing data curricula with optimization methods.

  • 8 authors
·
Nov 24, 2025

RepoRescue: An Empirical Study of LLM Agents on Whole-Repository Compatibility Rescue

Open-source libraries and tools are widely reused, but compatibility maintenance is expensive. Once maintainers leave, useful repositories can stop working as runtimes and dependencies evolve. We study whether LLM agents can adapt old repositories to modern environments, a task we call compatibility rescue. Unlike bug repair, compatibility rescue starts from a repository that worked in its original environment but fails after ecosystem drift. RepoRescue gives agents only the repository and its failing modern environment; the agent must diagnose the failure, locate affected code, and produce a source-code rescue that restores the historical test suite. We build RepoRescue from 193 Python and 122 Java repositories, each verified to pass historically and fail after modernization. We evaluate five deployed agent systems on Python and three on Java. Beyond full-patch pass rate, we rerun patches after removing test-file edits to measure source-only repair, add a runtime-enforced regime that blocks test edits, and validate practical use for repositories whose suites pass after rescue. We find that Claude Code systems sometimes edit failing tests even when prompted not to; with runtime blocking, Kimi still rescues 41.5% of repositories. Systems are complementary: their union reaches 62.7%, exceeding the best single system by 10.9 points. Difficulty concentrates in cross-file coordination: on 14 repositories requiring coordinated whole-codebase changes, GPT-5.2 through Codex passes all 14, while every Claude Code system passes at most two. Finally, a passing suite is only an initial signal: among 34 unmaintained Python candidates whose suites pass after rescue, 22 work in realistic scenarios and 12 pass bug-hunt with patches that address the compatibility failure. RepoRescue benchmarks compatibility rescue with source-only auditing, runtime enforcement, practical validation, and reasoning labels.