Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon

M ETAL S ANDBOX : I SOLATED E XECUTION AND C OMMAND S CHEDULING FOR GPU C ODING AGENTS ON A PPLE S ILICON Haozhe Wang 1 2 3 Lina Chen 3 Fanqi Wan 3 Qi Han 3 Yinmin Zhang 3 Zheng Ge 3 Daxin Jiang 3 Junchi Yan 1

arXiv:2611.17294v1 [cs.LG] 12 Nov 2026

1

Shanghai Jiaotong University

2

Beijing Zhongguancun Academy

3

StepFun

A BSTRACT On-device inference requires kernels that make effective use of local accelerators. Efficient training and evaluation of models that generate Apple Metal kernels benefit from native macOS tools and concurrent agent sessions. These sessions alternate between model requests, development commands, and GPU execution, leaving GPU capacity idle for much of a rollout. We present Metal Sandbox, infrastructure that combines restricted per-instance file access, native command execution, and command-level scheduling across interconnected Macs. Each agent retains its workspace and private development environment. Parallel commands can run concurrently, while serial commands share one execution slot per node; eligible waiting commands can migrate to available Macs and return results to the original agent. Integration with Harbor supports task execution, automatic verification, and rollout collection through a common workflow. Controlled experiments on four Mac mini M4 nodes achieve 1.68×– 2.05× gains in command throughput under concentrated demand. Sixteen static agent traces give an estimated 2.14× sustained-throughput gain for four sessions per node versus one, assuming continuously replenished sessions and unchanged mean durations. Replaying these measured traces under dynamic scheduling reduces mean tool waiting by 18.8% and batch elapsed time by 22.3%, assuming unchanged phase durations. Metal Sandbox and its Harbor integration are open-source on GitHub.* 1

I NTRODUCTION

Efficient on-device inference requires kernels that use local accelerators well. Apple’s on-device foundation model illustrates this need for local inference optimization (Gunter et al., 2024). Metal provides a native GPU API and shading language for both M-series chips in Macs and A-series chips in iPhones (Apple Inc., 2014; 2026). These processors combine high compute performance with energy-efficient designs (Apple Inc., 2024a;b); unified memory also supports CPU/GPU workflows in frameworks such as MLX (Hannun et al., 2023). This combination makes Metal important for on-device computation. Improving models’ ability to generate efficient Metal kernels can support applications across Apple’s desktop and mobile devices. Language models can generate and iteratively improve GPU kernels using compiler, correctness, and performance feedback. KernelBench provides evaluation tasks for CUDA and GPU-DSL generation (Ouyang et al., 2025). KernelGYM, introduced with Dr. Kernel, supplies distributed GPU evaluation and multi-turn data collection for reinforcement learning (Liu et al., 2026), while Metal-Sci studies auto*

github.com/WangHaoZhe/metal-sandbox github.com/WangHaoZhe/harbor

matic search over native Metal scientific kernels (Gallego, 2026). Supporting broader Metal evaluation and training requires interactive agents to prepare dependencies, edit programs, compile candidates, and obtain feedback across concurrent rollouts. These agents alternate between model requests, source editing, CPU preparation, and candidate execution. Figure 1 measures one metal_nbody session (task specification in Appendix D) without competing agents. Apple Instruments’ Metal System Trace (Apple Inc., n.d.) records 44.0 seconds of GPU activity over 31.6 minutes, or 2.32% of the session. Most of the session is spent outside GPU execution. We therefore schedule individual commands across concurrent sessions to use idle GPU capacity, reduce tool waiting, and shorten rollout collection. Commands that run or time GPU work enter a serial queue on each Mac, while parallel commands, such as file inspection and editing, proceed without waiting for that queue. This allows commands to overlap while coordinating participating GPU timing commands. Per-node serialization alone, however, leaves queues unbalanced across Macs. In sixteen concurrent sessions on four Macs (Section 5.6), tool waiting accounts for 21.0 of the 45.1 minutes in an average session. Although each Mac hosts four sessions, sessions on the busiest Mac wait 32.7

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon

Candidate GPU activity

Model request Serial tool

Parallel tool Non-Agent activity

Table 1. Execution environments for Metal agents. ✓: supported; ×: unsupported; △: partial. Docker denotes standard Linux containers; macOS VMs expose virtual Metal graphics.

Agent phases

100%

Capability

Candidate GPU active: 2.32%

50% 0% 0

5

10 15 20 Elapsed time (minutes)

25

30

Figure 1. One metal_nbody agent session without competing sessions. GPU activity totals 44.0 seconds (2.32%) over 31.6 minutes. Agent phases and GPU activity share the session timeline. The GPU curve is the active fraction of each one-second window; its area gives the total active time. Gray denotes activity outside the recorded model and tool phases.

macOS programs Host OS access Filesystem isolation Native Apple GPU access GPU timing coordination Cross-Mac scheduling

We present Metal Sandbox, native execution infrastructure that combines restricted instance file access with command scheduling across interconnected Macs. Each agent receives an instance, a workspace, and a private development HOME. Commands run in Apple’s App Sandbox, an operating-system mechanism that restricts an application’s access to files and other resources (Apple Inc., 2017), with access to the instance’s files and required system tools. Our Harbor integration supports Claude Code, Codex, and miniSWE-agent, enabling configured tasks, automatic verifica-

Metal bare macOS VM macOS Sandbox

× × ✓ × × ×

✓ × ✓ △ × ×

✓ ✓ × ✓ × ×

✓ ✓ ✓ ✓ ✓ ✓

tion, and trajectory collection through the same evaluation workflow (Harbor contributors, 2026; SWE-agent contributors, 2026). The paper contributes: 1. A native multi-agent execution model with restricted per-instance file access, ordinary development commands, and per-node serial queues, integrated with Harbor for task execution and rollout collection.

minutes on average, compared with 13.3 minutes on the least busy Mac. Waiting serial commands can therefore migrate to Macs with free execution slots. Concurrent development also requires separate instance files and a usable native tool environment. Agents need shell commands, compilers, and Metal programs without unrestricted write access to the host user’s files. Table 1 compares these environments. Docker containers and macOS VMs provide separate filesystems; bare macOS has no builtin file isolation between agent sessions. Standard Docker Desktop containers execute inside a Linux VM (Docker Inc., 2024), and Docker Desktop’s GPU support requires Windows with the WSL 2 backend (Docker Inc., 2021). macOS VMs provide a guest environment and virtual Metal graphics (Apple Inc., 2022). Bare macOS provides native execution, with file restrictions and timing coordination left to the application. KernelGYM already serializes evaluation tasks per GPU, but its evaluation backend targets CUDA (Liu et al., 2026). Interactive Metal rollouts additionally need persistent native workspaces and scheduling of individual tool commands.

Docker

2. Cross-Mac command migration that shares instance development files, coordinates execution at source and target nodes, and returns results to the original agent. 3. A four-Mac evaluation of cluster scaling, concentrated demand, and migration cost, plus scheduling replay that holds sixteen measured agent trajectories fixed.

2

N ATIVE E XECUTION AND I NSTANCE I SOLATION

2.1

Native Command Interface

An instance provides a workspace and development environment for an agent session, which repeatedly submits tool commands. Its owner node is the Mac hosting that session; an execution node is the Mac currently running one of its commands. During migration, the source node holds the waiting command, and the target node receives it. Each managed command includes the submitted program or shell expression and its child processes. The management service executes candidate builds and runs directly on host macOS in an App Sandbox process; ordinary child processes inherit its sandbox policy. Agents use native shell commands, installed compilers, SDKs, and Metal through this interface. 2.2

