Support Anthropic's server-side code execution tool (code_execution_20250825)

[skaheide]

The request

Support Anthropic's server-side code execution tool (code_execution_20250825) on the Anthropic endpoint, alongside the web_search_20250305 integration that already exists — ideally exposed per modelSpec the way webSearch is, rather than as a global switch.

Current state

Anthropic ships several server-side tools on the Messages API. LibreChat wires exactly one of them today: web_search_20250305 is the only Anthropic *_2025xxxx tool identifier present in the shipped image, and code_execution_2025* does not appear anywhere in this repository.

Why this doesn't compete with the built-in Code Interpreter

The bundled Code Interpreter is a genuinely good piece of engineering, and where the hardware allows it, it stays the better option — code and data never leave the operator's own infrastructure. This request isn't about replacing it.

The problem is that a large group of self-hosters can't run it in a form its own authors consider safe. All three Compose files in ClickHouse/code-interpreter require /dev/kvm, and its README is unusually candid about the alternative:

NsJail-only mode shares the host kernel and provides meaningfully weaker isolation: it is appropriate for local development, not for executing untrusted code from people you don't trust.

Shared-vCPU cloud instances generally don't expose /dev/kvm. Measured on a Hetzner Cloud CX instance: no /dev/kvm device, no vmx/svm CPU flags. The same applies to comparable tiers at other providers. For those deployments the real choice isn't "built-in interpreter vs. Anthropic's" — it's "code execution or none", unless the operator rents dedicated hardware purely to host a sandbox.

Supporting Anthropic's server-side tool would close that gap for KVM-less deployments without taking anything away from operators who can run the hardened sandbox.

Shape

It reuses the plumbing web search already goes through — same tools array, same server_tool_use / tool-result flow:

{
  "type": "code_execution_20250825",
  "name": "code_execution"
}

File input and output run over the Files API via a container_upload content block with the anthropic-beta: files-api-2025-04-14 header — which this repository already references elsewhere.

Docs: https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool

Two notes that may matter for prioritisation

• Anthropic states code execution incurs no additional charge beyond normal token cost when web_search_20260209 / web_fetch_20260209 or newer are present in the same request. For anyone already running web search, the added cost would be token cost only.
• PR feat: Support built-in server-side tools for custom endpoints (xAI x_search, web_search) #12551 introduces a generic builtInTools mechanism for custom endpoints, using xAI as the example — where code_execution is among the supported built-ins. It doesn't cover the first-party Anthropic endpoint and has been idle since April. Mentioning it in case the two are worth reconciling rather than solving twice.

Happy to test against a self-hosted instance if that's useful.

[PauloBrMello]

Strong +1 — with a working trace and one correction that makes the ask smaller.

It already works end-to-end on the API side. I ran code_execution_20260120 against Claude Sonnet 5 through an OpenAI-compatible gateway sitting in front of the Anthropic Messages API. The model ran bash_code_execution, confirmed the container ships reportlab 4.2.2, wrote a script via the text editor tool and produced a real file (prompt was in Portuguese, hence the output):

PDF gerado com sucesso em: /tmp/relatorio.pdf
-rw-r--r-- 1 root root 2386 … /tmp/relatorio.pdf: PDF document, version 1.4, 1 pages

Block sequence returned: server_tool_use → bash_code_execution_tool_result → text_editor_code_execution_tool_result → … → text. The Anthropic Files API also responds normally through the same path. So nothing on the provider side is blocking this.

One correction, in your favour: you mention code_execution_2025* doesn't appear anywhere in the repository. In the shipped v0.8.7 image it does — just not in the main repo, but in the bundled @librechat/agents (3.2.46), src/llm/anthropic/index.ts:

const ANTHROPIC_TOOL_BETAS = {
  // …
  code_execution_20250825: 'code-execution-2025-08-25',
  // …
};

and getToolBetas(tools) already scans the tools array and appends the matching beta header. So the beta-header half is done — any tool of that type placed in tools would already be sent with the correct header. That makes this a smaller change than it looks.

What's actually missing is only the trigger. In packages/api/src/endpoints/anthropic/llm.ts the tools array is assembled in code:

let enableWebSearch = mergedOptions.web_search;   // ~L180
// …
const tools = [];                                  // ~L356
if (enableWebSearch) {
  tools.push({ type: 'web_search_20250305', name: 'web_search' });
  // …
}

and tPresetSchema exposes only tools, artifacts, web_search — there's no code_execution field to set from a modelSpec. Mirroring the existing block (if (enableCodeExecution) tools.push({ type: 'code_execution_20250825', name: 'code_execution' })) plus the schema field would light up execution and its text output; surfacing generated files for download is the separate, larger piece.

Demand data point: in a corporate deployment (~200 users onboarding), the single most repeated unmet request in the first week was a downloadable document — one user asked three times in the same conversation ("generate a PDF I can send to the board", then falling back to "can you generate an .html?"). The model correctly answers it has no file-creation tool. We enabled Artifacts as a stopgap (formatted HTML → browser print-to-PDF), which covers presentation documents but not spreadsheets or real file outputs.

On your KVM point — worth adding that it isn't only a cloud-tier problem: the operational cost is also non-trivial. The official Compose is 8 services (api, service-worker, egress_gateway, tool_call_server, sandbox-runner, file_server + Redis + MinIO), 6 of them built from source with no published images, production path via Helm. For an on-prem single-host deployment whose policy is "pinned image tags only, never local builds", that's a hard blocker independent of KVM — while the provider-side sandbox needs zero infrastructure.

Happy to test a branch against our deployment if that helps.

[skaheide]

@danny-avila would you take a PR for this? I'd keep the first version small: a code_execution toggle next to web_search on the Anthropic endpoint (schema field, tools array, modelSpec support) and leave file downloads for a follow-up. Happy to open an issue and pick it up if it fits the roadmap.