What we build in the Claude API

What it is, and where it sits

Anthropic's Claude API is one of two AI providers we build with. We choose per task on measured accuracy and cost rather than preference, and we build so the model can be swapped without rewriting the workflow around it.

Where Claude tends to earn its place: long context windows suit contract, tender and specification review; structured output support makes typed, validated extraction reliable; and it is comparatively good at declining to answer when the information is not present, which matters more than it sounds.

What we build in it

• Long-document review against your checklist, with clauses quoted and located rather than summarised away
• Structured extraction from unstructured documents into typed, validated fields
• Inbound message classification and detail extraction for triage
• Drafted replies grounded in your own documentation, queued for human approval
• Internal knowledge assistants answering from your content with citations
• Meeting and call summarisation into decisions, owners and dated actions

How it is priced

Priced per token, input and output, varying by model. You pay Anthropic directly; we take no margin.

For a typical SMB workload the numbers are smaller than people expect. A triage agent handling a few hundred messages a day usually lands in the tens of dollars a month. Long-document review is the expensive case, because a 60-page tender is a lot of input tokens — worth modelling if you process them at volume.

Cost control comes from model selection per task: classification and extraction often run well on a smaller, cheaper model, with the larger one reserved for genuine reasoning over long context.

When it is the right choice

Same test as always: could a sufficiently detailed rule handle this? If yes, use a rule. Reach for a model only when the input is unbounded natural language. See agent or workflow?

Within AI-appropriate tasks, we lean toward Claude for long documents, for extraction where output shape must be reliable, and where "I don't know" is the correct answer more often than a guess.

Limits worth knowing before you commit

• It is not deterministic. The same input can produce different output. Everything downstream must validate rather than trust.
• Latency is seconds, not milliseconds. Fine for asynchronous work, wrong for anything a user waits on synchronously.
• Cost scales with document length. High-volume long-document processing needs modelling before committing.
• It cannot be the verification step for itself. High-stakes output needs independent checking — arithmetic, cross-reference, or a person.