Instance Filesystem Isolation

The runtime maps HOME and shell ~ to the instance’s development directory and starts commands in its workspace. Agents can create and modify files in that workspace, private HOME, and temporary directories. Required system

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon

tools, SDKs, and configured development-tool directories remain accessible. Each sandbox process receives access to its own instance’s development files, without access to the host user’s entire home directory or other instances’ files. The following commands were executed in one instance using native /bin/sh and /bin/mkdir. The first creates a directory in the instance’s HOME; the second attempts the same operation in the host user’s home. $ mkdir ~/demo [ALLOWED; exit 0] $ mkdir /Users/sandbox1/demo [DENIED; exit 1] mkdir: /Users/sandbox1/demo: Operation not permitted

3.1

When a request concerns another Mac (for example, placing an instance on a worker or migrating a waiting command), the cluster controller connects over SSH and invokes that node’s Metal Sandbox CLI. The remote service handles instance operations, file transfer, and execution-status queries; candidate commands run in its sandbox processes. The controller records which node owns each instance and which node executes each command, together with migration progress. These records are saved to disk so later requests can find the same instance or command. For example, after a command migrates from Mac mini #B to #D, requests for its output are sent to #D while the agent remains on #B. 3.2

This per-instance filesystem isolation lets an agent edit, build, and test its own project while rejecting writes to host files outside the granted scope and to other instances’ workspaces. 2.3

Migration starts a new process on the target node for a waiting command; it does not move a running process, live Metal buffers, or GPU state between Macs. Shared storage does not coordinate simultaneous writes by different commands. Commands that require local GUI state, sockets, running processes, unshared files, or device-specific state remain on their owner node.

3

S YSTEM A RCHITECTURE

Figure 2 shows how commands, results, and shared files move through the system. Figure 3 shows the four-Mac deployment, with Harbor and the cluster controller on the management node. The controller accepts cluster requests and records instance and command locations. Each node runs its own scheduler and sandbox processes, and checks saved execution state at startup to identify unfinished work left by an unexpected shutdown before accepting new work. Migrated commands execute through the target node’s normal management service.

Instance Placement

For node n, let An be the observed number of active instances and Rn the number of instances assigned there but still being created. Automatic placement selects from the eligible node set E: n∗ = arg min(An + Rn ).

Shared Files for Command Migration

For dynamic scheduling, each instance uses its own shared workspace and development HOME, mounted at the same absolute paths on nodes in its scheduling pool. This makes the instance’s files available wherever its commands execute, while different instances retain separate directories. Temporary files, runtime binaries, and execution logs remain local. Identity markers detect shared directories that are missing, replaced, or mounted incorrectly. Toolchains, dependencies, and permissions must be compatible across nodes.

Cross-Node Communication and Location Tracking

n∈E

(1)

An eligible node must have a compatible service version, available instance capacity, no pending recovery, and a thermal state below critical. During batch creation, the controller updates the projected counts after each assignment so successive instances do not all use the same initial counts. Instance count balances concurrent sessions but does not predict how much GPU work each session will submit. Command migration reduces queue imbalance that remains after instance placement. 3.3

Per-Node Command Scheduling

The default allowlist includes common file and text commands, compilers, and build tools; Appendix C gives the complete list. Matching commands run in parallel; other commands enter the serial queue. The administrator can edit this list or use a blocklist, where matching commands run serially and others run in parallel. Rules match executable paths and argument prefixes, and supported shell expressions are inspected before scheduling. Rules cover a command and its child processes; they do not detect GPU calls. A build tool may launch GPU tests, so the administrator must classify that build command as serial when those tests require coordinated timing. Each node has one serial execution slot and a first-in, firstout (FIFO) queue. Parallel commands can run while this slot is occupied. Queues are kept per node rather than clusterwide. Each node admits its own serial commands without a round trip to the controller, so local scheduling adds no

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon Cluster controller location + migration

Concurrent agent sessions / CLI Owner / source node

Target node

tool call / result

SSH control

Managed command Allowlist matching executable + arguments match

Reserve target-node slot validate files and command

migrate

no match

claim / commit

Parallel commands file tools and builds

Serial FIFO queue other commands

Sandbox process parallel permissions

Sandbox process one serial slot

Migrated command queue ready after commit

slot available

Sandbox process one serial slot

Native CPU execution

Native CPU execution

Metal calls

Metal calls

Apple GPU

Apple GPU

Shared workspace and instance HOME matching absolute paths on participating Macs Figure 2. Command scheduling and execution. Allowlist matches receive parallel execution permissions; other commands enter the node’s serial FIFO queue. Both paths execute native commands in an App Sandbox process, and Metal calls submit work to the Apple GPU. GPU timing commands use the serial path under the configured rules. Eligible waiting commands can migrate through target-node reservation, claim, and commit, using shared instance files. Outputs return to the original tool call.

network latency and does not depend on controller availability. Cross-node balance is instead provided by migrating waiting commands (Section 3.4), at the cost of not enforcing a global arrival order. Queue waiting is recorded separately and is excluded from Metal Sandbox’s managed command execution budget and Harbor’s active agent execution budget. The managed command’s execution budget starts when it receives execution permission. 3.4

Eligibility and Target-Node Selection

Dynamic scheduling considers only waiting serial commands from instances that enable it and meet the shared-file requirements in Section 2.3. The command’s arguments and environment must pass the source-private-path check; the target node also validates its files, environment, and scheduling rules. Parallel commands and agent sessions remain on their owner nodes. Intercepted shell tool calls supply their script, working directory, environment, relative timeout duration, and output-size limit. Calls missing this information remain local. The controller checks node status and looks for serial commands waiting at source nodes. A target node must have a free serial slot, no local serial waiters, no pending recovery,

and a thermal state below critical. Among eligible remote nodes, the controller chooses the smallest active-instance count; equal counts are resolved by selecting the smallest node ID. Reservation then holds the target node’s slot so another command cannot take it before migration completes. 3.5

Scheduling Pools

The administrator assigns each node to a scheduling pool, for example to group Macs with compatible hardware and toolchains. Automatic instance placement can be restricted to a selected pool. Command migration stays within the source node’s pool and requires cross-node scheduling to be enabled on both source and target nodes. 3.6

Reservation, Claim, and Commit

Figure 4 shows how a waiting command moves from its source queue to execution on a target node through reservation, claim, and commit. Reservation checks the shared workspace, command, environment, and scheduling rules, then holds the target node’s serial slot and prepares its sandbox process. The controller saves the command ID, source node, target node, and migration progress. Claim transfers execution responsibility from the source queue to the target

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon Source node

1. Reserve serial slot

Management + execution

reservation ID

Harbor Rollout orchestration

Mac mini #B

Cluster controller

Worker

Metal Sandbox service

Metal Sandbox service

2. Claim waiting command

3. Commit reserved command

Agent instances Parallel tools

Serial queue

CPU

GPU

CPU

GPU

SSH control requests

Serial queue

Mac mini #D

Worker

Worker

Metal Sandbox service

Metal Sandbox service

Agent instances

Agent instances

Parallel tools

Serial queue

Parallel tools

Serial queue

CPU

GPU

CPU

GPU

save migration progress

claimed; prevent local start

4. Deliver result and cleanup status Command migration

