Claude Agent Skills left beta on 19 August 2026, and a Skill still runs 3 different ways

Summary. Anthropic's Claude Platform release notes for 19 August 2026 put Agent Skills and the Skills API (/v1/skills) out of beta: requests no longer need the skills-2025-10-02 header, including Messages API requests that load Skills through the container parameter. That is the whole change. It does not make a Skill portable. As of 24 August 2026 the Agent Skills overview still states that custom Skills do not sync across surfaces, that Skills on the Claude API run in a sandboxed container with no network access and no runtime package installation, and that the same Skill running under Claude Code has full network access instead. The API container is Python 3.11 with 5 GiB RAM, 5 GiB disk and 1 CPU, billed at $0.05 per hour per container after 1,550 free hours per organization per month. A Skill is now a supported artefact. It is still not a portable one.

What actually changed on 19 August 2026

One header retired. Agent Skills and the /v1/skills endpoints no longer require anthropic-beta: skills-2025-10-02, and neither do Messages API requests that reference Skills through container. Requests that still send the header continue to work unchanged. The same release note batch also took the Files API and the computer use tool out of beta, so this was a general beta-clearing pass rather than a Skills-specific rework.

Nothing in the request shape moved. You still specify Skills in the container parameter with a type and skill_id, optionally pinning version, and you can include up to 20 Skills per request. Pre-built Skills are referenced by the ids pptx, xlsx, docx and pdf. Custom Skills you upload through /v1/skills are shared workspace-wide, so every member of the workspace can use them.

The prerequisite has not moved either. Using Skills through the Claude API requires the code execution tool, whose container the Skills run inside. That single dependency is where most of the surprise lives.

Three surfaces, three runtimes

The overview page is direct about it: "Custom Skills do not sync across surfaces." Skills uploaded to claude.ai must be uploaded separately to the API. Skills uploaded through the API are not available on claude.ai. Claude Code Skills are filesystem-based and separate from both. There is no export path documented between them, so a Skill that exists in three places exists as three copies you keep in step yourself.

Worse for anyone planning a single authoring standard, the runtime underneath differs by surface.

Read the bottom-right cell twice if you run a large claude.ai deployment. The documentation states plainly that claude.ai does not support centralized admin management or org-wide distribution of custom Skills. A 400-person organization standardising on an internal Skill has 400 uploads to organise, or it moves that work to the API.

The line the docs put next to itself

The architecture section sells bundled content hard: "No practical limit on bundled content: Files don't consume context until accessed, so Skills can include comprehensive API documentation, large datasets, or extensive examples. There's no context penalty for bundled content that isn't used."

That is true about context and misleading about capability. Roughly forty lines later the same page says Skills on the API run in a sandbox with no network access and no runtime package installation, and the limitations section repeats it: "Pre-configured dependencies only." You can bundle a 200-file reference corpus. You cannot bundle a dependency. A Skill whose SKILL.md instructs Claude to pip install anything works on a developer's laptop under Claude Code and fails on the API, and the failure surfaces as the model improvising around a missing import rather than as a clean error.

The practical test is short. Read your SKILL.md and every script it references. If any of them makes an outbound request or installs a package, that Skill is Claude Code only until you rewrite it.

What the API container actually gives you

The code execution container is documented precisely, and the numbers are the ones to plan against.

Pre-installed libraries cover most document and analysis work: pandas, numpy, scipy, scikit-learn and statsmodels for data; matplotlib and seaborn for charts; pyarrow, openpyxl, xlsxwriter, xlrd, pillow, python-pptx, python-docx, pypdf, pdfplumber, pypdfium2, pdf2image, pdfkit, tabula-py, reportlab and Img2pdf for files; sympy and mpmath for maths; tqdm, python-dateutil, pytz and joblib as utilities. Command-line tools include unzip, unrar, 7zip, bc, ripgrep, fd and sqlite. If your Skill needs something outside that list, redesign it or move the work outside the container.

Three billing details decide whether Skills are cheap or annoying at volume. Execution time has a minimum of 5 minutes, so a Skill that finishes in twelve seconds still bills five minutes. If files are included in the request, execution time is billed even when the tool is never called, because files are preloaded onto the container. And code execution is free entirely when web_search_20260209 or web_fetch_20260209 or later is in the same request, which makes the cheapest Skills-heavy request shape a slightly counter-intuitive one.

The container expiry trap

