ToolSched: Resource-Efficient Tool Scheduling for Shared-Host LLM Agents

T OOL S CHED : R ESOURCE -E FFICIENT T OOL S CHEDUL ING FOR S HARED -H OST LLM AGENTS Shucheng Zou1 , Yuhao Gu1 , Long Chen1 , Zhongchun Zheng1 , BinZe Xie2 , Xianwei Zhang1 SUN YAT-SEN UNIVERSITY (mail.sysu.edu.cn) 2 Independent (independent-researcher.org) 1

arXiv:2611.05269v1 [cs.OS] 3 Nov 2026

A BSTRACT Local LLM agents often work on shared hosts. Unlike multi-tenant cloud clusters, these hosts often have tightly bounded memory, CPU, and I/O resources. Concurrent agents frequently suffer from resource contention, leading to failures such as OOM and reduced resource efficiency. Considering that agents’ resource demands are bursty and shell command delay is imperceptible to agents, there is a huge scheduling opportunity to arrange when and in what order commands are actually executed. Thus, we present ToolSched, a Shell MCP Server for shared local hosts that serves multiple agents and schedules their operations. ToolSched embeds a resource model into the MCP interface: agents estimate resource demands along with command requests. These hints, together with real-time host resource conditions, determine when commands are actually executed. Internally, ToolSched applies a scheduling algorithm to stagger commands, reducing contention and improving resource utilization. Prediction correction and checkpoint-based recovery mitigate estimation bias and resource errors. Our evaluation on Terminal Bench shows that, compared with unscheduled execution, ToolSched improves resource utilization by 148.4% and end-to-end command throughput by 29.4%, demonstrating its effectiveness and practicality.

1

I NTRODUCTION

Large language models (LLMs) have evolved from text generators into multi-turn chat bots (OpenAI, 2022), and are now entering the era of agents (Wang et al., 2024). Unlike previous LLM services that merely generated text, agents connect the thinking ability of LLMs with real-world operations (Yao et al., 2023): they call tools or execute commands to interact with environments, and iteratively revise their behavior to complete complex tasks. This capability enables agents to handle domains such as software engineering (Yang et al., 2024; Jimenez et al., 2024; Wang et al., 2025), data analysis (Chan et al., 2025; Hong et al., 2025), and scientific experimentation (Boiko et al., 2023), where success depends on continuous interaction with stateful execution environments. Nowadays, most ChatGPT-like chat applications already possess some agent capabilities (OpenAI, 2025). They run in the cloud, co-located with inference services, respond to remote users’ dialogue requests, and call predefined tools during responses to improve their answers. Another class of agents runs as standalone applications on local hosts, acting as a bridge between LLM inference services and real-world operational environments: they request external LLM inference services and translate the output tokens into concrete actions like editing files or executing shell commands on behalf of users, such as OpenClaw (OpenClaw Contributors, n.d.), Hermes (Nous Research, n.d.), etc. In such scenarios, it is common to see multiple agents work on the same host. As shown in Figure 1, a workgroup or a small team may share a server used jointly by all members and their agents. Unlike multi-tenant cloud clusters, the computational resources, such as memory, CPU, and disk I/O, are highly constrained. Contention among multiple agents often leads to execution failures due to resource insufficiency, i.e., out-of-memory (OOM) errors, as observed by Zheng et al. (2026). Coordination among agents is demanded to alleviate this resource contention problem. Figure 1 demonstrates that the resource demands during a single agent task can fluctuate dramatically: memory, CPU, and I/O demands may differ by an order of magnitude or more across stages. On the other hand, 1

Team

Agents

Shared host

CPU (Cores)

30.5

24.4

18.3

12.2

…

6.1

0.0 0s

154s

307s

CPU

Human

461s

615s

768s

922s

1075s

1229s

Memory (MB)

3787.6

3030.1

2272.6

…

1515.1

757.5

Memory

Human

0.0 0s

154s

307s

461s

615s

768s

922s

1075s

1229s

Disk I/O (Mbps)

635.8

508.7

381.5

…

254.3

127.2

Disk I/O

Human

0.0 0s

154s

307s

461s

615s

768s

922s

1075s

1229s

Figure 1: A group of team members may share a single host machine, along with their agents. The right part of the figure presents typical observations during a real task, where resource contention may arise due to highly dynamic resource demands.

