Pith. sign in

REVIEW 3 major objections 4 minor 8 cited by

AI coding agents are OS-bound and memory-bursty, so container-level resource controls are the wrong granularity; per-tool-call kernel enforcement works better.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · deepseek-v4-flash

2026-08-03 02:53 UTC pith:GXICICNJ

load-bearing objection First systematic OS-level look at coding-agent resource behavior, but the burst-timescale measurement is too coarse to carry the paper's main design argument. the 3 major comments →

arxiv 2602.09345 v3 pith:GXICICNJ submitted 2026-02-10 cs.OS cs.AI

AgentCgroup: Understanding and Controlling OS Resources of AI Agents

classification cs.OS cs.AI
keywords AI coding agentsresource managementcgroupeBPFmemory burstsmulti-tenant isolationtool callsOS-level characterization
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

This paper claims that AI coding agents are not inference-bound: tool calls, container setup, and agent startup together account for 56–74% of end-to-end task time, and memory—not CPU—is what limits how many agents can share a machine. Memory use follows a two-layer pattern: a stable ~185 MB framework baseline plus bursts of up to 4 GB tied to individual tool calls, with peak-to-average ratios up to 15.4× and changes reaching 3 GB/s. Because these bursts are sub-second, unpredictable, and kill-and-restart destroys accumulated LLM context, the paper argues that existing container-level, user-space resource controls are mismatched in granularity, responsiveness, and adaptability. It proposes AgentCgroup, which attaches a cgroup to each tool call, enforces limits in-kernel with eBPF, and lets agents declare resource needs so the system can throttle rather than kill. The evaluation, limited to replayed traces and one agent framework, shows fewer OOM kills and lower high-priority latency under multi-tenant memory pressure.

Core claim

The central discovery is that AI coding agent workloads have a burst-silence resource signature: low, stable baseline usage from the agent framework punctuated by short, high-memory tool-call bursts that are hard to predict and costly to recover from. On a dataset of 144 software-engineering tasks, the paper finds that most latency is OS-level execution, that peak memory can reach 4 GB while average is 264 MB (15.4×), that bursts last 1–2 seconds with change rates up to 3 GB/s, and that the same task varies 1.8× across runs. The authors argue that these properties make standard container-level controls (static limits, PSI-driven user-space killers, history-based autoscaling) fail in three sp

What carries the argument

The load-bearing mechanism is a per-tool-call cgroup hierarchy with in-kernel eBPF enforcement. A transparent bash wrapper intercepts each bash -c invocation, creates an ephemeral child cgroup under the agent's container cgroup, moves the tool process into it, and removes it on exit. This gives resource policies tool-call granularity. Enforcement runs inside the kernel: sched_ext schedules tool calls on the CPU side, and memcg_bpf_ops custom throttle delays implement graduated memory pressure (throttle, then freeze via cgroup.freeze, rather than OOM-kill). Bidirectional intent communication lets the agent declare expected resource needs before a call and receive natural-language feedback aft

Load-bearing premise

The measurements sample CPU and memory at 1-second intervals, yet the paper reports bursts lasting 1–2 seconds with change rates up to 3 GB/s; if the true sub-second peaks are systematically higher than what 1 Hz sampling captures, the peak-to-average ratios, burst durations, and the tool-call burst attribution (98.5%) are overstated.

What would settle it

