Underpin Optimise: 98% lower token spend.

The commercial impact

I report a 98% reduction in token spend and six-figure dollar savings per month from the project. These are my reported project outcomes. The public benchmark below is a separate, earlier local evaluation; it does not independently validate the monthly financial result.

The engineering problem

Document-heavy AI workflows can repeatedly send more source text than the current question requires. Reducing that context creates a second problem: important information may be omitted. Optimise explores selection with a recovery path, rather than assuming a smaller input is always sufficient.

The implementation

The prototype provides a local API and Python SDK. The guarded selection path returns source excerpts with offsets. An agent can recover additional passages, and flagged cases can use full context. Recovery and fallback model calls are included in whole-task token accounting.

Earlier local benchmark: 59% fewer tokens

A recorded local comparison used 36 questions on 36 documents and the same model and prompts. Full context used 194,420 total model tokens; the guarded path used 79,737. That is 59% fewer total tokens in this specific test, including agent history, retrieval and fallback. It is a different result from the reported 98% reduction in token spend.

The trade-off

This was a small, single-model local test using Qwen3-4B-Instruct-2507. Guarded processing took 185.8 seconds versus 68.0 seconds for full context, and four tasks used full-source fallback. Token reduction is not a measured bill saving or a claim of faster processing. Provider tokenisation, caching and compute costs still need evaluation.

What is available to inspect

The product page explains the workflow, and the benchmark documentation describes the comparison and limitations. The published benchmark record reports 39 unit and integration checks and a built SDK wheel. This is prototype evidence, not a claim of a production hosted service.

What I would evaluate next

Use a representative workload and compare complete task costs, answer quality, latency and recovery behaviour against the existing approach. Keep the baseline fixed so improvements can be attributed to the change being tested.