bttrfly sits between your applications and the models.
Your applications send their calls to bttrfly instead of straight to the provider, and that is the only change on your side. From there the traffic is visible and attributed, your policy applies, and optimization runs underneath.
Four steps, and only the first one touches your code.
Your applications send their calls to us
Applications and command-line agents need one setting changed, and that is the whole integration. Desktop and IDE assistants keep their own connection to the provider, so we cover those with a hook and a small local service instead.
The traffic becomes visible
Every call is logged and attributed to a team, an application, and a model. Spend stops arriving as one invoice nobody can explain.
Your policy applies in one place
Per-team budgets, model rules, data handling, and the kill switch are enforced once, instead of in every application separately.
Optimization and measurement run underneath
Compression, caching, and routing shrink each request, and a control group shows the savings and any change in quality.
One honest limit. Assistants that run entirely inside a vendor's cloud, such as Microsoft 365 Copilot or the web versions of ChatGPT and Claude, build their context there and never expose the call. Nobody outside that vendor can see or optimize those, and we would rather tell you now than at the end of a pilot.
How we measure quality →Three places to save, and one place to manage them.
What the model already does
Providers like Anthropic and OpenAI cache and compact context themselves. We work with that rather than against it.
What we send in
Content-aware compression, caching, and routing that shrink the request without losing meaning.
How the model responds
Organization-wide policies that keep answers concise, cutting the most expensive tokens of all, the ones the model generates.
These layers multiply rather than just add up, which is why it pays to manage all three from one place instead of relying on any single trick.
Techniques that cut tokens and often raise quality.
| Technique | Cost | Quality | What it does |
|---|---|---|---|
| Relevance filtering | ↓ | ↑ | Drop retrieved passages that aren't relevant to the task, so the model sees fewer distractions. |
| Reranking and ordering | ~ | ↑ | Put the most relevant content where the model reads it best, at the start and end rather than buried in the middle. |
| Question-aware compression | ↓ | ↑ | Compress with the current question in mind, keeping what matters and shrinking the rest. |
| Deduplication | ↓ | ↑ | Remove repeated content that competes for the model's attention. |
| Denoising | ↓ | ↑ | Turn messy logs, stack traces, and HTML into clean input the model can read easily. |
| History pruning | ↓ | ~ | Trim stale conversation turns that would otherwise mislead the model. |
Some of these, like reranking, barely change the token count but still improve the answer. That is why we treat quality as its own goal, not just a side effect of spending less. Every one of them runs against a control group, and the guarantee says what happens when a technique does not pay off on your traffic.
Central control, without your data leaving your cloud.
Centralizing means the raw prompt arrives first, and that is the most sensitive version of your data. So the whole thing runs inside your own network, where that data already lives.
and agents →
provider
Your applications reach it over your own network, so the extra latency is a single local hop against a call that already takes seconds.
Talk through your setup →See this running on your own traffic.
We start with an audit of what your teams already send, not a contract.