Agent instances Parallel tools

Mac mini #C

Target node

Controller

Mac mini #A

queued / running / finished query same command after reconnect

Claim prevents the command from starting on the source node while the target node executes it. The result completes the original command or agent tool call.

Figure 4. Command migration through reservation, claim, and commit. The source-node claim prevents local execution before the target node starts the command.

SMB workspace / HOME: matching absolute paths All Macs can communicate over the cluster network

Figure 3. Four-Mac deployment. Harbor and the cluster controller run on Mac mini #A, which also executes work. Solid arrows show SSH control requests; the dashed arrow shows command migration from #B’s waiting queue to #D. CPU/GPU arrows show parallel preparation and serial Metal execution. The agent stays on its owner Mac. All nodes have network access and prepared SMB workspace/HOME paths.

reservation, disabling a local start. Commit authorizes the reserved command to start on the target node. If the source command has already started or been cancelled, claim fails and the controller releases the unused target reservation. If the source node accepted the claim but its response was lost, the controller queries the same command ID before proceeding. It then commits the reserved command to the target node, which checks the command description and reservation ID. The target node records the command as queued, then running when execution starts. 3.7

Results and Accounting

The target node returns stdout, stderr, exit status, and cleanup information using the migrated command’s ID. The source node uses these results to finish the original CLI execution or shell tool call. Execution logs and local temporary files stay on the target node; workspace modifications are visible through shared storage. The command remains attributed to its owner instance, while per-node execution counts record where it actually runs. Batch elapsed time is measured at the submitting controller.

The controlled experiments report queue waiting at both nodes; the agent traces report the broader submission-tostart interval defined in Section 5.6.

4

H ARBOR I NTEGRATION

Harbor connects task specifications, coding agents, and automatic verification through the Metal Sandbox environment adapter. For each trial, the adapter creates an instance, uploads the task files, prepares the agent runtime within the instance, and starts the configured harness. The agent and verifier use separate execution phases; the verifier receives the completed workspace and returns the task result. Harbor retains these results and the agent trajectory for evaluation and rollout collection. Claude Code, Codex, and mini-SWE-agent are supported through the same managed command interface. Claude Code and Codex use tool hooks to route shell commands through the sandbox command helper. mini-SWE-agent uses its MetalEnvironment interface to submit commands and receive their outputs. Agent sessions run concurrently, and each tool call is scheduled independently. A migrated call retains its shell script, working directory, environment, and original result interface. Calls that lack a shared-workspace description remain on the owner node. Harbor task configuration selects the harness and runtime version, model endpoint, concurrency, and execution budgets. The adapter records command waiting separately from active execution, preserves stdout, stderr, and exit status, and collects the native trajectory and standardized ATIF record. This allows rollout timing to distinguish model requests, tool execution, and tool waiting.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon Table 2. Fixed scheduling workloads. TG denotes the requested threads per threadgroup, bounded by the pipeline limit. Kernel

Input and computation

TG

Matmul

Two 128 × 128 matrices; one output element/thread 256 × 256, single channel; 3 × 3 stencil, zero boundary 262,144 elements; a + b 1,024 groups of 256; sum per group 1,024 groups of 256; mean/variance, ϵ = 10−5 262,144 elements; max(0, ab + 0.125)

64

Convolution Elementwise Reduction Normalization Fused

5

256 64 256 64 256

E VALUATION

We measure command throughput, scaling with node count, and queue waiting under balanced and concentrated submissions, then examine longer commands and migration overhead. The controlled experiments use fixed Metal implementations. Section 5.6 reports all sixteen measured static agent trajectories; Section 5.7 replays those fixed traces under dynamic scheduling. 5.1

Experimental Setup and Workloads

We use fixed workloads to measure how command scheduling changes throughput and waiting as demand and node count vary. The experiments use four Mac mini nodes with Apple M4 processors, 32 GiB memory per node, and macOS 27.0.1 (build 26A434), interconnected through a gigabit Ethernet switch. Two owner instances are prepared per node. Shared workspaces use SMB mounts at matching absolute paths, and control requests use the remote CLI over SSH. Table 2 lists the six hand-written Metal kernels. Inputs are deterministic float32 arrays, with ai = ((i mod 23) − 11)/16 and bi = ((i mod 17) − 8)/16. The matrix and convolution workloads use these values in their respective shapes. An Objective-C++ runner is compiled with -O2 before the measured batches. Each command loads and compiles the Metal source, creates its pipeline and buffers, and repeatedly submits the selected kernel. Every submission is followed by waitUntilCompleted(), which waits for the GPU command buffer to finish before its GPU start and end timestamps are read. Five submissions warm up execution, followed by at least thirty valid GPU timestamp samples. The loop repeats submissions until the elapsed time from its start reaches the requested minimum of two or six seconds, including encoding, submission, and waiting. We call these workloads two-second and six-second commands, respectively. Both use the same small input shapes.

The runner writes each result for an external correctness check. Command outputs are checked before they contribute to the reported throughput. 5.2

Baselines and Comparison Design

The comparison holds the controller build, Metal implementations, participating machines, workload commands, runner, shared storage, scheduling rules, and numerical checker constant. We compare: 1. Static scheduling: commands execute on their assigned owner nodes, with cross-node command migration disabled. 2. Dynamic scheduling: eligible waiting serial commands can migrate to available target nodes through the reservation–claim–commit protocol. Owner assignments are controlled explicitly. Balanced batches distribute commands round-robin across the selected nodes; concentrated batches submit all commands through two instances on the management node. All workload commands use the serial queue, allowing one workload command per node at a time. Batch time is measured on the submitting controller from submission through completion of all result reads and external numerical checks. Runner compilation and referenceoutput preparation precede that interval; per-command Metal compilation and pipeline creation occur inside it. Throughput is the completed command count divided by batch time, expressed as commands per hour. Configuration order is randomized within each repetition. We report medians and observed minimum–maximum ranges over three independent batches per configuration. 5.3

Throughput, Scaling, and Queue Delay

We first measure throughput, scaling, and queue delay using twelve commands per batch, with each of the six kernels executed twice and a two-second minimum computation loop. Balanced submissions use one, two, or four nodes; concentrated submissions use the four-node cluster. Table 3 reports batch times and throughput. Balanced static execution decreases from 25.2 seconds on one node to 6.62 seconds on four nodes. With dynamic scheduling enabled, balanced runs take 25.1, 12.8, and 6.61 seconds on one, two, and four nodes. No commands migrate in these balanced batches, so the improvement comes from parallel execution across the available nodes. With concentrated submissions on the four-node cluster, median batch time decreases from 25.3 to 15.1 seconds, a 40.4% reduction and 1.68× throughput gain. The controller initiates at most one migration per source node per scan

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon Table 3. Twelve commands per batch with two-second minimum computation-loop durations. Times are medians [minimum, maximum] over three independent batches. Throughput is the median number of commands per hour calculated from each batch. All 288 reported executions pass the numerical check. Nodes

Submission

Static time (s)

Dynamic time (s)

Static/hour

Dynamic/hour

1 2 4 4

Balanced Balanced Balanced Concentrated

25.2 [25.0, 25.2] 12.9 [12.8, 13.0] 6.62 [6.62, 6.69] 25.3 [25.2, 25.3]

25.1 [25.1, 25.2] 12.8 [12.8, 12.9] 6.61 [6.60, 6.65] 15.1 [14.0, 16.9]

1,710 3,350 6,520 1,710