since an LLM’s inference output is only related to its input, from the agent’s perspective, delaying the execution of a shell command is semantically indistinguishable from the command itself taking longer to execute. This presents a significant scheduling opportunity: by appropriately arranging the execution order and time of shell commands, we can coordinate resource usage among multiple agents without affecting the agents’ final behavior, thus reducing contention, improving resource utilization, and ultimately increasing overall performance. Driven by this idea, we propose ToolSched, a Shell MCP (Model Context Protocol Contributors, 2025) Server running on local shared hosts. ToolSched can serve multiple agents simultaneously and manage their associated Linux containers used for executing shell commands. Unlike previous Shell MCP Servers, ToolSched embeds a resource model into the MCP interface: it requires the agent to estimate the resource requirements when issuing an operation request. These hints, together with the host’s real-time resource conditions, are used to decide when to actually execute the shell command. Internally, ToolSched applies a scheduling algorithm to achieve staggered execution, thereby reducing contention and improving host resource utilization. To mitigate estimation bias and overload challenges, ToolSched also introduces prediction correction and checkpoint-based recovery mechanisms to improve scheduling accuracy and system reliability. In conclusion, the contributions of this paper are as follows: 1. We propose that it is possible to apply proactive shell command scheduling to alleviate resource contention among LLM agents operating on a shared host, without changing the semantics of commands as visible to agents. 2. We introduce ToolSched, a prototype Shell MCP Server that can coordinate multiple agents and, through real-time resource-aware scheduling, achieve accurate and reliable staggered execution of shell commands. 3. Our evaluation on Terminal Bench (Merrill et al., 2026) shows that ToolSched can improve resource utilization by 148.4% and command throughput by 29.4%, compared with unscheduled execution, proving its effectiveness and practicability.

2

BACKGROUND

Local LLM Agents with Shared Hosts. In this paper, we focus on agents deployed on local machines, such as OpenClaw (OpenClaw Contributors, n.d.). These agents serve as a bridge between LLM inference services and local environments, translating LLM outputs into operations like executing shell commands. Just as human members of a team may share a physical server, agents may also operate on the same machine. In such settings, Linux containers (Podman Contributors, n.d.b) are commonly used to prevent different tasks from interfering with one another. As a lightweight isolation mechanism, containers can create independent operating environments while allowing limited sharing of files and other resources among them (Soltesz et al., 2007), making them well suited to the needs of agents. 2

Resource Contention. Since these agents operate on the same host, resource contention inevitably arises. A complete task workflow typically involves executing many shell commands, whose resource demands can differ dramatically (Zheng et al., 2026)—for example, moving a file with mv versus compiling a program with gcc. Because the host’s total resources are limited, when multiple agents operate simultaneously, some commands may fail or run inefficiently due to resource insufficiency (Delimitrou & Kozyrakis, 2013; Kubernetes Contributors, n.d.). Human users usually sense such contention and always can coordinate usage through communication. However, agents generally do not possess such inter-communication ability—an agent running inside a container is, by default, unaware of the existence of agents in other containers. When resource-related failures occur, without awareness of the root cause, the agent may fall into continuous retries, further intensifying resource contention and even causing large-scale workflow blockage. Tool-Call Schedulability. On the other hand, there is substantial scheduling slack among these operations. The fundamental reason is that LLM inference is essentially predicting subsequent output based on input context, and the result of a tool call is merely fed back into the model as new context (Schick et al., 2023); thus, it is almost entirely insensitive to timing. Taking OpenAI’s /chat/completions API as an example, after the model generates a tool call, the agent is only required to include a message with the tool role in its next request (OpenAI, n.d.), while no requirement is imposed on when the next round of conversation is requested. The same principle applies to Shell MCP Servers, which are commonly used by agent applications (such as OpenClaw) to operate remote machines. Therefore, an MCP server can choose to delay command execution or reorder received operations without producing any visible semantic or behavioral change for the agent, which is often indistinguishable from the command itself taking somewhat longer to execute or the network communication being somewhat slower, and therefore does not alter the agent’s workflow or final outcome.

3

D ESIGN AND I MPLEMENTATION

3.1

OVERVIEW Shared Host Local Agents

ToolSched Queue

Agent 1

Sampler CPU

Memory

I/O

Containers …

…

Success

…

Error

POLL

command

MCP

command

Selector Memory Filter

CPU / IO Filter

… Retry

Controller POLL

command

MCP

Agent 3

command

Selected tool calls

Agent 2

Measurements

Checkpoints

…

TRIGGER

… Rollback

…

Figure 2: The architecture of ToolSched. ToolSched works on the shared host, interacts with agents via the MCP protocol and proxies their operations to their respective container environments. ToolSched is a shell MCP server running on the host shared among agents. Just like other shell MCP servers (Model Context Protocol Contributors, 2025), it allows agents to request shell commands and forwards them to the actual execution environment (specifically, containers). However, unlike existing works, ToolSched requires agents to declare the resources needed, including memory, CPU, and disk I/O, along with the shell commands in the MCP, which form the basis for ToolSched to schedule commands. In addition, since containers may have processes that need to run in the background, agents are also required to declare whether the command is idempotent and the recovery commands to set up background processes. 3

