Skip to content

    The method

    Measure honestly, save freely, prove the rest

    Six phases in strictly increasing order of quality risk. By the time anyone has to make a trade-off, the free savings have usually already paid for the work — which is the whole point of the sequence.

    How cost per successful task is measuredModel calls flow through a gateway which records tokens, model and price. The application separately records whether the customer task succeeded. Both write to a ledger keyed on the same task ID, and the ledger produces cost per successful task.THE CALL PATHYour appmakes model callsGatewayroutes · caches · capsModel providerAzure · OpenAI · othersTHE OUTCOME PATHWas the customer served?resolved · captured · acceptedLEDGERjoined ontask IDcost ÷ successescost persuccessfultaskthe only numberthat decidestokens · model · price · retriessuccess · failure · escalation
    The gateway knows what every call cost and cannot see whether the customer was served. The application knows whether the customer was served and cannot see the cost. Neither can flatter the ratio on its own — which is what makes it worth arguing in front of.

    Everything below exists to produce and defend one number. Cost per successful task is the only common AI metric that prices failure, which makes it the only one that catches a cheaper model quietly costing you more.

    Phases

    What actually happens, week by week

    You can stop after any phase and keep everything built so far. Nothing here requires the next thing to be bought.

    01Week 1

    Instrument the call path

    Every model call gets a trace: model, input and cached input tokens, output tokens, latency, the feature that made the call, and the task it belonged to. Where observability already exists we read it. Where it does not, a thin gateway captures it without touching application logic.

    • No customer data needs to leave your environment
    • Read access to billing and model logs, plus one engineering session
    • Price is recorded at call time, so later price changes cannot rewrite history
    02Week 1

    Join spend to outcomes

    Separately, your application emits one event per completed task saying whether the customer was actually served. Two independent writers, one shared task ID. Neither side can quietly flatter the ratio, because neither side holds both halves of it.

    • Success is defined by your product owner, not by us and not by the model
    • Failures and abandonments are recorded explicitly, not inferred from silence
    • The definition is versioned, so a later change does not silently reset the trend
    03Week 2

    Find and size the waste

    With both halves in place the waste surfaces in hours: prompts that resend a whole conversation each turn, static system prompts that are never cached, a flagship model doing classification, silent retries billing twice for one answer, batch-eligible work running at interactive prices.

    • Each finding sized in £/month at your current volume
    • Each finding rated for effort and for quality risk
    • Ranked by the ratio between them, not by the headline number
    04Implementation

    Ship the output-identical savings

    Caching, batching and deduplication go first because they cannot change a single token of your output. They need no evaluation harness, no product sign-off and no risk conversation — and they frequently cover the cost of the audit before anything contentious is discussed.

    • Prompt restructuring for cache stability, with before and after hit rates
    • Batch scheduling for work nobody is waiting on
    • Retry and idempotency fixes so one task is billed once
    05Implementation

    Prove the trades before anyone sees them

    Golden datasets built from your real traffic, including the awkward cases. Candidate configurations replayed offline against the same requests, scored on quality, cost and latency. The routing decision stops being an opinion and becomes a table.

    • Shadow replay — no customer sees a candidate's output
    • LLM judges calibrated against human labels on your data, or not used
    • Compared on cost per successful task, never on cost per token
    06Handover

    Gate it, cap it, and hand it over

    An evaluation gate in CI fails the build when a prompt or model change regresses the golden set. Budgets cap runaway spend at a number you chose. Dashboards show the unit economics. Then everything is handed over, because savings that are not defended decay within two quarters.

    • Routing policy versioned separately from application code, so rollback is a config revert
    • Per-project budgets and anomaly alerts, tuned to stay worth reading
    • Runbook and rollback path tested with your on-call team before handover

    What we will not do

    Four things we say no to

    Quote a saving before measuring

    Any percentage offered before someone has looked at your traces is a sales number. The honest answer to “how much can we save” is a range that gets narrower as the evidence arrives, and we would rather say that than pick a figure.

    Ship a model change without evidence

    Routing without an evaluation harness is not cost optimisation. It is a quality change with a cost side effect, shipped on a hunch, and it is how cost programmes end up being blamed for a bad quarter.

    Hold your traffic hostage

    Nothing we build runs in our infrastructure. No Rise10x-hosted proxy sits in your request path, and ending an engagement does not take your gateway, dashboards or golden sets with it.

    Sell you an engagement you do not need

    Below roughly £3,000 a month in model spend the arithmetic rarely works. We will say so on the first call and point you at the guides, which cover the same levers in the same order.

    What it costs

    FAQ

    Working with us

    How long before we see a saving?

    The audit is two weeks. The output-identical work — caching, batching, retry fixes — typically ships in the first weeks of implementation, because it needs no evaluation harness and no product sign-off. Routing changes take longer, because building golden datasets and running shadow replay properly is most of that work.

    What do you need from our team?

    An engineering contact for roughly a day a week during the audit, a product owner who can define what a successful task means, and read access to billing and model logs. Implementation phases need more engineering involvement for the parts that live in your application, such as prompt structure and retrieval strategy.

    Do you take over our systems?

    No. Everything is built into your repositories and your cloud account, and the handover is part of the scope rather than an afterthought. If you end the engagement you keep the gateway, the dashboards, the golden sets and the evaluation harness — which is deliberate, and why the retainer has to keep earning renewal.

    What if the audit finds we are already efficient?

    Then we say so, you have a measurement infrastructure and a quality baseline you did not have before, and there is no implementation phase to sell. That happens, and telling you would be the whole value of the engagement — it is a great deal cheaper than finding out in six months.

    How do you avoid breaking things?

    Sequencing and evidence. Two thirds of the work cannot change your output at all. The remaining third is validated against a fixed dataset before it goes near a customer, rolled out by percentage rather than by switch, watched on cost per successful task rather than per-token cost, and kept behind a one-line rollback throughout.

    Find out what your AI actually costs per completed task.

    Two weeks, a fixed fee, and a ranked savings plan with the quality risk of every move stated up front. If the numbers say an audit is not worth it for you, we will say so on the first call.