AI integration
Adding a model to a product takes an afternoon. Making it answer correctly, fail safely, and cost less than the customer pays is the actual work. We build model features that are measured before they ship and metered once they do, so you know which ones work and what each customer costs.
What it covers.
Retrieval over your data
Search across your documents and records that returns sources, respects each customer's permissions, and stays current as data changes.
Tools and agents
Models that act through your own APIs, with confirmation steps, limits and an audit trail for anything they change.
Evaluation
A test suite of real questions and expected answers that runs on every change, so a new prompt or model is a measured decision.
Cost per customer
Every call attributed and priced, with caps per customer and a monthly view of what each customer pays against what they cost.
Fallbacks across providers
A second model ready when the first is slow or unavailable, so one provider's outage isn't yours.
Model choice, documented
Which model each feature uses, why, and what it costs, written down so it can be revisited as prices fall.
Cost you can see, and cut.
Model bills grow quietly: a longer prompt here, a larger model there, one customer who uses a feature all day. We build so that every call has a known cost and a known customer, then bring the cost down where the evaluation says it's safe to.
Margin per customer
On Dianthan Models, each customer's calls are set against what they pay. You see who is profitable, who isn't, and which feature is responsible.
The right model for each task
Routine work such as classifying, extracting and summarising usually runs as well on a smaller model at a fraction of the price. The evaluation suite shows when that's true before anything changes.
Fewer tokens per answer
Shorter prompts, retrieval that sends only the passages that matter, and caching for questions that repeat.
Limits before surprises
Caps per customer and per app, alerts as spend climbs, and credits for heavy users so usage pays for itself.
How it runs.
Use case
Which task, for whom, and what a correct answer looks like. We collect real examples before writing a prompt.
Evaluation first
A measurable baseline: how often it's right today, what it costs per call, how long it takes.
Build
The feature, its guardrails and its metering, improved against the evaluation until it clears the bar you set.
Handover
The evaluation suite, the cost model and the code, so your team can keep improving it.
Is it a fit.
A good fit
Products adding search, assistants, document processing or agents for their customers. Teams that care about cost and accuracy, not demos.
Not a fit
Training foundation models, and projects where success can't be defined or measured.
Questions.
Which providers do you work with?
All the major ones. We choose per feature on accuracy, latency and price, and keep the choice easy to change.
Will our data be used to train models?
We use provider settings and agreements that exclude your data from training, and document which ones apply.
Can you fix a model feature we already have?
Yes. That usually starts with an evaluation suite, because it shows what is actually wrong before anything changes.
Other engagements.
Production readiness
For a product that works but is not yet ready for paying customers. We review it, close the gaps that matter, and hand back a written report.
From $3,000Product engineering
Web applications, APIs and internal tools, designed and built with your team, in milestones you can use as they land.
Milestones from $5,000Operations and care
Monitoring, upkeep and incident response for systems we have built or reviewed, with a fixed allowance for small changes each month.
From $400 a month
Tell us what you're building.
A few lines about the product and what stands in the way. An engineer replies within two working days.