Claude, choosing a model, the API, and real costs

Claude, choosing a model, the API, and real costs

Claude is Anthropic's family of language models, used both through a consumer application and through an API inside products. The current generation carries the number 5 and offers a one million token context window, roughly seven hundred pages of text in a single call. This text covers development work: model choice, costs, and the mechanisms that bring those costs down.

Where Claude actually gets used

Three surfaces and three different purposes, easy to confuse when hunting for documentation.

The Claude application is a chat interface for end users, handy for sanity checks and irrelevant to integration. The Claude API means HTTP calls with a key, the layer you build a product on. Claude Code is a command line tool and editor extension where the model works on your repository: reading files, running commands, applying changes.

That split matters when planning spend, because each surface bills differently. The application and Claude Code come from a subscription, the API from tokens. A team that prototypes an idea in the app and then ships it through the API should price the second scenario separately.

A fourth route runs through third party tools connected with your own key. The self hosted assistant OpenClaw, formerly Clawdbot runs on your own hardware and bills every call to your API account, so its cost sits outside any subscription and grows with the number of tasks you hand over. Broad permissions add a second risk: a misread instruction here ends in an action taken rather than merely an unhelpful answer.

Models and which to pick

The selection rule is short. Sonnet handles most production work at a reasonable price. Opus is for hard reasoning, long agentic tasks, and code work where the quality gap justifies the price gap. Fable is the top tier for the hardest, longest horizon tasks. Haiku suits classification, tagging, and bulk processing where throughput matters.

One discount is in force as this is written and is worth knowing because it expires: Sonnet 5 is billed at 2 USD input and 10 USD output through 31 August 2026, with the table rates taking effect on 1 September. When budgeting for a year, price the two periods separately rather than multiplying the current rate by twelve.

Write the identifiers exactly as shown. These are complete names rather than shorthand, so appending a date produces a 404. Haiku is the exception, with a dated variant as well.

Your first call

pip install anthropic
export ANTHROPIC_API_KEY=sk-ant-...

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    system="Answer concisely, without preamble.",
    messages=[{"role": "user", "content": "Summarise the contract below in five points: ..."}],
)

print(response.content[0].text)

TypeScript follows the same shape and drops into a Next.js API route without friction.

import Anthropic from '@anthropic-ai/sdk'

const client = new Anthropic()

const result = await client.messages.create({
  model: 'claude-opus-5',
  max_tokens: 16000,
  messages: [{ role: 'user', content: question }]
})

Two things deserve attention from the start. The max_tokens parameter is required and caps response length, so too low a value cuts text off mid sentence. For longer responses use streaming, since a plain call with a high limit can hit the connection timeout.

Adaptive thinking and the effort parameter

How you control the model's deliberation changed in this generation, and it is the most common source of errors when migrating older code.

Previously you supplied a token budget for thinking. Now the model decides that itself, and you steer overall spend through effort. The old parameter returns a 400 on current models, as do temperature, top_p, and top_k, which these models do not accept.

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=32000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": question}],
)

Effort levels are low, medium, high, xhigh, and max, with high as the default. Coding and agentic work do well at xhigh, routine work at low or medium, which perform surprisingly well in this generation and cut both cost and latency.

A tuning order that saves money: lower the effort first, and only then consider a cheaper model. Sonnet at high effort often beats Opus at low effort, and the difference only shows on your own test set.

Prompt caching, or not paying twice

This is the single most effective way to cut the bill and the one most often skipped. A repeated chunk of the prompt, a system instruction, product documentation, or terms of service, can be cached and billed at a fraction of the rate.

