Two months of engagement in four milestones. The instrumentation and the tracking table built and shipped into your call path; the analysis as real traffic accumulates; the changes you approve, implemented and shipped through your pipeline against an agreed quality bar; a second month of monitoring, correction and smaller cuts; and a final report with every change and what it measured out at. $12,000 total, and the only thing outside it is your own model spend, which you pay your provider directly as you already do.

Because a two week audit cannot prove anything. A week of traffic misses your monthly shape, so a cut made against it is a cut made against a sample. And comparing the month before to the month after is not a controlled comparison: your usage changed, you shipped other code, the vendor may have changed prices. Two months of per-call tracking, with each change annotated where it shipped, is what lets you separate what I did from everything else that happened. The second month is also when savings regress, so it is the month that decides whether there was a saving at all.

Because I am equally on it. Month one is louder, bigger cuts and more shipping. Month two is monitoring, catching the creep, the smaller fixes and the confirmation work, and it is the month that turns a dip into a result you can bank. Charging less for it would price the engagement as if the proof were optional. If month two turns out to be quiet, that is a good outcome you paid for, not a discount you are owed.

In four phases: instrumentation and tracking ($2,500), month one findings and first cuts ($4,000), month two held and tuned ($4,000), report and handover ($1,500). A phase is agreed before it starts and paid when you approve that phase’s deliverable, so you are never paying up front for work you have not seen.

Direct B2B, on your own contract and invoicing, through whatever procurement process your company already has. There is no platform in the middle and no marketplace fee. Reach me on LinkedIn and we sort the terms directly, including an NDA first if your policy wants one.

I will not put a number on that before the measurement, and you should be suspicious of anyone who does. Nobody can predict the saving on a workload they have not seen. What I commit to is the measurement: once the tracking is live you get a ranked list with an estimated saving per change and what each costs to implement, from your own traffic rather than from an industry average, and you decide which ones ship.

Then I write that down rather than inventing work. It is rarer than you would think, but it happens, and at that point we talk about what the rest of the engagement should be: it might become monitoring and a regression watch, it might become a smaller scope, it might stop. What I will not do is spend a month manufacturing changes so the invoice looks earned. You keep the instrumentation, the tracking and the dashboard either way, which is worth having the next time the bill moves.

One call to walk through what your product does and which features call a model. Then access to the repository that makes those calls, read access to wherever the calls are logged today, and whoever normally reviews and merges in that repository. After that I mostly need answers to the occasional question about what a feature is for and who uses it. For shipping, your team merges and deploys as usual, or you give me a path to do it, your call.

The instrumentation records metadata by default: feature, model, token counts, cached tokens, latency and cost. It does not need prompt or completion bodies to produce the breakdown, and it will not store them unless you explicitly want sampling turned on for prompt-trimming work, in which case it is scoped and redacted to whatever your policy allows. Everything runs in your environment, and I work from the aggregates. NDA signed before specifics if you want one.

That is the real risk, and it is the thing the engagement is built around. A quality bar is agreed up front, in whatever form fits your product: an evaluation set, a golden set of outputs, a human review pass, or a metric you already trust. Every change gets checked against it before it ships, and a change that crosses it does not ship. If a call genuinely needs the expensive model, it keeps the expensive model and I say so in writing.

Anything you call over an API. The big hosted providers, the aggregators and gateways, and anything you already run yourself behind an OpenAI-compatible endpoint. On the code side it does not matter much whether you call the SDK directly or go through a framework, because the instrumentation sits at the point where your code decides to make a call. If your calls are spread across several services in different languages, that comes up during scoping and shapes where the layer goes.

Nothing you have to pay for. The instrumentation keeps recording, the dashboard keeps showing spend by feature and by model, and the changes keep saving money. If a new feature starts burning tokens, you see it as a line going up in a dashboard you already own. There is no retainer to sign and no support plan to renew. If you want me back later for another pass once the product has moved on, that is a new engagement, quoted then.

You own all of it. The instrumentation, the tracking table and the dashboard are plain code in your repository, running on your infrastructure, and the changes are changes to your own codebase reviewed by your own team. There is no licence, no seat count, no subscription, and nothing phoning home.