1,720 3,380 6,540 2,870

(a) Batch time

30 20

(b) Queue waiting 25

36.8 25.3 15.1

18

10 0

Queue p95 (s)

Batch time (s)

40

21.9

20 15

11.9

10 5 0

2s 12 cmds

Static

6s 6 cmds

Static

Dynamic

Dynamic

Figure 5. Concentrated submission to one node in a four-Mac cluster. Panel (a) shows batch time for two-second loops with twelve commands and six-second loops with six commands. Panel (b) shows within-batch queue p95 for the two-second workload. Bars show medians and whiskers show the minimum–maximum range of three independent batches.

and prepares remote execution through synchronous control requests, while the source queue continues executing locally. This limits how quickly the three remote serial slots can be filled for approximately two-second commands. Recorded GPU device identities show per-node command counts of 7/3/1/1, 7/3/1/1, and 6/3/2/1 across the three dynamic batches. Six or seven commands therefore still execute serially on the source node, compared with three per node in the balanced case. At approximately 2.10 seconds per command, this remaining source-node work accounts for approximately 12.6–14.7 seconds of execution. The remaining concentration, together with remote preparation and control costs, limits the speedup below balanced fournode scaling. The runtime’s queueWaitSeconds adds queue waiting at the source and target nodes. We compute the linearly interpolated 95th percentile within each twelve-command batch. Under concentrated submissions, the median of these batch values decreases from 21.9 [21.8, 21.9] seconds to 11.9 [10.5, 12.9] seconds, a 45.5% reduction (Figure 5b).

5.4

Long-Command Scheduling

To examine longer commands, we increase the minimum computation-loop duration to six seconds and submit each of the six kernels once per batch, using the same submission setup as the concentrated two-second batches. Static execution takes 36.8 [36.7, 36.8] seconds per batch, while dynamic scheduling takes 18.0 [17.6, 18.2] seconds (Figure 5a). This gives a 51.1% reduction in median batch time and 2.05× throughput: 588 versus 1,200 commands per hour. Four of the six commands execute on other nodes in every dynamic batch. Longer commands benefit from migration despite the cost of preparing remote execution. 5.5

Migration Overhead

We perform 27 explicit command migrations from the management node to one worker, with three repetitions for each combination of payload read size (0, 1, or 16 MiB) and minimum computation-loop duration (0, 0.25, or 2 seconds). An eight-second matrix-multiplication command occupies the source serial slot, and a second command waits for migration. Automatic migration is disabled in this measurement; the experiment driver invokes the reserve, claim, commit, and result-query operations explicitly. The migrated shell command reads the prepared payload files and executes the elementwise workload with 262,144 elements and a 64-thread group. Payloads are written before timing begins. Timing uses the controller’s local elapsed-time clock. It starts immediately before lookup of the waiting command and ends when the driver observes the remote command’s final result. It includes lookup, reservation, sandbox-process preparation, claim, commit, command execution, and result polling. Delivery to the source node, output retrieval, and the external numerical check follow this interval. Lookup and reservation together take a median of 0.818 seconds, with an observed range of 0.796–0.965 seconds across the 27 migrations. This stage includes sandbox-process preparation. Claim and commit take medians of 0.97 and 3.89 milliseconds, respectively.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon Table 4. Median explicit command migration time (seconds) from lookup of the waiting command to its remote result. Columns give minimum computation-loop durations. Each cell summarizes three repetitions. A zero duration retains warmup and GPU sampling.

Read (MiB) 0 1 16

Minimum loop duration (s) 0 0.25 2 1.86 1.92 2.16

2.19 2.13 2.51

3.96 3.95 4.20

Table 4 reports the full timed migration path. With no additional payload, the medians are 1.86, 2.19, and 3.96 seconds for minimum loop durations of 0, 0.25, and 2 seconds. Reading 16 MiB raises them to 2.16, 2.51, and 4.20 seconds. The approximately 1.86-second path at zero minimum loop duration makes migration costly for short commands. However, dynamic scheduling provides a net benefit in the concentrated two- and six-second batches, where idle remote capacity reduces source-node waiting. 5.6

Sustained-throughput estimate. Subtracting each session’s recorded tool waiting while retaining all other phase durations gives a mean elapsed time T0 = 24.12 minutes. The measured mean with four sessions per node is T4 = 45.12 minutes. If completed sessions are immediately replaced to maintain four active sessions per node, estimated per-node throughput increases from 1/T0 to 4/T4 :

Static Agent Rollout Traces

We collect sixteen mini-SWE-agent sessions through Harbor, initially assigning four independent sandbox instances to each of the four M4 nodes. The sessions use Step 5 Preview (StepFun, 2026) with mini-SWE-agent 2.4.6. Each receives metal_nbody: implementing a native Metal allpairs gravitational simulation, an interactive renderer, a deterministic simulation CLI, and a benchmark entry point. The active execution budgets are 3,600 seconds per agent and 600 seconds per tool. Appendix D gives the complete task specification. Static workspaces and HOME directories remain instance-local. The task exercises source code generation, compilation, numerical testing, and repeated application runs.

Sthroughput =

4/T4 4 × 24.12 = ≈ 2.14. 1/T0 45.12

This compares one versus four sessions per node on the same hardware; the node count cancels. 5.7

Trace-Driven Scheduling Replay

Independent live runs can produce different model responses, command sequences, compilation failures, and execution durations. Comparing a live static run with a separate dynamic run would mix the scheduling effect with changes in agent behavior. We therefore use paired tracedriven replay to compare both scheduling policies on the same measured trajectories. The measured static instances use local workspaces. In the replay, recorded command paths are screened according to the migration-eligibility requirements in Section 3.4. With static scheduling, each replayed session finishes less than 1 ms from its measured finish time, and its total tool waiting differs by less than 8 ms. This validates the reconstruction of the recorded schedule before changing the policy. Using migration delays measured in Section 5.5, dynamicscheduling replay reduces mean tool waiting from 21.0 to 17.1 minutes (18.8%) and batch elapsed time from 67.6 to 52.5 minutes (22.3%). Figure 7 shows both the batch-level reduction and the distribution of individual elapsed times across the same sixteen trajectories.

Batch elapsed time runs from release of the sixteen sessions to the last sandbox stop; individual elapsed time runs from session start to sandbox stop. Instrumentation distinguishes model requests, serial and parallel tools, tool waiting, final verification, and shutdown. Model intervals include service waiting, reasoning, and generation. Tool waiting spans command submission to its observed source start notification, including helper startup, communication, and queue delay; model-request time is separate. Figure 6 shows the measured static timelines alongside their dynamic-scheduling replay.

The replay fixes model responses and their durations, command text and order, observed execution-slot occupancy, and local communication time. Each later submission waits for its preceding tool responses. The median delays measured in Section 5.5 are 0.818 seconds for lookup and reservation combined, 0.97 milliseconds for claim, and 3.89 milliseconds for commit; the median additional cleanup, communication, and result-polling delay is 0.935 seconds. The main replay uses these measured costs and a 0.015-second source-notification delay estimated as half the 0.030-second polling interval.

The measured batch lasts 67.6 minutes, with mean tool waiting of 21.0 minutes and mean individual elapsed time of 45.1 minutes. These sixteen static trajectories contain 114 parallel and 1,165 serial tool commands. These traces supply the fixed behavior for the scheduling replay below.