Figure 2 shows the internal architecture of ToolSched, which consists of the Queue, Selector, Sampler, and Controller. When agents submit shell commands to ToolSched, these commands are not executed immediately; instead, they are pushed into the Queue for processing. The Selector then polls the entire queue and selects eligible commands to emit to the Controller for execution. The Sampler is in charge of system resource monitoring and provides real-time information for making reasonable selections. The Controller is responsible for dispatching commands to the corresponding container, supervising their execution and handling resource errors. ToolSched classifies the execution result of a command into four categories: 1. Success: The command runs successfully without any error, and then it flows out of ToolSched. 2. Error: The command encounters an error during execution; it also flows out of ToolSched, but with the collected relevant error information. 3. Retry: An idempotent command is aborted due to a resource error; in this case, the command is pushed back into the queue and re-executed once resources become available. 4. Rollback: A non-idempotent command is aborted due to a resource error; in this case, the corresponding container is first rolled back by the Controller, and then the command is pushed back into the queue for re-execution. Only when a command flows out does ToolSched provide feedback to the agents, i.e., by generating MCP responses. For the latter two cases, the agent is completely unaware that the command has been re-enqueued. If the command eventually succeeds, everything is fine; if it ultimately fails, all error information within is collected and returned to the agents. It is believed that the agent is intelligent enough to handle these errors. 3.2

S ELECTOR AND S CHEDULING A LGORITHM

The Selector operates in a polling manner with a polling interval of Tsel . In each poll, it traverses the entire task queue, selects the currently eligible tasks, and emits them to the Controller for execution. Its goal is to maximize system resource utilization and concurrency. So we divide system resources into two categories: hard resources and soft resources. Hard resources currently include only memory, whose runtime constraints must be satisfied (Kubernetes Contributors, n.d.); otherwise, the command cannot run. Soft resources, such as CPU cores and disk I/O, benefit from time-division multiplexing (Linux Kernel Contributors, n.d.). Even if their total demand exceeds the physical hardware limit, they do not prevent execution; they merely slow it down. For these two types of resources, the Selector adopts different scheduling strategies. As shown in Figure 3, for hard resources, the Selector first filters out runnable tasks from the queue. Specifically, the filter first computes the current remaining amount of hard resources (i.e., total amount minus reserved amount). Then it traverses the queue from front to back. If the remaining amount can satisfy the demand Di of the task being visited, the task is considered eligible, and the remaining amount is reduced accordingly. When the traversal finishes, a list of eligible commands is generated. Tool queue

Selector Memory filter

GB cores MB/s

c₁ c₂ c₃

1 1 3

1 2 2

60

Results

c₁

c₂

c₄ 1.8 1 20

c₄

c₁

c₁

c₃

c₂

Dispatch

c₂

c₁

4 cores

3.8 / 4 GB

60 40

CPU / I/O filter

CPU

c₄

I/O

3 > 2 GB

c₁

c₂ c₁ Stop

c₂

free 120 / 100 MB/s

c₂

c₄

c₂

Remaining Mem.

2 GB

CPU

1 core

I/O

20 MB/s over

Figure 3: The Selector consists of two filters for the hard resource (memory) and soft resources. At each poll, all eligible commands are emitted to the Controller for execution. Subsequently, the Selector traverses the eligible list from front to back and emits commands based on soft resource demands. To do so, the Selector first calls the Sampler to provide the current remaining 4

amount R(tn ) for each resource. Then it traverses the eligible list from front to back and similarly deducts the remaining amounts. The difference here is that the traversal stops when any resource’s remaining amount becomes negative, i.e., the total amount of soft resources is allowed to exceed 100% once. This design prevents large tasks from being blocked in the queue for a long time due to insufficient resources. Even if their demand exceeds the total system resources, they still have a chance to be emitted and executed. 3.3

S AMPLER AND P REDICTION C ORRECTION

The Sampler also operates in a polling manner. It interfaces with the operating system (container cgroups) (Linux Kernel Contributors, n.d.) and samples the actual resource usage of each running command. The Sampler mainly serves two purposes: first, it computes the remaining amount for each resource; second, it corrects the agent’s resource demand declarations based on actual observations, thereby mitigating the problem of inaccurate resource demand estimation by the agent. The remaining amount of the hard resource, memory, at time t is calculated as follows: X ′ Rmem (t) = Cmem − Di,mem .

(1)

i∈E(t)

The remaining amount of each soft resource r at time t is calculated as follows: Z tn X 1 ′ Ur (x) dx − Di,r . Rr (t) = Cr − Tsam tn −Tsam

(2)

i∈An (t)

′ Here, Cr is the resource capacity, Di,r is the corrected demand of command i, and Ur (x) is the observed aggregate usage. E(t) contains all currently running commands, while An (t) contains commands admitted in the current window whose reservations have not been released. Tsam = 10 seconds is the window length, and tn is its starting time. The integral is computed by discrete accumulation in practice.