client.messages.create(
    model="claude-opus-5",
    max_tokens=8000,
    system=[{
        "type": "text",
        "text": LARGE_INSTRUCTION,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": question}],
)

A cache read costs roughly a tenth of the input price. A cache write costs 1.25 times the rate with a five minute cache and double with an hourly one. The five minute variant pays off from the second call, the hourly one from the third.

The governing rule: caching matches on a prefix. Changing a single byte anywhere before the cache breakpoint invalidates everything after it. A date in the system instruction, a session identifier placed at the start, or a tool list built in random order can therefore defeat the whole mechanism with no error message.

One number tells you whether it works. The usage.cache_read_input_tokens field in the response reports how many tokens came from cache. If it stays at zero across repeated requests, something is invalidating the prefix.

Batch API and the rest of the cost levers

Work that need not return immediately goes out as a batch at half the rate.

batch = client.messages.batches.create(requests=[
    {"custom_id": f"ticket-{i}", "params": {
        "model": "claude-haiku-4-5",
        "max_tokens": 512,
        "messages": [{"role": "user", "content": text}],
    }}
    for i, text in enumerate(tickets)
])

One batch holds up to a hundred thousand requests, results are usually ready within an hour and at worst within a day, and they stay available for twenty nine days. Results come back in any order, so match them by custom_id and never by position in the list.

The third factor is response length. Output costs five times more than input, so an instruction constraining response format trims the bill more effectively than shortening the prompt. Asking for five bullet points instead of an essay is usually a multiple, not a margin.

It also pays to price a single run before the process goes permanent. Take ten real cases, sum input and output tokens from the usage field in the response, multiply by the rate and by expected daily volume. That one number says more than any calculator, because it reflects your prompts rather than an averaged conversation.

The fourth is matching the model to the step rather than to the whole process. Ticket classification goes to Haiku, the customer reply to Sonnet, the hard analysis to Opus. One model for everything almost always means overpaying in one place and underdelivering in another.

Tools and structured responses

Integration with code needs a predictable response shape. A schema enforces it on the model side, with no regular expression parsing.

result = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=1024,
    output_config={"format": {"type": "json_schema", "schema": TICKET_SCHEMA}},
    messages=[{"role": "user", "content": f"Classify: {text}"}],
)

Tool calling works similarly: you describe the functions, the model states which to call and with what arguments, and you execute it on your side and return the result. For longer flows it makes sense to wire this through LangChain, which normalises the interface across providers.

For tools on your side, the description drives accuracy more than anything else. The model sees only the name, the description, and the argument schema, so a sentence stating plainly when to call the tool beats one stating merely what it does. A description like "Call this when the user asks about current order status by number" lifts accuracy more than any change to the system prompt.

Server side tools are a separate layer: web search, page fetching, and code execution in a sandbox. You declare them in the tool list and they run without your involvement, which shortens the code while moving some control to the vendor.

Long context and when to actually use it

A million tokens tempts you to drop entire documentation into the prompt instead of building retrieval. Sometimes that is the right call, sometimes it is the most expensive possible way to answer a question.

It pays off for one off analysis: reading a three hundred page contract, comparing two specification revisions, going through a log dump from an outage. You do it once, the cost is one off, and quality beats chunk retrieval because the model sees the whole thing and catches contradictions between distant sections.

It does not pay off in an application answering user questions. A hundred thousand context tokens per question, across a thousand questions a day, produces a bill against which a vector database comes out many times cheaper. Latency adds to that, since the model processes the entire input before it starts answering.

There is a third variant, most often overlooked: long context plus caching. If the same large document returns across many questions, caching it brings the cost of later calls down to a tenth. With a fixed document set and a few hundred questions a day, that arrangement is often simpler and cheaper than maintaining a separate vector database.

With very long input, mind where content sits. Put the question at the end and the most important passages at the start or the end, not in the middle.

Claude against the alternatives

Practical advice: do not bind business logic to one vendor. A thin layer with one call interface lets you compare models on your own data, which is the only meaningful test. Public benchmarks measure tasks that rarely resemble yours.

Common mistakes

The first is porting old code unchanged. The temperature, top_p, and top_k parameters, along with the thinking token budget, return a 400 on current models. Remove them and steer behaviour through instructions and effort.

The second is prefilling the start of the assistant's response. That technique no longer works and returns an error. Replace it with a response schema or a system prompt instruction.

The third is a max_tokens set too low. The limit covers thinking together with the answer, so a value sized for the answer alone truncates text once thinking is on.

The fourth is not handling the stop_reason field. A response can end for reasons other than normal completion, a token limit or a refusal for instance, and code reading content[0] without checking breaks on an empty list.

The fifth is keeping the key on the browser side. A call from a client component exposes it to anyone opening developer tools, and the bill lands on you. Route every call through the server, and if the app needs to feel interactive, stream the response through your own API route.

The sixth is ignoring retries. The libraries retry 429 and 5xx errors themselves, but under heavy traffic it pays to add your own exponential backoff and an attempt cap.

FAQ

Which Claude model should I start with?

Sonnet 5. It covers most production tasks at a third of Opus input pricing, and moving to a stronger model is a one string change. For classification and bulk processing, drop to Haiku 4.5.

What does a call actually cost?

It depends on prompt and response length. A conversation with a 2,000 token system instruction and a 500 token answer costs roughly one cent on Sonnet. At a thousand such calls a day the monthly bill runs into hundreds of dollars, and prompt caching plus batch mode can cut that several times over.

Does Claude read images and PDFs?

Yes, it accepts images and PDF documents in the same call as text. It does not generate images and does not take video input, so video material needs a different model.

How does Claude Code differ from the API?

Claude Code is a finished tool working on your repository from a terminal or editor, billed by subscription. The API is the layer for building your own products, billed per token. Teams often use both: Claude Code for working on code, the API inside the product. Cursor covers similar editor based work.

Is API data used to train models?

No, data sent through the API is not used for training. Retention configuration depends on organisation settings, and some models require a minimum retention period, so check that before deploying under compliance requirements.

Current models and rates are described in the Anthropic documentation, and the full price list sits on the pricing page.