Containers expire 30 days after creation. After about 5 minutes of inactivity a container is checkpointed, and sending a request with its ID inside the 30-day window restores it. Then comes the sentence worth putting in a code comment: the expires_at timestamp in the response's container object "is a shorter rolling value and doesn't report the 30-day limit."

So the field you would naturally use to decide whether to reuse a container tells you the wrong number. Scheduling reuse off expires_at will make you rebuild state you did not need to rebuild. Track creation time yourself, and handle the expired case by re-sending without the container parameter to get a fresh one. Containers are also scoped to the workspace of the API key, the same as the Files API, so a key rotation across workspaces loses the reuse path entirely.

Naming rules that break existing Skills

The Skills API enforces authoring rules that will reject a proportion of Skills written informally during the beta. A name is limited to 64 characters, must contain only lowercase letters, numbers and hyphens, cannot contain XML tags, and cannot contain the reserved words "anthropic" or "claude". A description must be non-empty, is limited to 1024 characters, and cannot contain XML tags. The description has to say both what the Skill does and when Claude should use it, because that text is what the model sees at startup to decide whether to trigger the Skill at all.

The reserved-word rule is the one that catches teams: any internal Skill named along the lines of claude-ticket-triage needs renaming before upload, and the rename changes the reference in every request that pins it.

Security, and why GA does not lower the bar

The overview carries a warning that survived the move out of beta: use Skills only from trusted sources, because a Skill can direct Claude to invoke tools or execute code in ways that do not match its stated purpose. The documentation calls out Skills that fetch data from external URLs as particularly risky, since fetched content can carry instructions, and notes that a trustworthy Skill can be compromised when its external dependencies change.

On the Claude API that risk is partly contained by the sandbox itself: no network means no exfiltration path out of the container. On Claude Code it is not contained at all, because Skills there have the same network access as any other program on the user's machine. If you are adopting third-party Skills, the surface decides the threat model, and the surface with the friendlier developer experience is the permissive one. Review bundled scripts before use, not after. This is the same review discipline that applies to any AI coding agent harness that can execute code on a developer machine.

Who should act, and what to do this week

If you run Skills only through the Claude API, the GA change costs you nothing and you can drop the beta header at your convenience. If you author on Claude Code and deploy on the API, audit each Skill for network calls and package installs now, because the failure mode is silent degradation rather than an error. If you standardised on claude.ai, accept that per-user upload is the only distribution mechanism documented and plan the move to workspace-scoped API Skills if that does not scale.

For governance teams, the useful framing is that a Skill is not one artefact with one owner. It is up to three copies with three different runtime privileges, and only the API copy is centrally controlled. That is the same governance question that agent skills governance for platform teams raises in other vendors' tooling, and the answer is usually a single authoring repository with a per-surface build step rather than three hand-maintained copies.

India-specific considerations

For Indian teams processing personal data under the Digital Personal Data Protection Act 2023, the surface split has a direct consequence. The Claude API container has no outbound network access and is scoped to the workspace of the API key, which makes it the easier surface to reason about for a data-flow map: content enters through the request and the Files API and cannot leave through the Skill. Claude Code Skills, with full network access on an engineer's machine, sit outside that boundary and need to be treated as endpoint software in your assessment rather than as platform configuration. Where a Skill handles personal data, keeping it on the API surface removes an entire category of argument during review.

What is still unknown

Anthropic has published no cross-surface sync mechanism, no export or import path between claude.ai, the API and Claude Code, and no roadmap entry for org-wide distribution of custom Skills on claude.ai. The pre-installed library list is documented but not versioned on the page, so a Skill pinned to a specific pandas behaviour has no published guarantee. Until those gaps close, the safe assumption is that portability is your build problem, not the platform's.

FAQ

How eCorpIT can help

eCorpIT builds and reviews agent tooling for engineering organisations, including Skill authoring standards that survive the move from a developer laptop to a locked-down API sandbox. We are ISO 27001:2022 certified and CMMI Level 5 assessed, and we design agent deployments aligned with DPDP Act 2023 data-flow requirements. If your team is standardising Skills across Claude Code and the Claude API, book an agent tooling review and we will map the per-surface constraints against what you have already written.

References

1. Claude Platform release notes, 19 August 2026

1. Agent Skills overview

1. Using Agent Skills with the Claude API

1. Code execution tool

1. Agent Skills quickstart

1. Skill Management API reference

1. Claude Files API

1. Beta headers

1. Programmatic tool calling

1. Skill authoring best practices

1. Claude API and data retention

1. Claude API overview

Last updated: 24 August 2026.