For memory, peak demand is reserved throughout command execution to reduce the risk of exceeding capacity. For CPU and disk I/O, the previous window’s measured average and newly admitted demands jointly stagger heavy commands within a window. At each window boundary, the measured baseline is updated, and estimated demands are accumulated only for commands admitted in the new window. If demand is overestimated, the lower actual usage measured in the next window allows more commands to be admitted. If demand is underestimated, the higher measured usage reduces the budget for new commands. Prior work such as Leopard uses historical CPU and memory usage to estimate invocation resource load for admission control (Cao et al., 2025). Inspired by this, the Sampler records the observed resource peak P and compares it with the resource demand D declared by the agent, thereby correcting future agent resource demand estimates. Specifically, the i-th resource demand Di is corrected to Di′ using the previous k command histories: Di′ = Di ∗ GM



Pi−k Pi−1 Pi−2 , , ..., Di−1 Di−2 Di−k

 (3)

where GM denotes the geometric mean, and k = 256 in this paper. Finally, R(tn ) and Di′ are provided to the Selector as references for selection decisions. 3.4

C ONTROLLER AND C ONTAINER R ECOVERY

The Controller supervises the execution of commands and responds to possible resource errors. To handle such errors, the Controller must be able to roll back and recover the container state. We choose to perform this rollback and recovery at the granularity of a shell command: before each command execution, the Controller creates a checkpoint for the container. Specifically, the container state consists of two parts: the runtime state, i.e., the memory of all running processes, and the file system state, i.e., the container’s rootfs. Unlike previous approaches, we do not checkpoint the memory (i.e., hot checkpoints such as CRIU (Podman Contributors, n.d.a)); instead, we only snapshot the 5

rootfs. The reason is that the memory is bulky and its checkpointing is extremely expensive (Wu et al., 2026). Meanwhile, the agent has error-handling capabilities and can actively restore the runtime state via the recovery commands. With rollback and recovery capabilities in place, when a container experiences a resource error such as OOM, the Controller can reclaim some resources by releasing certain containers. It should be noted that the container experiencing the resource error is not necessarily the one causing the problem; it could be another container that exceeds its resource usage and squeezes others. Therefore, simply stopping the error container may not be sufficient. The Controller also needs to find the container that actually caused the problem and terminate it. Early Linux OOM heuristics combine memory consumption with CPU time and elapsed runtime to favor memory-heavy, short-lived processes for termination (Gorman, 2004). Inspired by this approach, the Controller considers both excess resource demand and the execution time of the current command. Specifically, at the moment t when the resource shortage occurs, for each hard resource we use the following formula to select the container with the largest V (t) and release it: V (t) =

U (t) − Di Ti

(4)

where U (t) is the actual usage for the current command, Di is the declared demand, and Ti is the time the container has been running for this command. For memory, U (t) and Di are both measured as additional demand above the container’s usage immediately before the command. After the command is aborted, the Controller re-enqueues the aborted command and sets its resource demand to max(U (t), 2Di ). If the command is non-idempotent (declared by the agent in the MCP request), the Controller rolls back the container state to the previous checkpoint before re-enqueuing it.

4

E VALUATION

4.1

M ETHODOLOGY

We evaluate ToolSched from three aspects: 1) Its effect on resource utilization, and the improvement in performance brought by the increased utilization (§4.2). 2) Its Sampler’s prediction accuracy (§4.3). 3) The overhead of the Controller’s recovery mechanism (§4.4). 4.1.1

T ESTBED AND W ORKLOAD Table 1: Testbed and Workload Configurations. (b) Workload

(a) Testbed

CPU

Memory

Storage

LLM

Agent

Intel i7-10700 2.9GHz 8C16T

4GB

256GB

GLM-5.2

Terminal Bench Agent

Suite

Avail. / Total Tasks

Terminal Bench 2.0

75 / 89

Tables 1a and 1b show the testbed and workload configurations used in our evaluation. Since the experiments aim to evaluate ToolSched rather than the capabilities of the LLM or the agents, we chose an older and easier version (2.0) of Terminal Bench (Merrill et al., 2026). Even so, out of all 89 tasks, the LLM used still failed to complete 14 tasks within our time limit. Therefore, only the remaining 75 tasks were used. To support experiment replay and enhance reproducibility, we fully recorded the interaction between the agent and ToolSched for each task during the experiment. 4.1.2

M ETRICS AND S CHEMES

Our main concerns are resource utilization and the resulting performance improvement (task completion time). In addition, further evaluations of the Sampler and Controller focus on accuracy and time overhead, respectively, as described in Sections 4.3 and 4.4. We compare ToolSched (toolsched) 6

with two other schemes: 1) no-sched: no scheduling at all, directly running all tasks simultaneously; 2) reserve: statically allocating the peak resource demand of each task, similar to practices in cloud clusters.