The main replay completes 276 command migrations. Eight trajectories have less accumulated waiting and eight have more. Mean waiting for the initially busiest owner, Mac mini #A, falls from 32.7 to 15.8 minutes; #B also improves, while #C and #D incur more waiting. We vary migration

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon (a) Measured static scheduling

Trajectory

Batch: 67.6 min 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

Mac mini #A

Mac mini #B

Mac mini #C

Mac mini #D

0

10

20

30 40 Minutes from batch release

50

60

70

(b) Dynamic-scheduling replay

Trajectory

Batch: 52.5 min 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

Mac mini #A

Mac mini #B

Mac mini #C

Mac mini #D

0

10

20

Environment and Agent setup Serial tool Sandbox shutdown

30 40 Minutes from batch release Model request and response Tool waiting Command migration

50

60

70

Parallel tool Verification

Figure 6. Sixteen agent timelines under (a) measured static scheduling and (b) dynamic-scheduling replay. Red lines mark batch elapsed time, when the last sandbox stops. Blue outlines group four sessions per owner Mac mini, #A–#D.

overhead and scheduling parameters to assess the sensitivity of the replay results. Across the tested settings, the replay predicts reductions of 6.78–20.4% in mean tool waiting and 15.6–27.8% in batch elapsed time relative to measured static scheduling. Appendix B details the 166 parameter settings and validation checks. Appendix A reports every paired trajectory and its elapsed time.

6

R ELATED W ORK

Kernel evaluation and training. KernelBench couples correctness and performance evaluation with parallel generation and serialized GPU execution (Ouyang et al., 2025). KernelGYM, developed for Dr. Kernel, supports distributed GPU evaluation, isolated subprocesses, and multi-turn reinforcement-learning data collection (Liu et al., 2026). Metal-Sci searches native Metal scientific kernels (Gallego, 2026), while KernelArc coordinates optimization agents and shares validated results (Kundu et al., 2026). These systems

Elapsed (min)

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon Batch: 67.6 min

Batch: 52.5 min

Static

Replay

60 40 20 0

Figure 7. Batch elapsed time and individual duration distributions for the measured static batch and its dynamic scheduling replay. Labels give batch elapsed time; circles and connecting lines retain all sixteen paired trajectories. Replay holds model behavior and phase durations fixed.

schedule work at the granularity of candidate evaluations. Metal Sandbox schedules the individual tool commands of interactive agent sessions, which run in persistent native macOS instances with direct Apple GPU access. Remote command execution. distcc distributes compilation by sending preprocessed sources and compiler arguments (Pool, 2008). Bazel Remote Execution distributes build and test actions through a worker pool, transferring inputs and caching outputs in content-addressed storage (Bazel contributors, 2018). These systems establish command-level remote execution. Metal Sandbox supports interactive tools in persistent native macOS instances, sharing workspace and HOME paths while preserving each agent’s command-result interface. Distributed scheduling. Sparrow delays task assignment until workers are ready to execute (Ousterhout et al., 2013). Work stealing lets idle processors take ready computations from other processors (Blumofe & Leiserson, 1999). Metal Sandbox applies availability-based scheduling to waiting serial tool commands, using target reservations and source claims to coordinate migration while running processes remain local. Agent interfaces and rollout environments. SWE-agent studies how command and observation interfaces shape automated software engineering (Yang et al., 2024). SkyRLAgent uses asynchronous dispatch for multi-turn agent training and evaluation (Cao et al., 2025), and R2E-Gym provides executable software-engineering environments and hybrid verification (Jain et al., 2025). Metal Sandbox supplies native Apple Metal execution and command scheduling through Harbor, supporting Claude Code, Codex, and mini-SWE-agent in a common task and trajectory-collection workflow.

Accelerator sharing and execution isolation. Gandiva time-slices GPUs and migrates training jobs (Xiao et al., 2018); Salus supports fast job switching and memory sharing (Yu & Chowdhury, 2020). Firecracker isolates workloads with KVM-based microVMs (Agache et al., 2020), while gVisor implements a Linux application kernel to mediate system calls (gVisor contributors, 2018). Metal Sandbox uses Apple App Sandbox to restrict per-instance file access while retaining native macOS tools and Apple GPU access.

7

D ISCUSSION AND L IMITATIONS

File-access restrictions apply to sandbox processes and their ordinary children; some application-launch paths remain outside this boundary. The system does not provide hostile multi-tenant containment or physical GPU exclusivity. Other applications and commands classified as parallel may still use the GPU. Replay estimates scheduling effects while holding model behavior and phase durations fixed. It uses a sourcenotification delay estimated from the sandbox-process polling interval. It cannot predict changes in agent behavior caused by different tool feedback, or changes in kernel quality, training outcomes, or deployment reliability. Eight trajectories have less accumulated tool waiting and eight have more, even though mean tool waiting and batch elapsed time improve.

8

C ONCLUSION

Metal Sandbox combines native Apple Metal execution, perinstance filesystem isolation, and command-level scheduling across interconnected Macs. Its Harbor integration supports Claude Code, Codex, and mini-SWE-agent through a shared task, verification, and trajectory-collection workflow. Four-node experiments demonstrate scaling under balanced submissions and throughput gains under concentrated submissions. Replaying fixed agent trajectories predicts reduced tool waiting and shorter batch completion under dynamic scheduling. Metal Sandbox provides execution infrastructure for training and evaluating models that generate Apple Metal kernels.

R EFERENCES Agache, A., Brooker, M., Florescu, A., Iordache, A., Liguori, A., Neugebauer, R., Piwonka, P., and Popa, D.-M. Firecracker: Lightweight virtualization for serverless applications. In 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI), pp. 419–434, 2020. URL https://www.usenix.org/conference/ nsdi20/presentation/agache.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon

Apple Inc. Metal overview, 2014. URL https://developer.apple.com/metal/. Accessed 2026-10-24.

Docker Inc. Docker Desktop: Virtual Machine Manager, 2024. URL https://docs.docker.com/ desktop/features/vmm/. Accessed 2026-10-24.

Apple Inc. Enabling App Sandbox, 2017. URL https://developer.apple.com/library/ archive/documentation/Miscellaneous/ Reference/EntitlementKeyReference/ Chapters/EnablingAppSandbox.html. Entitlement Key Reference. Accessed 2026-10-07.

Gallego, V. Metal-Sci: A scientific compute benchmark for evolutionary LLM kernel search on Apple Silicon. arXiv preprint arXiv:2605.09708, 2026. URL https://arxiv.org/abs/2605.09708.

Apple Inc. Create macOS or Linux virtual machines. WWDC 2022, session 10002, 2022. URL https://developer.apple.com/videos/ play/wwdc2022/10002/. Accessed 2026-10-24. Apple Inc. Apple introduces iPhone 16 and iPhone 16 Plus, 2024a. URL https://www.apple.com/ newsroom/2024/09/apple-introducesiphone-16-and-iphone-16-plus/. Accessed 2026-10-25. Apple Inc. Apple introduces M4 chip, 2024b. URL https://www.apple.com/newsroom/2024/ 05/apple-introduces-m4-chip/. Accessed 2026-10-25. Apple Inc. Metal feature set tables, 2026. URL https://developer.apple.com/metal/ Metal-Feature-Set-Tables.pdf. Accessed 2026-10-25. Apple Inc. Metal developer tools, n.d. URL https: //developer.apple.com/metal/tools/. Accessed 2026-10-25. Bazel contributors. Remote execution overview and Remote Execution API, 2018. URL https://bazel.build/remote/rbe. API: https://github.com/bazelbuild/remoteapis. Accessed 2026-10-27. Blumofe, R. D. and Leiserson, C. E. Scheduling multithreaded computations by work stealing. Journal of the ACM, 46(5):720–748, 1999. doi: 10.1145/324133.324234. Cao, S., Li, D., Zhao, F., Yuan, S., Hegde, S. R., Chen, C., Ruan, C., Griggs, T., Liu, S., Tang, E., Liaw, R., Moritz, P., Zaharia, M., Gonzalez, J. E., and Stoica, I. SkyRL-Agent: Efficient RL training for multi-turn LLM agent. arXiv preprint arXiv:2511.16108, 2025. URL https://arxiv.org/abs/2511.16108. Docker Inc. GPU support in Docker Desktop for Windows, 2021. URL https://docs.docker.com/ desktop/features/gpu/. Accessed 2026-10-25.

