Models in production, with the bill visible

What it is

The Anthropic API is direct, programmatic access to the Claude models. Instead of a person typing into a chat window, software sends a request and gets a response it can act on. It is the layer underneath anything that uses a model as part of a system rather than as a tool someone opens.

On this estate it does two production jobs, and it is also the route by which Claude Code reaches the models for day-to-day engineering.

What it runs here

The Ask Claude widget. Twenty-five sites carry a small widget that lets a visitor ask a question and get an answer. The sites do not each talk to the model. They call one central service, which holds the API key, applies the rules and makes the request. Changing how the widget behaves is one change, not twenty-five, and the key never sits in a web page.

Scheduled content agents. The newsroom runs on WordPress, and scheduled agents keep it current on a timetable, rather than a person doing that by hand each morning.

Why the API rather than a packaged product

Plenty of products wrap a model in a ready-made chatbot or writing assistant, and for many organisations one of those is the right call: quicker to start, nothing to run. I would recommend one where it fits.

The API makes sense when the model has to fit into your own systems — your sites, your data, your schedule, your identity — rather than living in a separate tab. It also keeps the important decisions with you: what data is sent, what is kept, which model handles which job, and what each job is allowed to cost.

How it is kept honest

1. One place holds the key. Requests go through a server-side service. Keys are never placed in browser code where a visitor could lift them.
2. Cost per job is recorded. Each use is accounted for, so it is possible to say what the widget or an agent actually costs and whether it is worth it.
3. The right model for the job. Not every task needs the largest model. Cost accounting per job is what makes it possible to see where a smaller, cheaper one would do.
4. Output is treated as a draft until checked. A model's answer can be fluent and wrong. Where it matters, there is a check — by a person, or against the source — before it is relied on.

What I would do for a client

Start with the job, not the model. Find the places where a model genuinely removes work — triage, summarising, drafting, answering the same question for the hundredth time — and the places where it would add risk without saving much. For the first group, build the integration behind your own service so keys, rules and costs are in one place, put a per-job cost on it from the first day, and decide in advance what "worth it" looks like. For the second group, say no and write down why.

Questions people ask