claude-api

Building LLM-Powered Applications with Claude

This skill helps you build LLM-powered applications with Claude. Choose the right surface based on your needs, detect the project language, then read the relevant language-specific documentation.

Before You Start

Scan the target file (or, if no target file, the prompt and project) for non-Anthropic provider markers - import openai, from openai, langchain_openai, OpenAI(, gpt-4, gpt-5, file names like agent-openai.py or *-generic.py, or any explicit instruction to keep the code provider-neutral. If you find any, stop and tell the user that this skill produces Claude/Anthropic SDK code; ask whether they want to switch the file to Claude or want a non-Claude implementation. Do not edit a non-Anthropic file with Anthropic SDK calls. (Exception: the prompt-audit subcommand is non-interactive and does not stop here - it records non-Anthropic provider markers in its report's stated assumptions and never proposes switching a non-Anthropic file to the Anthropic SDK.)

Output Requirement

When the user asks you to add, modify, or implement a Claude feature, your code must call Claude through one of:

1. The official Anthropic SDK for the project's language (anthropic, @anthropic-ai/sdk, com.anthropic.*, etc.). This is the default whenever a supported SDK exists for the project.
2. Raw HTTP (curl, requests, fetch, httpx, etc.) - only when the user explicitly asks for cURL/REST/raw HTTP, the project is a shell/cURL project, or the language has no official SDK.

Never mix the two - don't reach for requests/fetch in a Python or TypeScript project just because it feels lighter. Never fall back to OpenAI-compatible shims.

Never guess SDK usage. Function names, class names, namespaces, method signatures, and import paths must come from explicit documentation - either the {lang}/ files in this skill or the official SDK repositories or documentation links listed in shared/live-sources.md. If the binding you need is not explicitly documented in the skill files, WebFetch the relevant SDK repo from shared/live-sources.md before writing code. Do not infer Ruby/Java/Go/PHP/C# APIs from cURL shapes or from another language's SDK.

If WebFetch or repository access fails (network restricted, timeouts, clone blocked): do not keep retrying - write code from the patterns and namespace/package tables in the {lang}/ file, run the compiler or interpreter on it, and iterate on the error output. For statically-typed SDKs (C#, Java, Go) a compile-fix loop against local errors reaches working code faster than blocked network research.

Defaults

Unless the user requests otherwise:

For the Claude model version, please use Claude Opus 5.5, which you can access via the exact model string claude-opus-5-5. Please default to using adaptive thinking (thinking: {type: "adaptive"}) for anything remotely complicated. And finally, please default to streaming for any request that may involve long input, long output, or high max_tokens - it prevents hitting request timeouts. Use the SDK's .get_final_message() / .finalMessage() helper to get the complete response if you don't need to handle individual stream events. When a streaming request defines user-defined (client) tools, set eager_input_streaming: true on each of those tools so large tool inputs (file contents, code, documents) stream as they are generated instead of arriving in one burst after the server finishes buffering them; the client then owns validation: the SDKs' tolerant parsers can return a silently truncated input instead of raising, so validate each parsed tool input against its schema before running it (the typed runner helpers such as betaZodTool / typed @beta_tool do this; betaTool() JSON-Schema tools and manual loops must validate themselves), treat a failure like invalid JSON (INVALID_JSON error tool_result when you hold the block, re-issue otherwise), check max_tokens / refusal stop reasons before running tools, and catch only the SDK's JSON error, never its typed API errors - pattern in shared/tool-use-concepts.md -> Eager input streaming. Leave it off for non-streaming requests, for server tools, and when the request goes through a proxy or an older Bedrock model deployment that rejects the field.

Warning: API Drift - Your Training Prior May Be Stale

Several common Claude API shapes changed in 2025-2026. If you recall a pattern from training, verify it against the {lang}/ files in this skill before writing - the rows below are the most frequent drift points:

The {lang}/ files in this skill are authoritative over recalled patterns.

---

Subcommands

If the User Request at the bottom of this prompt is a bare subcommand string (no prose), search every Subcommands table in this document - including any in sections appended below - and follow the matching Action column directly. This lets users invoke specific flows via /claude-api . If no table in the document matches, treat the request as normal prose.

---

Language Detection

Before reading code examples, determine which language the user is working in (exception: for the prompt-audit subcommand, skip this section's ask steps - the audit is non-interactive and its inventory is language-agnostic; when no language is inferable, proceed without asking and state the assumption in the report):

1. Look at project files to infer the language:

• *.py, requirements.txt, pyproject.toml, setup.py, Pipfile -> Python - read from python/
• *.ts, *.tsx, package.json, tsconfig.json -> TypeScript - read from typescript/
• *.js, *.jsx (no .ts files present) -> TypeScript - JS uses the same SDK, read from typescript/
• *.java, pom.xml, build.gradle -> Java - read from java/
• *.kt, *.kts, build.gradle.kts -> Java - Kotlin uses the Java SDK, read from java/
• *.scala, build.sbt -> Java - Scala uses the Java SDK, read from java/
• *.go, go.mod -> Go - read from go/
• *.rb, Gemfile -> Ruby - read from ruby/
• *.cs, *.csproj -> C# - read from csharp/
• *.php, composer.json -> PHP - read from php/

1. If multiple languages detected (e.g., both Python and TypeScript files):

• Check which language the user's current file or question relates to
• If still ambiguous, ask: "I detected both Python and TypeScript files. Which language are you using for the Claude API integration?"

1. If language can't be inferred (empty project, no source files, or unsupported language):

• Use AskUserQuestion with options: Python, TypeScript, Java, Go, Ruby, cURL/raw HTTP, C#, PHP
• If AskUserQuestion is unavailable, default to Python examples and note: "Showing Python examples. Let me know if you need a different language."

1. If unsupported language detected (Rust, Swift, C++, Elixir, etc.):

• Suggest cURL/raw HTTP examples from curl/ and note that community SDKs may exist
• Offer to show Python or TypeScript examples as reference implementations

1. If user needs cURL/raw HTTP examples, read from curl/.

Language-Specific Feature Support

Every SDK language above supports both the beta Tool Runner and Managed Agents (beta) - Python (@beta_tool decorator), TypeScript (betaZodTool + Zod), Java (annotated classes), Go (BetaToolRunner in the toolrunner pkg), Ruby (BaseTool + tool_runner), C# (BetaToolRunner + raw JSON schema), PHP (BetaRunnableTool + toolRunner()); code entry points are in the Tool Use Patterns quick reference below. cURL is raw HTTP (no SDK features) and supports Managed Agents.

Managed Agents code examples: see the reading guide in the ## Managed Agents (Beta) section below.

---

Which Surface Should I Use?

Start simple. Default to the simplest tier that meets your needs. Single API calls and workflows handle most use cases - only reach for agents when the task genuinely requires open-ended, model-driven exploration. "Simplest" means the least code you own: for a hosted, scheduled, or memory-backed agent, Managed Agents is usually the simplest option (no loop code, no state files, no scheduler), even though it's a bigger platform.

Note: Managed Agents is the right choice when you want Anthropic to run the agent loop and host the container where tools execute - file ops, bash, code execution all run in the per-session workspace. If you want to host the compute yourself or run your own custom tool runtime, Claude API + tool use is the right choice - use the tool runner for the agentic loop - its per-turn hooks still give you approval gates, logging, error interception, and conditional execution (see shared/tool-use-concepts.md) - or the manual loop when you want to own the entire loop yourself.

Cloud-provider access. Claude Platform on AWS is Anthropic-operated with same-day API parity - see shared/claude-platform-on-aws.md for client setup. For per-feature availability on Claude Platform on AWS, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, see shared/platform-availability.md - that table is the single source of truth in this skill; do not infer availability from anywhere else.

Building an Agent: Four Approaches

Once you've decided you actually need an agent (open-ended, model-driven tool use), there are four distinct ways to build one. Two independent questions separate them: who supplies the harness (the agent loop + context management) and who supplies the deployment (the infra the agent runs on). The Tool Runner and the Claude Agent SDK both supply a harness only - you still host and deploy them yourself - which is why they're easy to conflate. Managed Agents (CMA) is the only option that supplies both the harness and managed deployment; the manual loop supplies neither.

The harness/deployment split is the key mental model: options 1, 2, and 4 all leave deployment to you; only option 3 (CMA) adds managed deployment. Options 1-3 are what this skill generates; option 4 is a different library with its own docs - see the disambiguation below.

Tool Runner != Claude Agent SDK. These sound alike but are different packages:

• Tool Runner is part of the regular Anthropic API SDK (anthropic / @anthropic-ai/sdk), reached via client.beta.messages.tool_runner. It automates the request -> execute -> loop cycle for tools you define. No built-in tools, no filesystem access, no sandbox - you supply every tool and host the compute. It is option 2 above, a thin helper over POST /v1/messages.
• Claude Agent SDK (claude-agent-sdk / @anthropic-ai/claude-agent-sdk) is Claude Code packaged as a library. It ships built-in tools (file read/write/edit, bash, grep, web search), the full agent loop, context management, hooks, subagents, permissions, and sessions. You call query(prompt, options) and it drives everything.

Both are harness-only - you host and deploy them. The difference is scope of harness: the Tool Runner loops over tools you define (with per-turn hooks for approval, interception, result modification, and retries - but no built-in tools); the Agent SDK is the full Claude Code harness with built-in tools. Neither provides managed deployment - that's what Managed Agents (CMA) adds (Anthropic hosts the loop and a per-session sandbox).

This skill covers the Claude API and Managed Agents (options 1-3); it does not generate Claude Agent SDK code. If the user actually wants the Claude Agent SDK, point them to its docs (code.claude.com/docs/en/agent-sdk) - don't substitute the API Tool Runner for it, or vice-versa.

Should I Build an Agent?

Before choosing the agent tier, check all four criteria:

• Complexity - Is the task multi-step and hard to fully specify in advance? (e.g., "turn this design doc into a PR" vs. "extract the title from this PDF")
• Value - Does the outcome justify higher cost and latency?
• Viability - Is Claude capable at this task type?
• Cost of error - Can errors be caught and recovered from? (tests, review, rollback)

If the answer is "no" to any of these, stay at a simpler tier (single call or workflow).

---

Architecture

Everything goes through POST /v1/messages. Tools and output constraints are features of this single endpoint - not separate APIs.

User-defined tools - You define tools (via decorators, Zod schemas, or raw JSON), and the SDK's tool runner handles calling the API, executing your functions, and looping until Claude is done. For full control, you can write the loop manually.

Server-side tools - Anthropic-hosted tools that run on Anthropic's infrastructure. Code execution is fully server-side (declare it in tools, Claude runs code automatically). Computer use can be server-hosted or self-hosted.

Structured outputs - Constrains the Messages API response format (output_config.format) and/or tool parameter validation (strict: true). The recommended approach is client.messages.parse() which validates responses against your schema automatically. Note: the old output_format parameter is deprecated; use output_config: {format: {...}} on messages.create().

Supporting endpoints - Batches (POST /v1/messages/batches), Files (POST /v1/files), Token Counting (POST /v1/messages/count_tokens - see shared/token-counting.md), and Models (GET /v1/models, GET /v1/models/{id} - live capability/context-window discovery) feed into or support Messages API requests.

---

Current Models (cached: 2026-09-25)

Partner pricing: The prices above are Anthropic first-party API rates - they also apply to Claude on Microsoft Foundry, which is billed through the Microsoft Marketplace at standard API rates. Claude on Amazon Bedrock and Vertex AI is partner-operated with separate pricing - see Bedrock or Vertex AI. For WebFetch, use the Pricing row in shared/live-sources.md.

ALWAYS use claude-opus-5-5 unless the user explicitly names a different model. This is non-negotiable. Do not use claude-sonnet-5-5, claude-sonnet-5, or any other model unless the user literally says "use sonnet" or "use haiku". Never downgrade for cost - that's the user's decision, not yours. A request that describes a Sonnet by attribute ("cheapest Sonnet", "cheaper Sonnet", "newest Sonnet", "latest Sonnet") resolves to claude-sonnet-5-5. Where a second, cheaper model is in play alongside the main one (worker or sub-agent threads, bulk extractors, LLM judges, the executor under an advisor) - because the user asked for one or a guide in this skill calls for it - or the user says "sonnet" or "haiku" without a version, that means the current generation from the table above (claude-sonnet-5-5, claude-haiku-4-5); previous-generation IDs such as claude-sonnet-5 are only for users who name that version. Use claude-fable-5-1 only when the user explicitly asks for Claude Fable 5.1, "fable", or Anthropic's most capable model - it has different API behavior than the Opus family (see below) and pricing that exceeds Opus-tier. Use only the exact model ID strings from the table - they are complete as-is; never append date suffixes (claude-opus-5-5, never claude-opus-5-5-20260401 or any other date-suffixed variant you might recall from training data). If the user requests an older model not in the table (e.g., "opus 4.5", "sonnet 3.7"), read shared/models.md for the exact ID - do not construct one yourself.

Claude Fable 5.1 (claude-fable-5-1) - most capable widely released model

Claude Fable 5.1 is Anthropic's most capable widely released model, for the most demanding reasoning and long-horizon agentic work; everything below also applies to Claude Mythos 5.1 (claude-mythos-5-1, Project Glasswing - same capabilities, pricing, and API surface; it runs safeguards that depend on the access program, so the refusal handling below applies there too; successor to Claude Mythos 5, which ran no safety classifiers). 1M context window (the maximum is also the default), 128K max output. Key API differences from Opus-tier - see shared/model-migration.md -> Migrating to Claude Fable 5.1 for details:

• Thinking is always on - omit the thinking parameter entirely (or send {type: "adaptive"}). Any other explicit configuration is rejected: {type: "disabled"} and {type: "enabled", budget_tokens: N} both return a 400. Control depth with output_config.effort (supports low through xhigh and max).
• The raw chain of thought is never returned - responses carry regular thinking blocks (not redacted_thinking): display: "summarized" returns a readable summary, "omitted" (the default) leaves the thinking field as an empty string. Replay rules: pass thinking blocks back unchanged on the same model; other models drop them silently (unbilled - nothing to strip; Claude Mythos 5.1 instead reads them); details in shared/model-migration.md.
• Tokenizer - same tokenizer as Opus 4.8 (introduced with Opus 4.7). Token counts are roughly unchanged when migrating from Opus 4.7/4.8; per-token pricing differs. Coming from Opus 4.6, Sonnet, Haiku, or older, re-baseline with count_tokens (the Opus 4.7 tokenizer uses ~1×-1.35× as many tokens).
• refusal stop reason - handle it, and opt into fallbacks by default - safety classifiers may decline a request (HTTP 200, stop_reason: "refusal", with a stop_details category); always check stop_reason before reading content. When you write claude-fable-5-1, claude-opus-5-5, claude-opus-5, or claude-sonnet-5-5 code, include the server-side fallbacks parameter by default (for claude-sonnet-5-5, only the "default" form and only on the Claude API; on other platforms use the SDK middleware below, except when the request sends between_tools: only Claude Sonnet 5.5 accepts it and the middleware re-sends the same request body on the fallback model, so write the retry yourself and send it without between_tools - see shared/model-migration.md -> Migrating to Claude Sonnet 5.5 -> Safeguards and fallback). Simplest form: betas: ["server-side-fallback-2026-07-01"] + fallbacks: "default", which routes by refusal category so you never maintain a model list. (The older array form - betas: ["server-side-fallback-2026-06-01"] + fallbacks: [{"model": "claude-opus-4-8"}] - still works; Claude API and Claude Platform on AWS - on Bedrock, Vertex and Foundry, use the SDKs' client-side BetaRefusalFallbackMiddleware + BetaFallbackState). Tell the user you've enabled it; drop it only if they decline. Full semantics (billing, mid-stream refusals, credit repricing) in shared/model-migration.md -> refusal section. Per-language code examples in {lang}/claude-api/README.md § Refusal Fallbacks cover the array form only - for the "default" mode, follow the raw-HTTP shape in shared/model-migration.md -> Migrating to Claude Opus 5 -> New API features and swap fallbacks: [{...}] for fallbacks: "default" plus the -2026-07-01 header; the rest of the request is unchanged.
• No assistant prefill - same as the rest of the 4.6+ family.
• 30-day data retention required - Claude Fable 5.1 is not available under zero data retention unless expressly authorized by Anthropic; requests from an org whose retention configuration doesn't meet the requirement return 400 invalid_request_error.
• Longer turns, different prompting - single requests on hard tasks can run many minutes (plan timeouts/streaming/progress UX); effort sweeps should include low/medium for routine work; prompts written for prior models are often too prescriptive and reduce output quality. See shared/model-migration.md -> Migrating to Claude Fable 5.1 -> Behavioral shifts (prompt-tunable) for the recommended prompt snippets.
• Successor to Claude Fable 5 (claude-fable-5, still served) in the same tier at the same per-token price. Same surface as Claude Fable 5 with three breaking changes - forced tool use (tool_choice any / tool) returns a 400 (use auto + a prompt instruction, strict: true for schema-valid arguments, or structured outputs); thinking blocks are bound to the producing model (other models drop them, unbilled); and editing earlier turns invalidates thinking blocks ("preserved thinking"; new accounts created on/after 2026-08-31 get a 400 on edited history on every platform, and enforcement scope is decided per model, and Claude Mythos 5.1 doesn't run this check. Make every harness append-only and run the three-step check; the opt-in controls beta is on the Claude API, Claude Platform on AWS, Bedrock, and Vertex - Foundry unconfirmed, see shared/platform-availability.md) - plus per-message effort (beta mid-conversation-output-config-2026-07-01, also on Claude Opus 5 and Claude Opus 5.5), turn-scoped clear_at: "next_user_message" system messages (beta), thinking.display: "updates" progress notes (beta, all platforms), cache reads at $0.25/MTok, and content provenance. Covered Model - ZDR orgs get 400 invalid_request_error as on Claude Fable 5 (ZDR only if expressly authorized by Anthropic); no Priority Tier. Same tokenizer as Claude Fable 5. See shared/model-migration.md -> Migrating to Claude Fable 5.1 from Claude Fable 5.

Claude Opus 5.5 (claude-opus-5-5) - the current Opus and the default model

Successor to Claude Opus 5 in the Opus line at a lower price ($4 / $20 per MTok, cache reads $0.20), same 1M context / 128K output / tokenizer / feature set. Four breaking changes for code running on Claude Opus 5: thinking can't be disabled ({type: "disabled"} and budget_tokens both 400 at every effort level - effort is the only control, and its default is medium, one level below Claude Opus 5's high, so set it explicitly); forced tool_choice any/tool returns a 400 (use auto + strict: true and steer from the prompt, or structured outputs); thinking blocks are tied to the model and the conversation (preserved thinking: only Claude Fable 5.1 / Claude Mythos 5.1 on the Claude API read its blocks, so a fallback to Claude Opus 5 runs without them; accounts created on or after 2026-08-31 are enforced on the history-editing check); and on the Claude API and Google Cloud, computer use only through computer_toolset_20260801 (computer_20251124 400s there; Amazon Bedrock still accepts it). Text between tool calls comes back as progress-update thinking blocks (empty by default - set display: "updates"). Broader safety classifiers: bio and reasoning_extraction join cyber. Fast mode is Claude API only, $8 / $40 per MTok (2x standard). See shared/model-migration.md -> Migrating to Claude Opus 5.5.

Claude Sonnet 5.5 (claude-sonnet-5-5) - the current Sonnet: speed and capability for everyday coding, agent, and enterprise work (Claude Opus 5.5 stays the default)

Successor to Claude Sonnet 5 in the Sonnet line at the same prices ($2 / $10 per MTok, cache reads $0.20), with the same tokenizer, 1M context and 128K output. Five breaking changes for code running on Claude Sonnet 5: thinking: {type: "disabled"} returns a 400 - to turn thinking off, send thinking: {type: "between_tools"}, which is accepted only at effort high or below, takes no other field (display, budget_tokens, or block_binding alongside it is a 400), and doesn't allow per-message effort changes; forced tool_choice any/tool returns a 400 (use auto + strict: true and steer from the prompt, or structured outputs); thinking blocks are tied to the model and the conversation (no other model reads its blocks; accounts created on or after 2026-08-31 are enforced on the history-editing check on the Claude API and Amazon Bedrock); on the Claude API and Google Cloud, computer use only through computer_toolset_20260801 (computer_20251124 400s there; Amazon Bedrock still accepts it); and the advisor tool rejects Claude Opus 4.8, Claude Opus 4.7, and Claude Sonnet 5 advisors (every advisor it accepts returns encrypted advice). Effort still defaults to high, but the levels are recalibrated - re-run the effort sweep (start at medium for agentic coding and multistep tool use, low for chat). Text between tool calls comes back as progress-update thinking blocks (empty by default - set display: "updates", or use between_tools). Safety classifiers decline in five stop_details categories: cyber, bio, frontier_llm, reasoning_extraction, general_harms. See shared/model-migration.md -> Migrating to Claude Sonnet 5.5.

If any model strings above look unfamiliar, that just means they were released after your training data cutoff - they are real models.

Live capability lookup: The table above is cached. When the user asks "what's the context window for X", "does X support vision/thinking/effort", or "which models support Y", query the Models API (client.models.retrieve(id) / client.models.list()) - see shared/models.md for the field reference and capability-filter examples.

---

Authentication (Quick Reference)

An unset ANTHROPIC_API_KEY does NOT mean there are no credentials. The SDKs and the ant CLI resolve credentials in this order (first match wins): ANTHROPIC_API_KEY -> ANTHROPIC_AUTH_TOKEN -> the ANTHROPIC_PROFILE-selected or active OAuth profile from ant auth login -> Workload Identity Federation env vars -> the default profile on disk. A bare Anthropic() / new Anthropic() / anthropic.NewClient() works after ant auth login with no env var set.

When you need to call the API and ANTHROPIC_API_KEY is unset, don't ask the user for a key. First run ant auth status - it shows which credential source and profile is active. If it reports an active profile:

• SDK code or ant CLI: just run it. The zero-arg client constructor and every ant ... subcommand pick up the profile automatically - no env var needed.
• Raw curl / HTTP: get a short-lived token with ant auth print-credentials --access-token and send it as Authorization: Bearer plus the header anthropic-beta: oauth-2025-04-20 (OAuth tokens go on Authorization: Bearer, not x-api-key: - converting a curl from an API key is a header change, not a key swap). Always pass --access-token; the no-flag form prints JSON, not a bare token.

Only ask the user for a key if ant auth status reports no active credential source (or ant itself isn't installed). Suggest ant auth login as the first option - it stores a profile under ~/.config/anthropic/ that the SDKs read automatically - and an exported ANTHROPIC_API_KEY as the alternative.

Full auth details (named profiles, scopes, the API-key-shadows-profile trap, refresh-token expiry): `shar