Gunter, T., Wang, Z., Wang, C., Pang, R., Narayanan, A., Zhang, A., Zhang, B., Chen, C., Chiu, C.-C., Qiu, D., Gopinath, D., Yap, D. A., Yin, D., Nan, F., Weers, F., Yin, G., Huang, H., Wang, J., Lu, J., Peebles, J., Ye, K., Lee, M., Du, N., Chen, Q., Keunebroek, Q., Wiseman, S., Evans, S., Lei, T., Rathod, V., Kong, X., Du, X., Li, Y., Wang, Y., Gao, Y., Ahmed, Z., Xu, Z., Lu, Z., Rashid, A., Jose, A. M., Doane, A., Bencomo, A., Vanderby, A., Hansen, A., Jain, A., Anupama, A. M., Kamal, A., Wu, B., Brum, C., Maalouf, C., Erdenebileg, C., Dulhanty, C., Parilla, D., Moritz, D., Kang, D., Jimenez, E., Ladd, E., Shi, F., Bai, F., Chu, F., Hohman, F., Kotek, H., Coleman, H. G., Li, J., Bigham, J., Cao, J., Lai, J., Cheung, J., Shan, J., Zhou, J., Li, J., Qin, J., Singh, K., Vega, K., Zou, K., Heckman, L., Gardiner, L., Bowler, M., Cordell, M., Cao, M., Hay, N., Shahdadpuri, N., Godwin, O., Dighe, P., Rachapudi, P., Tantawi, R., Frigg, R., Davarnia, S., Shah, S., Guha, S., Sirovica, S., Ma, S., Ma, S., Wang, S., Kim, S., Jayaram, S., Shankar, V., Paidi, V., Kumar, V., Wang, X., Zheng, X., Cheng, W., Shrager, Y., Ye, Y., Tanaka, Y., Guo, Y., Meng, Y., Luo, Z. T., Ouyang, Z., Aygar, A., Wan, A., Walkingshaw, A., Narayanan, A., Lin, A., Farooq, A., Ramerth, B., Reed, C., Bartels, C., Chaney, C., Riazati, D., Yang, E. L., Feldman, E., Hochstrasser, G., Seguin, G., Belousova, I., Pelemans, J., Yang, K., Alizadeh Vahid, K., Cao, L., Najibi, M., Zuliani, M., Horton, M., Cho, M., Bhendawade, N., Dong, P., Maj, P., Agrawal, P., Shan, Q., Fu, Q., Poston, R., Xu, S., Liu, S., Rao, S., Heeramun, T., Merth, T., Rayala, U., Cui, V., Rangarajan Sridhar, V., Zhang, W., Zhang, W., Wu, W., Zhou, X., Liu, X., Zhao, Y., Xia, Y., Ren, Z., and Ren, Z. Apple Intelligence foundation language models. Technical Report arXiv:2407.21075, Apple, 2024. URL https://arxiv.org/abs/2407.21075. gVisor contributors. Introduction to gVisor security, 2018. URL https://gvisor.dev/docs/ architecture_guide/intro/. Accessed 2026-10-27. Hannun, A., Digani, J., Katharopoulos, A., and Collobert, R. MLX: Efficient and flexible machine learning on Apple Silicon, 2023. URL https://github.com/ml-explore/mlx. Accessed 2026-10-24.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon

Harbor contributors. Harbor documentation, 2026. URL https://docs.harborframework.com/. Accessed 2026-10-25. Jain, N., Singh, J., Shetty, M., Zhang, T., Zheng, L., Sen, K., and Stoica, I. R2E-Gym: Procedural environment generation and hybrid verifiers for scaling open-weights SWE agents. In Conference on Language Modeling (COLM), 2025. URL https://arxiv.org/abs/2504.07164. Kundu, J., Stoffelen, B., Wang, K., Vrancx, P., and Denoyer, L. KernelArc: A multi-agent framework for GPU kernel optimization. arXiv preprint arXiv:2608.17071, 2026. URL https://arxiv.org/abs/2608.17071. Liu, W., Xu, J., Li, Y., Zheng, L., Li, T., Liu, Q., and He, J. Dr. Kernel: Reinforcement learning done right for Triton kernel generations. arXiv preprint arXiv:2602.05885, 2026. URL https://arxiv.org/abs/2602.05885. Ousterhout, K., Wendell, P., Zaharia, M., and Stoica, I. Sparrow: Distributed, low latency scheduling. In 24th ACM Symposium on Operating Systems Principles (SOSP), pp. 69–84, 2013. doi: 10.1145/2517349.2522716. Ouyang, A., Guo, S., Arora, S., Zhang, A. L., Hu, W., Ré, C., and Mirhoseini, A. KernelBench: Can LLMs write efficient GPU kernels? In Proceedings of the 42nd International Conference on Machine Learning (ICML), volume 267 of PMLR, pp. 47356–47415, 2025. URL https://proceedings.mlr.press/v267/ ouyang25a.html. Pool, M. distcc manual page, 2008. URL https:

//www.distcc.org/man/distcc_1.html. Accessed 2026-10-27. StepFun. Step 5 Preview, 2026. URL https: //www.stepfun.com/step-5-preview. Accessed 2026-10-27. SWE-agent contributors. mini-SWE-agent, version 2.4.6, 2026. URL https://github.com/SWE-agent/miniswe-agent/releases/tag/v2.4.6. Accessed 2026-10-25. Xiao, W., Bhardwaj, R., Ramjee, R., Sivathanu, M., Kwatra, N., Han, Z., Patel, P., Peng, X., Zhao, H., Zhang, Q., Yang, F., and Zhou, L. Gandiva: Introspective cluster scheduling for deep learning. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI), pp. 595–610, 2018. URL https://www.usenix.org/conference/ osdi18/presentation/xiao. Yang, J., Jimenez, C. E., Wettig, A., Lieret, K., Yao, S., Narasimhan, K., and Press, O. SWE-agent: Agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems 37 (NeurIPS), pp. 50528–50652, 2024. doi: 10.52202/079017-1601. Yu, P. and Chowdhury, M. Fine-grained GPU sharing primitives for deep learning applications. In Proceedings of Machine Learning and Systems 2 (MLSys), pp. 98–111, 2020. URL https://proceedings.mlsys.org/paper_ files/paper/2020/hash/ d9cd83bc91b8c36a0c7c0fcca59228f2Abstract.html.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon

A

S TATIC ROLLOUT AND R EPLAY R ECORDS