Resample the same 144 tasks at 10 ms granularity and compare the peak-to-average ratios and burst durations with the 1 Hz measurements; a large discrepancy would show the reported burst statistics are sampling artifacts. Alternatively, run AgentCgroup against live agents (not replayed traces) under the same memory pressure: if the 100%-vs-66% OOM survival advantage does not reproduce with real scheduling and tool-call variability, the isolation claim would fail.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Setting a container memory limit to the observed peak wastes over 90% of allocated memory, since peak demand occurs in less than 2% of sampling time; setting it to the average triggers OOM kills during tool bursts, destroying agent context.
  • Kill-and-restart is disproportionately expensive for agents: cold-starting multi-gigabyte images consumes 31–48% of total task time, and re-running the same task follows a different solution path, so restart is not a reliable fallback.
  • Because memory, not CPU, is the concurrency bottleneck, multi-tenant density of agent instances is set by peak memory allocation, not by CPU utilization, which stays below 36% even at memory-bound concurrency.
  • Retry loops in agent workloads cause progressive memory accumulation (up to 502 MB unreleased), so a limit that fits early iterations can OOM later ones.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The per-tool-call cgroup pattern could generalize beyond coding agents to any stateful, tool-driven workload—for instance, multi-agent orchestration frameworks or notebook-style execution environments where short-lived subprocesses dominate—though the paper does not test those.
  • If the 1-second sampling understates true peaks, the mismatch arguments would only strengthen, since real bursts would be even faster and higher; a 10 ms sampling study would settle which way the bias goes.
  • The intent-declaration channel suggests a division of labor: the LLM predicts and announces resource needs, the kernel enforces them cheaply, and the feedback loop corrects miscalibration—this could evolve into a standard interface between agent frameworks and OS schedulers, but that is speculative.
  • The idea that memory pressure should trigger throttling/freeze rather than OOM kills could apply to other non-checkpointable workloads, such as interactive Jupyter kernels, which also lose in-memory state on kill.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. This paper characterizes OS-level resource dynamics of AI coding agents (Claude Code) executing 144 SWE-rebench tasks with two LLM backends (Haiku cloud API and GLM local GPU). The measurements report that OS/tool execution accounts for 56–74% of end-to-end latency, memory rather than CPU is the concurrency bottleneck, memory peaks reach 15.4× the average and are tool-call-driven, and resource demands are unpredictable across tasks, runs, and models. The paper then identifies three mismatches with existing container resource controls (granularity, responsiveness, adaptability) and proposes AgentCgroup, an eBPF-based controller using hierarchical cgroups aligned with tool-call boundaries, in-kernel enforcement via sched_ext and memcg_bpf_ops, and intent-driven bidirectional adaptation. A proof-of-concept is evaluated by replaying recorded memory traces at 50× speed in a multi-tenant setting, reporting 100% OOM survival and 29% lower high-priority P95 latency under contention.

Significance. If the characterization is confirmed, this would be a timely and useful empirical basis for OS-level resource management of AI agent workloads, quantifying why container-level controls are mismatched and motivating kernel-level enforcement. The open-source prototype and the systematic comparison against serverless, microservice, and batch workloads are assets. However, the central quantitative premises are currently supported by measurements of limited resolution and scale, and the system evaluation does not exercise the proposed adaptive feedback loop. The paper's claims therefore outrun the evidence in several load-bearing places, but the direction is promising and the issues are addressable with additional experiments or careful revision.