Memory (%)

100

no-sched reserve toolsched

80 60 40 20 0

0

20

40

60

80

100

Mean

0

20

40

60

80

100

Mean

0

20

40

60

80

100

Mean

100

CPU (%)

45 30 15 0

Disk I/O (%)

100 5 4 3 2 1 0

Elapsed time (min)

Figure 4: Observed resource usage throughout the entire experiment for the three schemes. It can be seen that toolsched achieves higher resource utilization for memory and CPU, and therefore completes all tasks the fastest. Since the I/O load of Terminal Bench is low and does not constitute a bottleneck, no significant difference is visible in the figure.

Table 2: Pass rate and performance results. Due to resource contention, no-sched fails on 11 tasks in Terminal Bench. By contrast, toolsched can complete all the tasks in less time. Scheme no-sched reserve toolsched

4.2

Pass (Succ. / Total)

Time (s)

Avg. Cmd./s

85.33% (64/75) 100% (75/75) 100% (75/75)

3,392 6,837 3,254

0.462 0.285 0.598

U TILIZATION AND P ERFORMANCE

Figure 4 depicts the resource usage observed for the three schemes throughout the experiment. Due to the resource contention problem, no-sched fails on some tasks, whose resource consumption has already been subtracted in Figure 4. The task pass rate, together with the total runtime and average commands per second, is reported in Table 2. From Figure 4, we can see that compared with no-sched, toolsched achieves a substantial improvement in memory and CPU utilization (mean memory utilization: 15.10%, 13.16%, and 36.67%; mean CPU utilization: 5.24%, 4.59%, and 14.76%, for no-sched, reserve, and toolsched, respectively). This shows that ToolSched achieves effective scheduling coordination, maximizing command concurrency while satisfying resource demands. The three schemes show no significant difference in I/O resource usage, because Terminal Bench has low I/O demand and is far from the testbed bottleneck. 7

In terms of overall performance, toolsched has a runtime similar to that of no-sched (3254 s vs. 3392 s in Table 2). However, it must be noted that since no-sched failed on some tasks, toolsched actually completed more tasks and therefore achieved higher average shell command throughput (0.598 vs. 0.462). On the other hand, due to its overly conservative static resource allocation, reserve took 1.1x longer time than toolsched to complete all tasks, which proves the great space and opportunity for scheduling optimization at the sub-task command granularity. 4.3

P REDICTION ACCURACY

To evaluate ToolSched’s Sampler and its prediction correction mechanism designed in §3.3, we compare the observed real resource usage with ToolSched’s corrected results, along with the agent’s original estimates, as shown in Figure 5. The figure intuitively shows the correction effect of ToolSched—it follows the overall trend of the estimates but is closer to the actual usage. Corrected

4

3.73

8.19k

4

3.44k

Actual 119 100

50 10

1

1

0.5

I/O (MB/s)

100

62.4

0.1

10

1

1 0

66.7

845

1k

CPU (cores)

Memory (MB)

10k

Agent estimate

0.01

0.213

0.137

(a) Memory

1.2e-3

0

0

(b) CPU

0.1

0.333

0

0.0207

0

(c) I/O

Agent

Corrected

Agent

Corrected

Agent

Corrected

MAE

420.36

42.86

MAE

1.034

0.138

MAE

4.068

2.323

RMSE

715.31

198.46

RMSE

1.090

0.308

RMSE

7.374

6.198

Figure 5: Comparison of agent estimates, corrected estimates, and measured resource usage across 1,573 tool calls. Bars show arithmetic means, narrow violins show distributions, and vertical lines span the observed ranges. The axes use a log1p transform, with ticks labeled in the original units. The tables report per-call mean absolute error (MAE) and root mean squared error (RMSE) in the corresponding resource units.

Further data analysis shows that the mean absolute error (MAE) between the agent’s original estimates and actual usage is 420.36 MB (Memory), 1.034 cores (CPU), and 4.068 MB/s (I/O). After calibration, the MAE decreases to 42.86 MB (Memory), 0.138 cores (CPU), and 2.323 MB/s (I/O). Thus, the calibrated estimate provides a substantially more accurate signal for command scheduling than the agent’s original estimation, which proves the necessity of the Sampler. 4.4

R ECOVERY C OST

To evaluate the cost of the Controller’s container recovery mechanism, we further measure the time overhead of container checkpoint/rollback and its occurrence frequency in the actual evaluation. The results are given in Table 3. On average, creating a checkpoint only slows down command execution by 54 ms, which is very small compared to the hundreds- or thousands-of-seconds task-completion time in the experiment. Moreover, since the rollback rate during the entire task process is very low (0.46%, 9/1946), the overhead introduced by container rollback is almost negligible. Overall, the introduction of the 8

