LLM integration
A model inside your product, with costs and failures under control.
Model calls wired into your app with prompt versioning, structured outputs, cost accounting, rate limits and fallbacks. The interesting part is not the prompt, it is what happens when the provider is slow, expensive or down.
Project pricing
From $2,500
That covers one model feature wired into an existing product: the call path, structured output, cost accounting and a fallback. Several features, an evaluation harness and a self-hosted gateway run to $10,500.
Send the brief and get a number back.
Describe the projectIt worked in the demo and then met real traffic
The prototype answered well, so the feature shipped. Then the provider had a slow afternoon and the page hung, because nothing set a timeout. The bill arrived and nobody could say which feature spent it, because the calls were never tagged. Somebody improved a prompt and something else quietly got worse, because there was nothing to compare against. The model returned prose where the code expected fields, and the parser threw on a customer. None of that is a prompt problem. It is the plumbing around the model, and it is the part that decides whether the feature survives its first month.
What gets built
A call path that fails politely
Timeouts, retries with backoff, and a fallback that is decided before it is needed: a smaller model, a cached answer, or an honest message. The page never waits on a provider that has stopped answering.
Output the code can trust
Structured output with a schema, validated on arrival, with a repair pass for the near misses and a clear failure for the rest. The application stops parsing prose and starts reading fields.
Costs and prompts you can account for
Every call tagged by feature and tenant, tokens and spend recorded, limits per user and per day. Prompts versioned in the repository, so a change is a diff you can revert rather than a memory of what someone edited.
Why it is built this way
The provider is a dependency, not a foundation
Prices change, models get deprecated, regions go down. The integration is written so the provider can be swapped at the boundary, and so a bad day upstream degrades the feature instead of taking the product with it.
Measured before tuned
A prompt change without a comparison is a guess with a good story. A small set of real cases, run before and after, turns tuning into something you can approve or reject.
How it runs
A read of the feature you want and the product it lives in: where the call belongs, what data it may see, what happens while the user waits, and what the answer must look like for the code downstream.
The contract first: the schema of the output, the failure modes, the budget per call and per day, agreed in writing before any prompt is written.
The integration built behind one interface, with the provider, the model and the prompt as configuration rather than as code sprinkled through the app.
A small evaluation set from your real cases, run against the versions, so the numbers decide rather than the last person to touch the prompt.
Handover with the dashboard for spend and failures, the runbook for a provider outage, and a written note on what to watch in the first month.
Background
What an LLM feature actually costs to run
The prompt is the cheap part
Most of the work in a production model feature is not the prompt. It is the schema the output has to satisfy, the timeout, the retry, the fallback, the per-tenant limit and the record of what was spent. Teams that skip that layer ship faster and then spend the following quarter adding it under pressure.
Structured output changed the failure mode
With schema-constrained output the model returns fields instead of prose, and the interesting failures move from parsing to semantics: a valid object with a wrong value. That is caught by validation against your own data, not by a stricter prompt.
Retrieval beats a bigger context window
Larger context windows made it possible to paste everything into the prompt, and expensive to do so. Selecting the few passages that matter is cheaper, faster and easier to explain to a user who asks where an answer came from.
Evaluation is what makes tuning honest
Without a fixed set of cases, every prompt change is judged by whoever tried it last. With one, a change is a number that went up or down, and a rollback is a decision rather than an argument.
Describe the project
Tell us what you have and what should change. Within two working days you get a written calculation: the scope broken into parts with a price against each, or the questions needed to write one. No discovery call in between.
Questions
LLM work, asked and answered
Usually more than one. The integration is written against an interface, with one provider primary and another behind it, because the cheapest model for a task changes every few months and being locked to one vendor is what makes that expensive.
Often not. Retrieval on a modest corpus runs on the database you already have, and a dedicated vector store earns its keep at scale or with heavy filtering. It gets added when the numbers say so, not by default.
Yes, and it is part of the build: budgets per user, per feature and per day, enforced in the call path rather than watched in a dashboard afterwards. When a cap is hit, the feature degrades in a way you chose in advance.
Yes, with the provider and region chosen for it, or with an open model on your own infrastructure. It is a constraint that changes the architecture, so it belongs in the first conversation rather than the last.
That is the usual starting point. The prompt work in a prototype is often fine; what is missing is the schema, the limits, the fallback and the accounting, and those can be added without throwing away what works.