Model
Building with Claude
Where Claude earns its place in a production system, where a cheaper model wins, and what we have learned running it at volume.
- Anthropic
- Model
When should you use Claude?
Claude is the model we most often reach for on the reasoning-heavy steps of an agent workflow — multi-step tool use, long-context document work and tasks where instruction adherence matters more than raw speed. It is not the right choice for every step, and routing high-volume classification or extraction through it is one of the most common causes of indefensible inference bills. We benchmark step by step and use it where it measurably wins.
Use it when
- The step involves multi-part instructions that must be followed precisely, such as an agent deciding which tool to call next.
- The task requires reasoning over a long document or a large retrieved context where the relevant material is scattered.
- Output quality on nuanced judgement matters more than shaving a few hundred milliseconds of latency.
- You need reliable structured output and tool calling as the backbone of an agent loop.
Reach for something else when
- High-volume classification, routing or simple field extraction, where a small model performs identically at a fraction of the cost.
- Latency-critical paths where a sub-second response is a product requirement.
- Workloads that must run entirely on your own hardware with no external inference at all.
From our own builds
What we have learned running it
We use Claude as the reasoning core in most of the agent systems we operate, with smaller models handling the routine steps around it. The two things that have most changed our architecture are prompt caching, which makes a long stable system context economically viable in a way it was not before, and the reliability of structured tool calling, which removed a whole category of parsing and repair code we used to need. The recurring mistake we correct in inherited codebases is a single frontier model handling every step in the pipeline, including the ones that are trivially classifiable.
Where it fits in an architecture
We treat model selection as a per-step decision, not a platform choice. In a typical agent workflow there are three or four genuinely hard steps — deciding what to do next, reasoning over a long retrieved context, composing a careful response — and a dozen routine ones.
Claude goes on the hard steps. Something small and cheap goes on the routine ones. That split is the single highest-leverage cost decision in an agent build, and it is much easier to design in than to retrofit once the architecture assumes one model everywhere.
What changed our patterns
Two capabilities materially altered how we build.
Prompt caching made long stable system context economically sensible. Before it, a detailed system prompt with extensive tool definitions and policy context was a per-request cost you tried to trim. With it, that context can be substantial and cached, which in practice means agents can be given fuller instructions than we used to allow ourselves.
Reliable structured tool calling removed a whole layer of defensive code. We still validate every output against a schema at the boundary — that rule does not change for any model — but the repair-retry path fires far less often than it used to.
The mistake we most often inherit
Almost every underperforming system we are asked to audit routes every step through one frontier model. The bill is fine in pilot and indefensible at volume, and by then the code assumes a single client everywhere.
The fix is a provider abstraction and per-step benchmarking against the evaluation set. It is a day or two of work at the start of a project and a multi-week refactor eighteen months in.
Frequently asked questions
When do you choose Claude over another model?
Is Claude expensive to run in production?
Can Claude be used with sensitive data?
Do you lock the system to one model provider?
Where we use this
- AI agent developmentAutonomous agents that execute a business process end to end, with the guardrails and evaluation infrastructure that keep them trustworthy at volume.
- LLM app developmentLLM features built into your existing product, with the streaming, structured output and cost controls that production traffic demands.
- RAG developmentRetrieval systems that answer over your own data with a citation for every claim, and a retrieval score you can actually measure.
Next Step
Tell us what you are trying to automate
A 30-minute technical call with an engineer who has shipped this before — not a sales qualification round. You leave with a feasibility read, a rough shape for the build, and an honest answer about whether it is worth doing at all.