container recovery mechanism incurs only a very small overhead but solves the critical and challenging resource overload problem, serving as a stability and reliability fallback in ToolSched. Table 3: Checkpoint and recovery overheads.

5

Metric

Mean

P50

P95

Max

Frequency

Checkpoint latency (s) Checkpoint storage (MB) Recovery latency (s)

0.054 598.8 1.670

0.034 624.0 0.946

0.128 1011.6 6.207

29.69 1408.6 6.207

100% (1946/1946) — 0.46% (9/1946)

R ELATED W ORK

Agent tools have different resource demands across calls, making fixed resource allocations inefficient when multiple agents share a host. Recent work addresses this variability at tool-call or action granularity. One approach controls resource consumption during execution: AgentCgroup (Zheng et al., 2026) places calls in separate cgroups and uses CPU scheduling and memory throttling or freezing to regulate running tools while preserving agent state. Another approach adjusts resource allocation between actions: ARL-Tangram (Xiao et al., 2026) allocates CPU cores when an action executes and releases them afterward. It retains container memory to preserve environment state, a choice suited to its target clusters with relatively abundant memory. These approaches make resource management responsive to individual calls, but differ in which resources they retain and when they intervene. ToolSched focuses on coordinating command execution under the limited memory, CPU, and I/O capacity of a shared host. It checks memory feasibility and schedules command start times according to resource availability, allowing selected commands to wait rather than compete immediately for resources. Resource prediction helps determine which calls can execute concurrently. Leopard (Cao et al., 2025) uses historical average resource usage to guide serverless invocation scheduling, while ALAP (Sinha et al., 2025) predicts requirements from invocation inputs. ToolSched similarly uses historical measurements, but corrects agent-declared demands for stateful shell execution rather than directly predicting demand from previous function invocations. Such estimates can still be inaccurate, making recovery important when resource failures occur. Existing agent recovery systems preserve filesystem and runtime state through checkpoints (Dong et al., 2026; Wu et al., 2026; Zhou et al., 2026). Crab reduces unnecessary checkpointing by observing state changes through eBPF, but still uses CRIU when process state needs to be captured. ToolSched instead uses agent-provided recovery commands to reconstruct runtime state, so it snapshots only the rootfs without capturing process memory. This avoids process-memory checkpointing and restoration, at the cost of relying on recovery commands to re-establish necessary background processes.

6

C ONCLUSION

We presented ToolSched, a Shell MCP server designed to coordinate multiple LLM agents running on a shared, resource-constrained host. Unlike conventional Shell MCP servers, ToolSched embeds a resource model into the MCP interface: agents provide resource estimates when issuing shell commands, and these hints, together with real-time host resource conditions, drive a scheduling algorithm that staggers command execution across agents. To handle estimation bias and overload, ToolSched further incorporates prediction correction and checkpoint-based recovery, improving both scheduling accuracy and system reliability. Our evaluation on Terminal Bench shows that, compared with unscheduled execution, ToolSched improves resource utilization by 142.9%–181.4% and command throughput by 29.4%, demonstrating its effectiveness and practicality. These results suggest that proactive, resource-aware shell command scheduling is a promising direction for enabling efficient and reliable multi-agent execution on shared local hosts. Future work includes extending ToolSched to more diverse workloads, refining the prediction model, and exploring its integration with broader agent ecosystems.

9

R EPRODUCIBILITY S TATEMENT The runtime semantics are specified in Sections 2–3, and the workload and evaluation protocol are reported in Section 4. The artifact will provide the code revision, configuration archive, workload manifest, image digests, execution commands, and event logs. The primary throughput metric and secondary latency metric use the post-preparation execution interval only; preparation, grading, and cleanup are recorded separately. The final submission will add repeated-run statistics.

