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. ## Defaults Unless the user requests otherwise: Use Claude Opus 5 via the exact model string `claude-opus-5` (the app-building default: $5/$25, adaptive thinking on by default, near-Fable capability at Opus price). Effort **defaults to `high`**; set `output_config: {effort: "xhigh"}` for coding and agentic tasks and `max` for the hardest problems. Re-sweep effort on your evals — low/medium often hold quality at fewer tokens than on 4.8. 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 to reach for Claude Fable 5** (`claude-fable-5`, released 2026-06-09 — Anthropic's most capable widely-released model): the hardest, longest-running, most-ambiguous workloads (multi-day autonomous agents, codebase-scale migrations, first-shot complex systems, dense-image vision). It is **2× the price** ($10/$50), and differs from Opus 5 at the API level — see the Fable 5 note below. For most app-building, Opus 5 remains the right default; opt into Fable 5 deliberately when the task is at the top of your difficulty range, and **keep Opus 5 as the fallback** (Fable's safety classifiers refuse offensive-cyber / bio-life-sciences / reasoning-extraction requests with `stop_reason: "refusal"`, and you retry those on Opus 5). > > **Claude Fable 5 API differences (read before using it):** adaptive thinking is **always on and the only mode** (no `disabled`, no `budget_tokens`, no `task_budget` thinking budgets beyond the beta task-budgets header); **raw CoT is never returned** — `thinking.display` is `"omitted"` by default, set `"summarized"` for summaries, and **never instruct the model to echo/explain its reasoning as response text** (trips the `reasoning_extraction` classifier → refusal/fallback). Effort low→max, default `high` (lower effort often exceeds prior-model `xhigh`). Turns run longer by default — raise client timeouts and stream. Use the `fallbacks` param (beta) or SDK middleware to auto-retry refusals on `claude-opus-5`. Covered Model: 30-day retention, no zero-data-retention. > **Opus 5 migration note** (2026-07-24): model id `claude-opus-5`, same $5/$25 as 4.8. Thinking is **on by default**; disabling thinking is only allowed at effort `high` or below. Prompting deltas: longer default verbosity (prompt for concision), stronger self-verification (remove redundant "verify again" scaffolding), more subagent-eager (cap delegation). Cyber-classifier refusals fall back to `claude-opus-4-8` by default; Fable bio blocks route to Opus 5. Full guide: [prompting-claude-opus-5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5) · [migration](https://platform.claude.com/docs/en/about-claude/models/migration-guide#migrating-from-claude-opus-4-8-to-claude-opus-5). > > **Genuinely new in 4.8:** > - **Effort defaults to `high`** on all surfaces (API + Claude Code). Set `xhigh` explicitly for coding/high-autonomy work. > - **Effort levels recalibrated** vs 4.7: `medium` allows somewhat more thinking, `high` somewhat less, `xhigh` substantially more. Re-baseline cost/latency at your chosen level before tuning. > - **Mid-conversation system messages:** 4.8 accepts `role: "system"` messages *immediately after a user turn* in the `messages` array (subject to placement rules) — earlier models including 4.7 reject this with 400. Keeps prompt-cache hits on earlier turns instead of rebuilding history. Top-level `system` field is still for from-the-start instructions. > - **Refusal `stop_details`** (present since 4.7) is now publicly documented: refusals carry a refusal *category* alongside the `refusal` stop reason. No beta header, no opt-out. > - **Lower prompt-cache minimum:** 1,024 tokens (down from 4.7's higher floor) — short prompts that couldn't cache on 4.7 now can. > - Materially more honest: flags uncertainty, ~4× less likely than 4.7 to let its own code flaws pass unremarked. 1M context is the default (no beta header); fast mode 2.5× speed at $10/$50. --- ## Language Detection Before reading code examples, determine which language the user is working in: 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/` 2. **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?" 3. **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." 4. **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 5. **If user needs cURL/raw HTTP examples**, read from `curl/`. ### Language-Specific Feature Support | Language | Tool Runner | Agent SDK | Notes | | ---------- | ----------- | --------- | ------------------------------------- | | Python | Yes (beta) | Yes | Full support — `@beta_tool` decorator | | TypeScript | Yes (beta) | Yes | Full support — `betaZodTool` + Zod | | Java | Yes (beta) | No | Beta tool use with annotated classes | | Go | Yes (beta) | No | `BetaToolRunner` in `toolrunner` pkg | | Ruby | Yes (beta) | No | `BaseTool` + `tool_runner` in beta | | cURL | N/A | N/A | Raw HTTP, no SDK features | | C# | No | No | Official SDK | | PHP | No | No | Official SDK | --- ## 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. | Use Case | Tier | Recommended Surface | Why | | ----------------------------------------------- | --------------- | ------------------------- | --------------------------------------- | | Classification, summarization, extraction, Q&A | Single LLM call | **Claude API** | One request, one response | | Batch processing or embeddings | Single LLM call | **Claude API** | Specialized endpoints | | Multi-step pipelines with code-controlled logic | Workflow | **Claude API + tool use** | You orchestrate the loop | | Custom agent with your own tools | Agent | **Claude API + tool use** | Maximum flexibility | | AI agent with file/web/terminal access | Agent | **Agent SDK** | Built-in tools, safety, and MCP support | | Agentic coding assistant | Agent | **Agent SDK** | Designed for this use case | | Want built-in permissions and guardrails | Agent | **Agent SDK** | Safety features included | > **Note:** The Agent SDK is for when you want built-in file/web/terminal tools, permissions, and MCP out of the box. If you want to build an agent with your own tools, Claude API is the right choice — use the tool runner for automatic loop handling, or the manual loop for fine-grained control (approval gates, custom logging, conditional execution). ### Decision Tree ``` What does your application need? 1. Single LLM call (classification, summarization, extraction, Q&A) └── Claude API — one request, one response 2. Does Claude need to read/write files, browse the web, or run shell commands as part of its work? (Not: does your app read a file and hand it to Claude — does Claude itself need to discover and access files/web/shell?) └── Yes → Agent SDK — built-in tools, don't reimplement them Examples: "scan a codebase for bugs", "summarize every file in a directory", "find bugs using subagents", "research a topic via web search" 3. Workflow (multi-step, code-orchestrated, with your own tools) └── Claude API with tool use — you control the loop 4. Open-ended agent (model decides its own trajectory, your own tools) └── Claude API agentic loop (maximum flexibility) ``` ### 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. Use `output_config: {format: {...}}` on `messages.create()`. **Supporting endpoints** — Batches (`POST /v1/messages/batches`), Files (`POST /v1/files`), and Token Counting feed into or support Messages API requests. --- ## Current Models (cached: 2026-06-09) | Model | Model ID | Context | Input $/1M | Output $/1M | Notes | | ----------------- | ------------------- | -------------- | ---------- | ----------- | ----- | | Claude Fable 5 | `claude-fable-5` | 1M | $10.00 | $50.00 | Most capable; adaptive-only, summarized-CoT-only, safety classifiers → fallback to Opus 5. | | Claude Opus 5 | `claude-opus-5` | 1M | $5.00 | $25.00 | App-building default. | | Claude Sonnet 4.6 | `claude-sonnet-4-6` | 200K (1M beta) | $3.00 | $15.00 | | | Claude Haiku 4.5 | `claude-haiku-4-5` | 200K | $1.00 | $5.00 | | `claude-mythos-5` (same weights as Fable 5, classifiers lifted) exists but is Project-Glasswing-only — not generally callable. **Default to `claude-opus-5` for app-building unless the user names another model or the task is at the top of your difficulty range (then `claude-fable-5`, with Opus 5 as the fallback).** Never downgrade for cost on the user's behalf — that's their decision, not yours. **Use only the exact model ID strings from the table above.** Do not append date suffixes. If the user requests a model not in the table, read `shared/models.md` or WebFetch the Anthropic Models Overview — do not construct an ID yourself. A note: if any of the model strings above look unfamiliar to you, that's to be expected — that just means they were released after your training data cutoff. Rest assured they are real models; we wouldn't mess with you like that. --- ## Thinking & Effort (Quick Reference) **Adaptive thinking is off by default on Opus 5.** Set it explicitly: `thinking: {type: "adaptive"}`. Claude then decides when and how much to think. Adaptive thinking also automatically enables interleaved thinking (no beta header needed). `budget_tokens` returns a 400 error on Opus 5 — do not use it; do not fall back to an older model just because the user asks for a "thinking budget." **Effort levels (GA, no beta header):** `output_config: {effort: "low"|"medium"|"high"|"xhigh"|"max"}`. Opus 5 added `xhigh` between `high` and `max`. - `xhigh` — **start here for coding and agentic use cases.** - `high` — minimum for most intelligence-sensitive work. - `medium` — cost-sensitive tasks where intelligence tradeoff is acceptable. - `low` — short, scoped, latency-sensitive tasks only. Opus 5 respects low strictly — it will under-think on complex problems at this level. If you see shallow reasoning, raise effort; don't prompt around it. - `max` — deepest reasoning; can overthink on simpler tasks. Test before committing. With `xhigh` or `max` effort, start with `max_tokens: 64000` or higher — 4.8 uses more output tokens at these levels. **Thinking display:** `thinking.display` defaults to `"omitted"` on Opus 5 — thinking blocks appear in the stream but their `thinking` field is empty. Set `thinking: {type: "adaptive", display: "summarized"}` to restore visible reasoning progress. Important for UIs that show thinking to users — otherwise the UI appears frozen until first output token. **Sampling parameters are removed.** `temperature`, `top_p`, and `top_k` return 400 on Opus 5. Omit them from request payloads. Use prompting to guide behavior. **Task budgets (beta):** For agentic loops, set an advisory token cap the model uses to pace itself: ``` output_config = {"effort": "high", "task_budget": {"type": "tokens", "total": 128000}} ```