Vercel adds FUSE Sandbox mounts and Agent Runs MCP/CLI access

• Vercel's Sandbox announcement shipped FUSE-based filesystems for Sandboxes, including S3 buckets, network filesystems, remote CLI access, and shared state across Sandboxes.
• rauchg's post framed the Sandbox update as the payoff from microVMs: Docker and FUSE can now run in the same unconstrained runtime, with an S3-backed filesystem example in roughly 10 lines.
• Vercel's Agent Runs post opened eve traces through Vercel MCP and CLI, including reasoning, tool calls, token usage, and tool input or output.
• rauchg's observability post called the loop “agentic self-improvement,” while rauchg's reply said the installed eve skill already knows about the new Agent Runs surface.
• Vercel's Gateway routing post added gateway-level model routing rules, and Vercel's dry-run post added vercel deploy --dry for pre-deployment manifests.

The FUSE changelog includes the sharp edge: its sample passes AWS credentials into mount-s3 and notes they are permanently exposed in the sandbox, so it uses a restricted role. The Agent Runs changelog says piped CLI traces render as Markdown, which gives non-MCP coding agents a plain-text debugging path. The dry-run deployment changelog turns the deployment file manifest into JSON, including file modes and content hashes.

Vercel's FUSE changelog moves remote storage into the same POSIX-looking surface as local Sandbox files. The example installs fuse and Amazon's mount-s3 RPM with dnf, creates /mnt/s3, runs mount-s3, then lists the mounted bucket.

The shipped mechanics are simple:

• Mount S3 buckets, network filesystems, or any FUSE-compatible driver.
• Run CLI tools against remote sources without copying data into the Sandbox first.
• Stream large datasets directly from object storage.
• Share state across Sandboxes through a common mounted filesystem.

The substrate is not a normal serverless function. Vercel's Sandbox docs describe a Firecracker microVM with its own filesystem and network, sudo access, persistence by default, and support for system-privileged processes. The system specifications explicitly list Docker, VPN clients, and FUSE filesystems as supported privileged workloads, with outbound network access still governed by the sandbox firewall policy.

According to the Agent Runs changelog, deployed eve traces are automatically ingested into Vercel and exposed as Agent Runs. The new surface is both MCP-native and CLI-native.

MCP tools:

• list_agent_run_projects: find projects in a team with Agent Runs activity.
• list_agent_runs: list recent runs for a project.
• get_agent_run: inspect metadata, lifecycle events, usage, and subagent data.
• get_agent_run_trace: retrieve turns, messages, reasoning, tool calls, token usage, and tool input or output.

CLI commands:

• vercel agent-runs projects
• vercel agent-runs list
• vercel agent-runs inspect
• vercel agent-runs trace

The Vercel MCP tools docs add the operational details: project and team IDs are first-class parameters, run lists include status, model, trigger, token usage, time series, and pagination, and get_agent_run_trace has a maxFieldLength option that defaults to 8,000 characters.

Every CLI subcommand supports --json. Piped traces render as Markdown, which makes the trace format useful outside an MCP host.

rauchg's observability post names the loop directly: give an agent access to past runs, let it spot inefficiencies, errors, and redundant tool calls, then produce new prompts and skills. MelkeyDev's reaction put the community read bluntly: deployed eve traces can become course-correction material.

The eve observability docs say Agent Runs appear automatically for eve projects with no instrumentation file. The overview breaks runs down by trigger, token usage, triggering message, turn count, duration, and time.

The per-run view includes:

• Model, trigger, and deployment.
• Step timings, including skill loads and tool calls.
• Turn input and output.
• Model reasoning.
• Tool calls with arguments and results.
• Input, cached, and output token counts per turn.

Christmas came early for agent-harness nerds: the run log is now inside the tool surface the agent can call.

Vercel's AI Gateway routing changelog adds firewall-style model controls at the gateway level. Rules are managed in the Vercel CLI and apply to every request made with a team's AI Gateway credentials.

Two rule types shipped:

• rewrite: serve a request for one model using another model, while the application keeps requesting the original model.
• deny: block a model and return 403.

The beta keeps existing request-level and team-level configuration in place for the destination model. Vercel lists BYOK, model fallbacks, sorting, the only filter, provider options, Zero Data Retention, and the provider allowlist as continuing to apply.

The deployment-side change is smaller and very agent-shaped. Vercel's dry-run changelog says vercel deploy --dry previews the framework preset and files included in a deployment before creating one.

vercel deploy --dry --format=json returns:

• Detected framework.
• Included and ignored paths.
• Directory size distribution.
• Largest files.
• File modes.
• Content hashes.

Vercel frames the JSON manifest as a pre-deployment check for agents: verify framework detection, identify unexpected or missing files, flag oversized assets or unusual file modes, update .vercelignore or project config, and rerun the check without uploading code or creating a deployment.