The measured static batch and its dynamic scheduling replay retain the same sixteen trajectories. Indices in Table 5 identify paired trajectories with fixed model responses and command behavior. Mac mini labels #A–#D identify the initial owner throughout both schedules. Figure 7 compares batch elapsed time and individual duration distributions.

Table 5. Individual elapsed time and accumulated tool waiting in minutes for every paired trajectory. Elapsed time runs from session start to sandbox stop. Replay fixes the measured model responses and phase durations under the assumptions in Appendix B. Measured static Dynamic replay Trace / Mac Elapsed Waiting Elapsed Waiting

B

00 / #A 01 / #A 02 / #A 03 / #A 04 / #B 05 / #B 06 / #B 07 / #B 08 / #C 09 / #C 10 / #C 11 / #C 12 / #D 13 / #D 14 / #D 15 / #D

67.6 67.4 65.1 44.6 50.9 42.0 49.8 39.1 41.2 34.5 40.1 40.0 36.5 32.9 36.0 34.2

29.0 40.5 32.6 28.7 18.2 22.4 25.5 20.9 18.5 15.0 15.3 16.2 12.8 13.2 15.0 12.0

52.5 49.6 46.9 31.4 46.6 38.7 46.1 36.5 44.1 37.9 40.1 43.9 38.6 33.4 41.3 35.3

13.1 21.6 14.7 13.9 13.5 18.9 21.6 17.9 21.2 19.2 16.3 20.4 14.8 13.4 19.0 13.3

Mean

45.1

21.0

41.4

17.1

S CHEDULING R EPLAY D ETAILS

The replay retains all sixteen measured trajectories, including five tools without observed start notifications. No new model responses or candidate executions are produced. All identifiers and owner-node labels match Appendix A. Trace coverage and timing. Inputs contain 1,275 complete model phases, 1,279 tool calls (1,165 serial and 114 parallel), and 144 setup or verification commands. All 1,274 tools with execution-start records have matching commandargument hashes. Responses, command order, observed execution-slot occupancy, and local communication durations remain fixed. Each subsequent model request, tool call, verification step, or shutdown is delayed until its preceding responses are available. Tool waiting ends at the source start notification, which may arrive after remote execution begins.

Scheduling and portability. Each node has one serial execution slot and a first-in, first-out (FIFO) queue. Every second, the controller checks source nodes in node-ID order. A target node must have a free serial slot and no local waiting serial commands; selection uses current instance count, then node ID. Waiting commands are selected by commandID order, without inspecting future durations. Reservation occupies the target slot; a source-local start before claim cancels migration. Commands already running are not migrated; agent sessions, parallel tools, setup, and verification remain on their owner nodes. The replay filters the recorded command text for absolute paths to owner-local files, leaving 1,131 serial tools eligible for migration. Environment-variable references to node-private dependencies require portable environments for these predictions. Migration costs. The 27 measured migrations provide median combined lookup and reservation, claim, and commit delays of 0.818, 0.00097, and 0.00389 seconds. A further 0.935 seconds is the median difference between remoteresult observation time and candidate-process execution time; it includes cleanup, communication, and result polling. Source notification adds an estimated 0.015 seconds, half the configured 0.030-second sandbox-process polling interval. The main replay uses overhead scale 1, controller start offset 0, and command-ID ordering seed 0. Validation and sensitivity. With static scheduling, each replayed session finishes less than 1 ms from its measured finish time, and its total tool waiting differs by less than 8 ms. Validation also checks phase dependencies and durations, keeps parallel commands local, and enforces migration eligibility, one serial command per node, target reservations, and selection based only on current node status. The sensitivity study combines four migration-cost scales {0.5,1,2,4}, four controller start offsets {0,0.25,0.5,0.75} seconds, and ten command-ID ordering seeds 0–9, giving 4 × 4 × 10 = 160 configurations. Six additional configurations vary only source-notification delay {0,0.03,0.1,0.5} seconds or controller-check interval {2,5} seconds from the main settings. All 166 pass the scheduling checks. Mean tool waiting spans 16.7–19.6 minutes; batch elapsed time spans 48.8–57.1 minutes. All configurations and trajectories are retained in the artifact.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon

C

D EFAULT PARALLEL A LLOWLIST

The following is the complete shipped parallel allowlist template. Each name in the first two groups denotes the executable at the stated directory. The final group denotes paths resolved from the installed development tools when an instance is created. All entries accept any argument prefix except CMake, which requires --build. The administrator can change this scheduling policy; the list classifies commands and does not detect GPU use. Executable directory

Complete entries

/bin/ /usr/bin/

ls, cat, pwd, sleep, echo, date, test, mkdir, rmdir, cp, mv, rm, ln, chmod, df, realpath touch, head, tail, grep, egrep, fgrep, sed, awk, sort, uniq, wc, cut, tr, tee, diff, cmp, comm, paste, join, basename, dirname, readlink, stat, file, du, find, jq, git, curl, tar, zip, unzip, gzip, gunzip, shasum, printf, true, false, make C compiler, C++ compiler, Xcode Git, Xcode Make, Ninja, Metal compiler, metallib, and CMake with argument prefix --build

Installed tools

D

TASK S PECIFICATION : metal_nbody

Execution and submission. This is a complete project task to be completed autonomously. You receive the full specification and public attachments at the start. Implement, build, test, and fix the project within the same session without waiting for clarification, approval, or further evaluation feedback. Decide unspecified details yourself and document them in the README. Tool calls are unlimited. Submit complete source code, dependency configuration, a launch entry point, and usage instructions; do not submit plans, placeholder modules, or unfinished implementations. The project is frozen after final submission or the time limit and evaluated centrally, without returning errors for further repair. Interactions described below are features of the finished product and do not require user participation during development. L: Star Cluster Workbench—Metal particle simulation and graphics optimization. A science museum wants to display dynamic structures formed by particles under mutual gravitational attraction. The exhibit must run continuously without frequent stalls when visitors move the camera, pause, or regenerate the cluster. Build a native interactive macOS application connecting computational correctness, GPU scheduling, and visual presentation. Research-grade astrophysical accuracy is unnecessary, but prerecorded video, regular rotation, or a small particle set cannot substitute for the specified interactions. The goal is a graphics implementation that can be repeatedly checked using common inputs, numerical comparisons, and device measurements. The display may begin with a simple small-particle state and then switch to a dense cluster. Both scales use the same computational definition; do not use a separate approximate simulation for the display. This sequence is a usage suggestion, not a requirement for a preset-scene library. Graphics optimization may change data organization and execution, but must preserve the physical meaning of exported results. Numerical checks compare short deterministic runs; long-term visual trajectory differences are not error thresholds. Choose the camera, particle colors, and background to make spatial structure clear. Deliver an application that performs three-dimensional all-pairs gravitational computation and rendering with Metal, plus a terminal benchmark entry point. The program must load external state, advance with a fixed time step, export results, and measure performance. Establish small-scale correctness before optimizing to sixty frames per second on the specified device and particle count. Choose resource organization and scheduling yourself; evaluation uses correct output and measured frame times under the same workload. Working environment and self-testing. The current directory is the project workspace prepared by Harbor inside Metal Sandbox. Keep source code, builds, and outputs in this writable directory, without relying on the host task-package path. Keep every candidate build and run inside the management service’s App Sandbox. Do not bypass restrictions through execution outside the sandbox, system services, elevated privileges, or host configuration changes. The target is macOS on a physical Apple Silicon GPU. Use the actual clang, clang++, swift/swiftc, metal, and metallib resolved by the runtime PATH, together with the supplied CC, CXX, and SDKROOT. Check available tools and preserve the existing environment. System xcrun cannot run here; do not use it to locate tools or SDKs or assume an xcodebuild project is available. You may compile and link native frameworks directly, compile separate shaders with metal/metallib, or compile Metal source at runtime. Record missing tools honestly and do not install them on the host.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon The terminal is not a PTY, so commands must not require interactive confirmation. If a bench-server is needed, communicate with it through child-process pipes from a runner in the same managed execution, without relying on a console to keep stdin open. GUI operation, visible windows, screenshots, and presentation timing remain to be verified in this environment; retain the application and interactions. If restricted, report actual errors and unverified items rather than claiming an offscreen substitute is complete. Numerical commands must be independent of windows. The performance target is a Mac mini M4 and 32 GiB memory. Record the actual machine, system, tools, and available measurement capabilities. On unmatched hardware or without exclusive access, report exploratory results without claiming the target is met. Multiple-instance scheduling does not guarantee GPU exclusivity. Evaluators calibrate formal measurements under suitable conditions; application-reported metrics are not the sole evidence. M1: Project and entry points. Deliver a native macOS project, README, and executable run.sh. Support ./run.sh app, ./run.sh simulate --input FILE --steps N --output FILE, and ./run.sh benchmark --input FILE --output DIR. The simulation entry point must operate without mouse interaction, read external files, and write parseable JSON. Report actual build logs on failure. M2: Inputs and scale. The input object contains dt, epsilon, and particles. Each particle is {id, mass, position:[x,y,z], velocity:[vx,vy,vz]}. IDs are unique signed 32-bit integers; mass lies in [0.001, 10], absolute position components do not exceed 100, and absolute velocity components do not exceed 10. The ranges are dt ∈ [0.0001, 0.02] and epsilon ∈ [0.05, 1]; every number is finite. Support 2–8,192 particles. Invalid inputs or nonfinite computed values must produce a nonzero exit and an explanation. M3: Acceleration definition. Use G = 1. For every particle i, ai =