major comments (3)
  1. [§3.1, §3.3, §4.2] The workload characterization samples CPU and memory at 1-second intervals (§3.1), but the responsiveness argument depends on burst durations that are at or below the sampling resolution. §3.3 reports that bursts "last 1–2 seconds," while the Abstract and §4.2 refer to "sub-second unpredictable bursts." At 1 Hz Nyquist, a 200 ms and a 900 ms burst are indistinguishable, and the reported 1–2 s durations are exactly the resolution-limited timescale. Moreover, a user-space PSI daemon with tens-of-milliseconds reaction time could plausibly respond within a 1–2 s burst, which undercuts the responsiveness mismatch that motivates in-kernel enforcement via sched_ext and memcg_bpf_ops. The 15.4× peak-to-average ratio is a lower bound under 1 Hz sampling, so the granularity mismatch may be even stronger, but the duration and responsiveness claims need higher-resolution measurements (e.g., 100 ms o
  2. [§6] The system evaluation replays memory traces at 50× acceleration rather than running live agents. This exercises the in-kernel throttle/freeze mechanism but not the central design innovation: the intent-driven bidirectional adaptation loop (§5), where an agent declares resource hints and receives stderr feedback to alter its behavior. Replaying pre-recorded traces also means the controller sees a demand that is not influenced by its own actions, so the reported 29% P95 latency improvement and 100% survival results cannot be extrapolated to live agent workloads. The conclusion acknowledges this limitation, but the paper should present the evaluation as validating only the enforcement path, and ideally include a small live-agent case study.
  3. [§3.4] The cross-run unpredictability finding, which feeds the adaptability mismatch, is based on three executions of a single task (iterative/dvc#777) with execution times 402, 222, and 259 seconds. Three runs of one task are insufficient to establish a general "1.8× across runs" variance or statistical unpredictability. The paper should either report a larger sample of repeated tasks or soften the claim to a motivating observation.
minor comments (4)
  1. [Abstract/§3.2] The OS-level execution share is reported inconsistently: the abstract (v1) says 55–60%, while the full text and §3.2 state 56–74%. Please ensure the numbers and the definition of OS-level share (initialization + tool execution) are consistent throughout.
  2. [§3.3] The burst attribution uses a 300 MB threshold to claim that 98.5% of memory bursts occur during tool calls. This threshold appears arbitrary; a sensitivity analysis (e.g., 200/400 MB) would strengthen the claim.
  3. [§5] The "transparent bash wrapper" and its interception mechanism need more detail: how is bash -c intercepted at the container boundary without modifying the agent framework, and what is the measured overhead per invocation? The text only asserts negligible overhead.
  4. [Fig. 8] The survival-rate and P95-latency results are reported as single bars without error bars or per-run points. Given the 50× trace replay setup, several repetitions would make the comparison more convincing.

Circularity Check

0 steps flagged

No significant circularity: the paper is an empirical measurement plus prototype evaluation, with no fitted parameter called a prediction and no load-bearing self-citation.

full rationale

The paper's central claims are measurement findings from 144 SWE-rebench tasks: phase breakdowns, peak-to-average memory ratios, burst-silence patterns, and cross-task variance. Each is obtained by direct sampling (1-second CPU/memory samples plus tool-call timestamps) and reported as observed values, not as outputs of a fitted model derived from the same values. The proposed system AgentCgroup is a separate prototype; Section 6 evaluates it by replaying measured memory traces from Section 3, which is a standard workload-replay methodology, not a prediction of the measured quantities. The only self-citations (AgentSight [39], Kgent [40]) appear as background/implementation ancestry ('extending Agentsight') and are not used to establish the characterization or to justify the mismatch argument. The 1 Hz sampling limitation and the internal tension between 'sub-second' (intro) and '1-2 s' (Section 3.3) burst durations are empirical validity concerns about temporal resolution, not circular reductions: the reported durations are not forced by construction to equal the sampling interval in a way that makes the conclusion equivalent to its input. No step in the derivation chain reduces by definition to its own input.

Axiom & Free-Parameter Ledger

3 free parameters · 3 axioms · 0 invented entities

The paper introduces no new physical or conceptual entities. The load-bearing assumptions are measurement fidelity (1 Hz sampling), the behavioral assumption that agents will honor resource hints, and the availability of experimental kernel patches.

free parameters (3)
  • burst definition thresholds (CPU 20%/s, memory 50 MB/s) = 20%/s CPU; 50 MB/s memory
    Hand-chosen thresholds defining a 'burst' in Fig. 7; affect reported burst counts but not the peak-to-average ratio.
  • memory burst attribution threshold = 300 MB (~1.6× baseline)
    Used in §3.3 to attribute bursts to tool calls; definitional choice influencing the 98.5% statistic.
  • trace replay acceleration factor = 50×
    Chosen for the §6 evaluation; accelerating time may not preserve realistic memory-pressure timing and limits generalizability.
axioms (3)
  • domain assumption 1 Hz sampling adequately characterizes resource dynamics
    §3.1 samples at 1-second intervals; the paper uses this to attribute 98.5% of memory bursts to tool calls and to estimate burst durations of 1–2 s, which is at the Nyquist limit for 1 Hz sampling.
  • domain assumption Agents can understand and adapt to resource feedback
    §1 and §5 assume agents respond to resource hints (AGENT_RESOURCE_HINT) and stderr feedback to reconstruct execution strategies; this is untested in the evaluation.
  • domain assumption memcg_bpf_ops hooks will be available in production kernels
    §5/§6 rely on RFC patches under upstream review; the prototype cannot run on stock kernels.

pith-pipeline@v1.3.0-alltime-deepseek · 12146 in / 10015 out tokens · 91659 ms · 2026-08-03T02:53:26.586251+00:00 · methodology

0 comments
read the original abstract

AI agents are increasingly deployed in multi-tenant cloud environments, where they execute diverse tool calls within sandboxed containers, each call with distinct resource demands and rapid fluctuations. We present a systematic characterization of OS-level resource dynamics in sandboxed AI coding agents, analyzing 144 software engineering tasks from the SWE-rebench benchmark across two LLM models. Our measurements reveal that (1) OS-level execution (tool calls, container and agent initialization) accounts for 55-60% of end-to-end task latency; (2) memory, not CPU, is the concurrency bottleneck; (3) memory spikes are tool-call-driven with a up to 15.4x peak-to-average ratio; and (4) resource demands are highly unpredictable across tasks, runs, and models. Comparing these characteristics against serverless, microservice, and batch workloads, we identify three mismatches in existing resource controls: a granularity mismatch (container-level policies vs. tool-call-level dynamics), a responsiveness mismatch (user-space reaction vs. sub-second unpredictable bursts), and an adaptability mismatch (history-based prediction vs. non-deterministic stateful execution). We propose AgentCgroup, an intent-driven eBPF-based resource controller that exploits agents ability to declare resource needs and reconstruct execution strategies, using hierarchical cgroup structures aligned with tool-call boundaries, in-kernel enforcement via sched_ext and memcg_bpf_ops, and runtime-adaptive policies. Preliminary evaluation demonstrates improved multi-tenant isolation and reduced resource waste. AgentCgroup is open-source at https://github.com/eunomia-bpf/agentcgroup

Figures

Figures reproduced from arXiv: 2602.09345 by Andi Quinn, Jiakun Fan, Quanzhi Fu, Wei Zhang, Yiwei Yang, Yusheng Zheng.

Figure 1
Figure 1. Figure 1: Task execution time distribution (a) and execution [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 4
Figure 4. Figure 4: Docker image size distribution (a) and aggregated [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figure 3
Figure 3. Figure 3: Tool time proportion distribution (a) and tool call [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 5
Figure 5. Figure 5: Resource usage time series: Haiku agent executing [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Resource usage time series: GLM agent executing [PITH_FULL_IMAGE:figures/full_fig_p004_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Resource change rate distribution (CPU and mem [PITH_FULL_IMAGE:figures/full_fig_p004_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: BPF enforcement evaluation with real agent trace [PITH_FULL_IMAGE:figures/full_fig_p006_8.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 8 Pith papers

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

  1. Sandlock: Confining AI Agent Code with Unprivileged Linux Primitives

    cs.CR 2026-05 unverdicted novelty 7.0

    Sandlock provides an unprivileged Linux process sandbox for AI agents by compiling static policies into kernel rules and delegating runtime decisions to a narrow supervisor.

  2. Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes

    cs.OS 2026-04 unverdicted novelty 7.0

    Crab bridges the agent-OS semantic gap with an eBPF inspector, turn-aligned coordinator, and host engine to deliver 100% recovery correctness while cutting checkpoint traffic up to 87% and adding under 2% overhead.

  3. FAVA: Formal Authorization for Verified Agents with Evidence-Backed Permission Graphs

    cs.CR 2026-07 conditional novelty 6.0

    FAVA enforces agent permissions by lowering LLM-parsed tasks into evidence-backed graphs checked by an SMT solver, matching benchmark ground truth on 90.5% of 801 decisions.

  4. ParaCell: Paravirtualized Secure Containers with Lightweight Intra-Container Isolation and Intent-Driven Memory Management

    cs.OS 2026-05 unverdicted novelty 6.0

    ParaCell reduces latency by up to 88% in nested setups and saves 35.6% memory on agent workloads via MPK XGates and intent-based Pager compared to PVM, RunV, and HyperAlloc.

  5. Towards an Agent Operating System - Lessons from Classical and Cloud OS

    cs.AI 2026-07 conditional novelty 5.0

    Agentic systems need an Agent-OS of thirteen OS/Cloud-OS-derived primitives with precise platform-enforceable semantics before portable production adoption is possible.

  6. VIGIL: Runtime Enforcement of Behavioral Specifications in AI Agent Skills

    cs.CR 2026-06 unverdicted novelty 5.0

    VIGIL introduces a policy language and symbolic evaluation rules to enforce context-aware behavioral specifications on LLM agent traces, achieving over 95% recall and under 10% false positives on real tasks.

  7. Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents

    cs.CR 2026-06 unverdicted novelty 5.0

    PORTICO is a revocable capability reference monitor for coding agents that enforces task contracts via grant-invoke-closure lifecycles and rejects post-closure reuses while preserving task success.

  8. Agentic AI Workload Characteristics

    cs.DC 2026-05 unverdicted novelty 5.0

    Agentic workloads with context caching become decode-dominated with high KV-cache reuse and show tool use shifting from early read/explore to later execute/write phases.

Reference graph

Works this paper leans on

42 extracted references · 7 linked inside Pith · cited by 8 Pith papers

  1. [1]

    Anthropic. 2026. How Claude Code Works. Claude Code Documentation. https://code.claude.com/docs/en/how-claude-code-works (accessed 2026-02-09)

  2. [2]

    Anthropic. 2026. Securely Deploying AI Agents. Claude API Documentation (Agent SDK Guides). https://platform.claude.com/docs/en/agent-sdk/secure- deployment (accessed 2026-02-09)

  3. [3]

    Apple. 2026. Xcode 26.3 unlocks the power of agentic coding. Apple News- room. https://www.apple.com/newsroom/2026/02/xcode-26-point-3-unlocks- the-power-of-agentic-coding/ (accessed 2026-02-09)

  4. [4]

    Zain Asgar, Michelle Nguyen, and Sachin Katti. 2025. Efficient and Scalable Agentic AI with Heterogeneous Systems. arXiv preprint arXiv:2507.19635

  5. [5]

    Ibragim Badertdinov, Alexander Golubev, Maksim Nekrashevich, Anton Shevtsov, Simon Karasik, Andrei Andriushchenko, Maria Trofimova, Daria Litvintseva, and Boris Yangel. 2025. SWE-rebench: An Automated Pipeline for Task Collec- tion and Decontaminated Evaluation of Software Engineering Agents. arXiv preprint arXiv:2505.20411. Dataset: https://huggingface.c...

  6. [6]

    Teofil Bodea, Masanori Misono, Julian Pritzi, Patrick Sabanic, Thore Sommer, Harshavardhan Unnibhavi, David Schall, Nuno Santos, Dimitrios Stavrakakis, and Pramod Bhatotia. 2025. Trusted AI Agents in the Cloud. arXiv preprint arXiv:2512.05951

  7. [7]

    Jinyuan Chen, Jiuchen Shi, Quan Chen, and Minyi Guo. 2025. Kairos: Low-latency Multi-Agent Serving with Shared LLMs and Excessive Loads in the Public Cloud. arXiv preprint arXiv:2508.06948

  8. [8]

    Cognition. 2024. Introducing Devin, the first AI software engineer. Cognition Blog. https://cognition.ai/blog/introducing-devin (accessed 2026-02-09)

  9. [9]

    Eli Cortez, Anand Bonde, Alexandre Muzio, Mark Russinovich, Marcus Fontoura, and Ricardo Bianchini. 2017. Resource Central: Understanding and Predicting Workloads for Improved Resource Management in Large Cloud Platforms. In Proceedings of the 26th Symposium on Operating Systems Principles (SOSP). ACM, 153–167

  10. [10]

    Cursor Team. 2026. Best practices for coding with agents. Cursor Blog. https: //cursor.com/blog/agent-best-practices (accessed 2026-02-09)

  11. [11]

    David Dworken and Oliver Weller-Davies. 2025. Beyond Permission Prompts: Making Claude Code More Secure and Autonomous. Anthropic Engineering Blog. Published Oct 20, 2025. https://www.anthropic.com/engineering/claude- code-sandboxing (accessed 2026-02-09)

  12. [12]

    GitHub. 2026. About GitHub Copilot coding agent. GitHub Documenta- tion. https://docs.github.com/en/copilot/concepts/agents/coding-agent/about- coding-agent (accessed 2026-02-09)

  13. [13]

    Google. 2025. Jules, Google’s asynchronous AI coding agent, is out of public beta. Google Blog. https://blog.google/innovation-and-ai/models-and-research/ google-labs/jules-now-available/ (accessed 2026-02-09)

  14. [14]

    Tejun Heo. 2015. Control Group v2. Linux Kernel Documentation. https: //docs.kernel.org/admin-guide/cgroup-v2.html

  15. [15]

    Tejun Heo, David Vernet, and Josh Don. 2023. Extensible Scheduler Class. Linux Kernel Documentation. https://docs.kernel.org/scheduler/sched-ext.html

  16. [16]

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

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R. Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. InInternational Conference on Learning Representations (ICLR). Oral. arXiv:2310.06770

  17. [17]

    Jiin Kim, Byeongjun Shin, Jinha Chung, and Minsoo Rhu. 2025. The Cost of Dynamic Reasoning: Demystifying AI Agents and Test-Time Scaling from an AI Infrastructure Perspective. arXiv preprint arXiv:2506.04301

  18. [18]

    Kubernetes Community. 2024. In-Place Update of Pod Resources. Kubernetes Enhancement Proposals. https://github.com/kubernetes/enhancements/tree/ master/keps/sig-node/1287-in-place-update-pod-resources

  19. [19]

    Kubernetes Community. 2024. Pod Quality of Service Classes. Kubernetes Documentation. https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

  20. [20]

    Kubernetes Community. 2024. Vertical Pod Autoscaler. Kubernetes Docu- mentation. https://github.com/kubernetes/autoscaler/tree/master/vertical-pod- autoscaler

  21. [21]

    Marco Laju, Donghyun Son, Saurabh Agarwal, Nitin Kedia, Myungjin Lee, Jayanth Srinivasa, and Aditya Akella. 2026. Nalar: An Agent Serving Framework. arXiv preprint arXiv:2601.05109

  22. [22]

    Hanchen Li, Qiuyang Mang, Runyuan He, Qizheng Zhang, Huanzhi Mao, Xi- aokun Chen, Hangrui Zhou, Alvin Cheung, Joseph Gonzalez, and Ion Stoica

  23. [23]

    Linux Kernel Community. 2024. eBPF Verifier. Linux Kernel Documentation. https://docs.kernel.org/bpf/verifier.html

  24. [24]

    Linux Kernel Community. 2024. libbpf Overview. Linux Kernel Documentation. https://docs.kernel.org/bpf/libbpf/libbpf_overview.html

  25. [25]

    Kai Mei et al . 2024. AIOS: LLM Agent Operating System. arXiv preprint arXiv:2403.16971

  26. [26]

    Meta/Facebook. 2024. oomd: A Userspace Out-of-Memory Killer. GitHub. https: //github.com/facebookincubator/oomd

  27. [27]

    Hongqiu Ni, Jiabao Zhang, Guopeng Li, Zilong Wang, Ruiqi Wu, Chi Zhang, and Haisheng Tan. 2025. Astraea: A State-Aware Scheduling Engine for LLM-Powered Agents. arXiv preprint arXiv:2512.14142

  28. [28]

    OpenAI. 2025. Introducing Codex. OpenAI. https://openai.com/index/ introducing-codex/ (accessed 2026-02-09)

  29. [29]

    Krzysztof Rzadca, Pawel Findeisen, Jacek Swiderski, Przemyslaw Zych, Prze- myslaw Broniek, Jarek Kusmierek, Pawel Nowak, Ben Strack, Piotr Witusowski, Steven Hand, and John Wilkes. 2020. Autopilot: Workload Autoscaling at Google Scale. InProceedings of the Fifteenth European Conference on Computer Systems (EuroSys). ACM

  30. [30]

    Mohammad Shahrad, Rodrigo Fonseca, Íñigo Goiri, Gohar Chaudhry, Paul Batum, Jason Cober, Esdras Laureano, Christos Trespass, Mark Russinovich, and Ricardo Bianchini. 2020. Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider. InProceedings of the 2020 USENIX Annual Technical Conference (ATC). USENIX, 205–218

  31. [31]

    systemd Project. 2024. systemd-oomd.service — A Userspace Out-Of-Memory (OOM) Killer. systemd Documentation. https://www.freedesktop.org/software/ systemd/man/systemd-oomd.service.html

  32. [32]

    Abhishek Verma, Luis Pedrosa, Madhukar Korupolu, David Oppenheimer, Eric Tune, and John Wilkes. 2015. Large-Scale Cluster Management at Google with Borg. InProceedings of the Tenth European Conference on Computer Systems (EuroSys). ACM

  33. [33]

    Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Ji-Rong Wen. 2024. A Survey on Large Language Model Based Autonomous Agents.Frontiers of Computer Science18, 6 (2024), 186345. doi:10.1007/s11704- 024-40231-1

  34. [34]

    Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H

    Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Gra- ham Neubig. 2025. OpenHands: An Open Platform for...

  35. [35]

    Johannes Weiner. 2018. PSI — Pressure Stall Information. Linux Kernel Docu- mentation. https://docs.kernel.org/accounting/psi.html

  36. [36]

    Johannes Weiner, Niket Agarwal, Dan Schatzberg, Leon Yang, Hao Wang, Blaise Sanouillet, Bikash Sharma, Tejun Heo, Mayank Jain, Chunqiang Tang, and Dim- itrios Skarlatos. 2022. TMO: Transparent Memory Offloading in Datacenters. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (...

  37. [37]

    Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press

    John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer Inter- faces Enable Automated Software Engineering. InAdvances in Neural Information Processing Systems (NeurIPS). arXiv:2405.15793

  38. [38]

    Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. InInternational Conference on Learning Representations (ICLR)

  39. [39]

    Yusheng Zheng, Yanpeng Hu, Tong Yu, and Andi Quinn. 2025. AgentSight: System-Level Observability for AI Agents Using eBPF. arXiv preprint arXiv:2508.02736

  40. [40]

    Yusheng Zheng, Yiwei Yang, Maolin Chen, and Andrew Quinn. 2024. Kgent: Kernel Extensions Large Language Model Agent. InProceedings of the ACM SIGCOMM 2024 Workshop on eBPF and Kernel Extensions (eBPF ’24). ACM, 30–36. doi:10.1145/3672197.3673434 Yusheng Zheng, Jiakun Fan, Quanzhi Fu, Yiwei Yang, Wei Zhang, and Andi Quinn

  41. [41]

    Hui Zhu. 2026. mm: memcontrol: Add BPF hooks for memory controller. LWN.net. RFC PATCH bpf-next v3 00/12, Jan 23 2026. https://lwn.net/Articles/ 1055698/

  42. [2025]

    arXiv preprint arXiv:2511.02230

    Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live. arXiv preprint arXiv:2511.02230