R EFERENCES Daniil A. Boiko, Robert MacKnight, Ben Kline, and Gabe Gomes. Autonomous chemical research with large language models. Nature, 624:570–578, 2023. doi: 10.1038/s41586-023-06792-0. URL https://www.nature.com/articles/s41586-023-06792-0. Tingjia Cao, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, and Tyler Caraza-Harter. Making serverless pay-for-use a reality with Leopard. In 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI 25), pp. 189–204. USENIX Association, 2025. URL https: //www.usenix.org/conference/nsdi25/presentation/cao. Jun Shern Chan, Neil Chowdhury, Oliver Jaffe, James Aung, Dane Sherburn, Evan Mays, Giulio Starace, Kevin Liu, Leon Maksin, Tejal Patwardhan, Lilian Weng, and Aleksander Madry. ˛ MLEbench: Evaluating machine learning agents on machine learning engineering. In International Conference on Learning Representations, 2025. URL https://arxiv.org/abs/2410. 07095. Christina Delimitrou and Christos Kozyrakis. Paragon: QoS-aware scheduling for heterogeneous datacenters. In Proceedings of the 18th International Conference on Architectural Support for Programming Languages and Operating Systems, pp. 77–88, 2013. doi: 10.1145/2451116.2451125. URL https://csl.stanford.edu/~christos/publications/2013.paragon. asplos.pdf. Yunpeng Dong, Jingkai He, Shiqi Liu, Yuze Hou, Dong Du, Zhonghu Xu, Si Yu, Baochuan Yang, Yubin Xia, and Haibo Chen. DeltaBox: Scaling stateful AI agents with millisecond-level sandbox checkpoint/rollback. arXiv preprint arXiv:2605.22781, 2026. URL https://arxiv.org/ abs/2605.22781v2. Version 2. Mel Gorman. Understanding the Linux Virtual Memory Manager. Prentice Hall, 2004. URL https: //www.kernel.org/doc/gorman/html/understand/understand016.html. Chapter 13 and Appendix M. Sirui Hong, Yizhang Lin, Bang Liu, Bangbang Liu, Binhao Wu, Ceyao Zhang, Danyang Li, Jiaqi Chen, Jiayi Zhang, Jinlin Wang, Li Zhang, Lingyao Zhang, Min Yang, Mingchen Zhuge, Taicheng Guo, Tuo Zhou, Wei Tao, Robert Tang, Xiangtao Lu, Xiawu Zheng, Xinbing Liang, Yaying Fei, Yuheng Cheng, Yongxin Ni, Zhibin Gou, Zongze Xu, Yuyu Luo, and Chenglin Wu. Data Interpreter: An LLM agent for data science. In Findings of the Association for Computational Linguistics: ACL 2025, pp. 19796–19821. Association for Computational Linguistics, 2025. doi: 10.18653/v1/2025. findings-acl.1016. URL https://aclanthology.org/2025.findings-acl.1016/. 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 International Conference on Learning Representations, 2024. URL https://arxiv.org/abs/2310. 06770. Kubernetes Contributors. Resource management for pods and containers. Kubernetes documentation, n.d. URL https://kubernetes.io/docs/concepts/configuration/ manage-resources-containers/. Accessed 2026-09-12. Linux Kernel Contributors. Control group v2. Linux Kernel documentation, n.d. URL https: //docs.kernel.org/admin-guide/cgroup-v2.html. Accessed 2026-09-19. 10