mj (pj − pi ) . 2 2 3/2 (∥p − p j i ∥ + epsilon ) j̸=i

X

All accelerations in a step read positions from the start of that step; do not mix sequentially updated positions into the same step. Always include softening. Coincident particles must not produce NaN. M4: Integration and export. Use semi-implicit Euler: vnew = vold + a dt and pnew = pold + vnew dt. N is an integer from 0 to 1,000. The simulate command advances exactly N steps and outputs {dt,epsilon,steps:N,particles}, retaining each particle’s id, mass, position, and velocity in input order. For small-scale tests after one and ten steps, each component’s error must be at most 10−4 + 10−3 |reference|. Do not judge correctness using chaotic divergence of long-term trajectories. M5: GPU implementation. All-pairs interaction and integration in every step must execute in Metal compute shaders; rendering must also use Metal. Do not substitute a CPU main loop, reduce the particles participating in interactions, cache fixed-input trajectories, or replace the formula with approximate neighborhood truncation. The CPU may handle input, UI, and resource management. M6: Display and camera. Display every particle by default. Support mouse rotation, scroll-wheel zoom, and restoration of the default camera. Actual position updates drive the display. Particles may be points or small quads; complex materials are unnecessary. Camera changes must not change physical state, and window resizing must not stretch the coordinate space. M7: Pause and reset. Provide play/pause, single-step, reset, load, and current-state export controls, with the same export format as simulate. Show particle count and cumulative step count. Paused state remains unchanged; single-step advances exactly once; reset restores the most recently loaded initial state and zero steps. Interactive mode advances one fixed-dt step per rendered frame, without adapting the step size to wall time. M8: Benchmark workload. The benchmark uses an evaluator-supplied state of 8,192 particles, dt = 1/120, and epsilon = 0.05. Render at 1920 × 1080 physical pixels. Each frame advances exactly one step and draws all particles. Dynamic resolution, skipped simulation steps, and reduced particle count are prohibited. Keep the camera fixed and the window visible during benchmarking.

Metal Sandbox: Isolated Execution and Command Scheduling for GPU Coding Agents on Apple Silicon M9: Performance target. After a ten-second warmup, measure continuously for sixty seconds, with one task exclusively using the device and a 60 Hz display configuration. Average presented frame rate must be at least 59, presentation-interval p95 must not exceed 20 ms, and no stall may exceed 200 ms. This tolerance expresses a stable sixty-frame-per-second target; it does not require every frame to be strictly below 16.67 ms. Numerical correctness and workload checks must pass before performance is assessed. M10: Measurement artifacts. The benchmark exports per-frame submission, GPU completion, and actual presentation timestamps, step number, particle count, drawable size, and environment information. Explicitly mark unsupported timing fields as null and explain them. Do not pass off CPU submission time as GPU execution time. Trusted evaluation separately collects presentation evidence; application reports are not the only basis for assessment. M11: Errors and resources. Load states with 2, 17, and 8,192 particles in sequence and switch between paused and running states ten times. There must be no out-of-bounds accesses, crashes, or stale-buffer artifacts. Preserve a usable interface and show a message on invalid input. Document self-test commands, known limitations, and one actual before/after optimization measurement in the README. Do not invent unexecuted results. Technical scope. Use Swift, Objective-C, or C++ for host code and Metal Shading Language for GPU algorithms. Choose a native window framework. Do not substitute browser rendering, CUDA, external solver services, or video playback. Floating-point precision is your choice, but the specified error bounds must hold. Do not emit preset answers based on evaluation filenames. Collision merging, gravitational tree approximations, multiple GPUs, physical cosmological units, long-term orbital stability, model imports, and complex postprocessing are out of scope. A realistic-looking nebula does not replace formula verification. The same frame rate is not required on Linux or different Mac models. Suggested but optional. The following are optional and do not affect the mandatory requirements: B1: Improve particle depth and background composition without reducing work. B2: Provide an analysis panel explaining numerical errors and measurements. B3: Improve camera reset, input feedback, and keyboard operation. B4: Explain a real bottleneck and evidence for its resolution. Your decisions. Choose thread organization, memory layout, buffer reuse, compute/render synchronization, particle shape, and colors. No particular technique is required, but explain what the exported timing metrics mean. If time is limited, prioritize small-scale numerical correctness and reproducible entry points. Extra visual effects must not reduce benchmark work. Delivery instructions. Document the shortest steps from a clean directory to the main interface, including required configuration, default demonstration data, and reset behavior. Include source code, dependency versions, and required local resources; exclude credentials and personal information. Invalid input must produce understandable feedback rather than silently changing a previously correct state. Record only tests actually performed, explicitly identify unexecuted checks, and do not replace successful results with speculation. Prioritize first launch, normal use, boundary inputs, and quit/relaunch, and explain which limitations are unfinished work.

Related documents

• When Faster VLA Deployment Changes Closed-Loop Behavior: Task Success-Latency Analysis of SmolVLA Across PyTorch and ONNX Variants#1013697
• SakanaAI/AI-CUDA-Engineer-Archive#786764
• KernelZero: Co-Evolving Proposer and Coder for Continuously Improved GPU Kernel Generation#1117786
• Bare-Metal Embedded C Programming#1331229
• HeteroMosaic: Exposing and Exploiting Heterogeneous Execution Opportunities for Energy-Efficient Edge LLM Inference#366223