Mike A Merrill, Alexander Glenn Shaw, Nicholas Carlini, Boxuan Li, Harsh Raj, Ivan Bercovich, Lin Shi, Jeong Yeon Shin, Thomas Walshe, E. Kelly Buchanan, Junhong Shen, Guanghao Ye, Haowei Lin, Jason Poulos, Maoyu Wang, Jenia Jitsev, Marianna Nezhurina, Di Lu, Orfeas Menis Mastromichalakis, Zhiwei Xu, Zizhao Chen, Yue Liu, Robert Zhang, Leon Liangyu Chen, Anurag Kashyap, Jan-Lucas Uslu, Jeffrey Li, Jianbo Wu, Minghao Yan, Song Bian, Vedang Sharma, Ke Sun, Steven Dillmann, Akshay Anand, Andrew Lanpouthakoun, Bardia Koopah, Changran Hu, Etash Kumar Guha, Gabriel H. S. Dreiman, Jiacheng Zhu, Karl Krauth, Li Zhong, Niklas Muennighoff, Robert Kwesi Amanfu, Shangyin Tan, Shreyas Pimpalgaonkar, Tushar Aggarwal, Xiangning Lin, Xin Lan, Xuandong Zhao, Yiqing Liang, Yuanli Wang, Zilong Wang, Changzhi Zhou, David Heineman, Hange Liu, Harsh Trivedi, John Yang, Junhong Lin, Manish Shetty, Michael Yang, Nabil Omi, Negin Raoof, Shanda Li, Terry Yue Zhuo, Wuwei Lin, Yiwei Dai, Yuxin Wang, Wenhao Chai, Shang Zhou, Dariush Wahdany, Ziyu She, Jiaming Hu, Zhikang Dong, Yuxuan Zhu, Sasha Cui, Ahson Saiyed, Arinbjörn Kolbeinsson, Christopher Michael Rytting, Ryan Marten, Yixin Wang, Alex Dimakis, Andy Konwinski, and Ludwig Schmidt. Terminal-Bench: Benchmarking agents on hard, realistic tasks in command line interfaces. In The Fourteenth International Conference on Learning Representations, 2026. URL https: //openreview.net/forum?id=a7Qa4CcHak. Model Context Protocol Contributors. Tools. Model Context Protocol specification, revision 2025-06-18, 2025. URL https://modelcontextprotocol.io/specification/ 2025-06-18/server/tools. Nous Research. Hermes Agent. Software repository, n.d. URL https://github.com/ NousResearch/hermes-agent. Accessed 2026-09-19. OpenAI. Introducing ChatGPT. https://openai.com/index/chatgpt/, November 2022. OpenAI. Introducing ChatGPT agent: Bridging research and action. OpenAI launch announcement, 2025. URL https://openai.com/index/introducing-chatgpt-agent/. OpenAI. Function calling. OpenAI API documentation, n.d. URL https://developers. openai.com/api/docs/guides/function-calling. Accessed 2026-09-19. OpenClaw Contributors. OpenClaw. Software repository, n.d. URL https://github.com/ openclaw/openclaw. Accessed 2026-09-19. Podman Contributors. podman-container-checkpoint. Podman documentation, n.d.a. URL https: //docs.podman.io/en/stable/markdown/podman-container-checkpoint. 1.html. Accessed 2026-09-10. Podman Contributors. What is Podman? Podman documentation, n.d.b. URL https://docs. podman.io/en/latest/. Accessed 2026-09-19. Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. In Advances in Neural Information Processing Systems, volume 36, 2023. URL https://proceedings.neurips.cc/paper_files/paper/2023/ hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html. Prasoon Sinha, Kostis Kaffes, and Neeraja J. Yadwadkar. ALAP: Intent-based serverless computing via delayed decision-making. In Proceedings of the 2025 ACM Symposium on Cloud Computing, pp. 831–846, 2025. doi: 10.1145/3772052.3772262. URL https://doi.org/10.1145/ 3772052.3772262. Stephen Soltesz, Herbert Pötzl, Marc E. Fiuczynski, Andy Bavier, and Larry Peterson. Containerbased operating system virtualization: A scalable, high-performance alternative to hypervisors. In Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007, EuroSys ’07, pp. 275–287. Association for Computing Machinery, 2007. doi: 10.1145/1272996. 1273025. URL https://doi.org/10.1145/1272996.1273025. 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 Jirong Wen. A survey on large language model based autonomous agents. Frontiers of Computer Science, 18:186345, 2024. doi: 10. 1007/s11704-024-40231-1. URL https://doi.org/10.1007/s11704-024-40231-1. 11

Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Daniel Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Graham Neubig. OpenHands: An open platform for AI software developers as generalist agents. In International Conference on Learning Representations, 2025. URL https://proceedings.iclr.cc/paper_files/paper/2025/hash/ a4b6ad6b48850c0c331d1259fc66a69c-Abstract-Conference.html. Tianyuan Wu, Chaokun Chang, Lunxi Cao, Wei Gao, and Wei Wang. Crab: A semantics-aware checkpoint/restore runtime for agent sandboxes. arXiv preprint arXiv:2604.28138, 2026. URL https://arxiv.org/abs/2604.28138. Bangjun Xiao, Yihao Zhao, Xiangwei Deng, Shihua Yu, Yuxing Xiang, Huaqiu Liu, Qiying Wang, Liang Zhao, Hailin Zhang, Xuanzhe Liu, Xin Jin, and Fuli Luo. ARL-Tangram: Unleash the resource efficiency in agentic reinforcement learning. arXiv preprint arXiv:2603.13019, 2026. URL https://arxiv.org/abs/2603.13019. John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. SWE-agent: Agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems, volume 37, pp. 50528–50652. Curran Associates, Inc., 2024. doi: 10.52202/ 079017-1601. URL https://papers.nips.cc/paper_files/paper/2024/hash/ 5a7c947568c1b1328ccc5230172e1e7c-Abstract-Conference.html. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations, 2023. URL https://arxiv.org/abs/2210.03629. Yusheng Zheng, Jiakun Fan, Quanzhi Fu, Yiwei Yang, Wei Zhang, and Andi Quinn. AgentCgroup: Understanding and controlling OS resources of AI agents. arXiv preprint arXiv:2602.09345, 2026. URL https://arxiv.org/abs/2602.09345v3. Version 3. Jiecheng Zhou, Qinghao Hu, Peng Sun, Xingcheng Zhang, and Weiming Zhang. Belayer: Efficient fault tolerance for LLM agentic RL training. arXiv preprint arXiv:2608.14635, 2026. URL https://arxiv.org/abs/2608.14635.

12

Related documents

• Flex: Grid-Responsive Provisioning and Scheduling for Elastic Cloud Clusters#1343416
• Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents#259578
• SeedFlood: A Step Toward Scalable Decentralized Fine-Tuning of LLMs#1156287
• Multi-agent LLMs on the Cloud-Edge-IoT Continuum: A Systematic Mapping Study on Architectures, Deployment, and Evaluation#1412943
• Multi-agent LLMs on the Cloud-Edge-IoT Continuum: A Systematic Mapping Study on Architectures, Deployment, and Evaluation#1406554