Managing token cost isn’t a single decision.
It’s five separate mechanisms, each documented by at least one of the two major agent platforms and in most cases by both, plus one diagnostic step that isn’t itself a cost-reduction mechanism but determines which of the other four actually applies. None of the four require guessing — they’re things a vendor’s own documentation tells an engineering team to do. The fifth is Luminity’s own synthesis, built on the companion readout’s measurements rather than on vendor-published guidance, and it’s labeled as such below.
1. Order the prompt so the stable part comes first
Both platforms’ caching systems work off a prefix match: a cache hit requires the entire prompt up to a marked point to match exactly against a prior request. Anthropic’s guidance is to place cached content — system instructions, background information, large contexts — at the prompt’s beginning, and to set the cache breakpoint on the last block that stays identical across requests, not on whatever happens to be last in the message. OpenAI’s guidance is the mirror image: keep the stable prefix first, and if dynamic content has to appear in the developer or system message, push it to the end rather than the beginning.
The failure mode both vendors describe is the same one: a static system prompt followed immediately by a per-request field that changes every call. Because the whole prefix up to the breakpoint has to match, that one changing field at the front invalidates everything behind it, and the system pays full price on every request despite most of the content never changing.
2. Tune the compaction trigger instead of accepting the default
Compaction is not a fixed cost — both platforms expose it as a configurable trigger, and where it fires directly shapes both compaction frequency and cache reuse. Anthropic’s server-side compaction lets a team configure when compaction triggers via an explicit trigger parameter. OpenAI’s compaction is controlled the same way: server-side compaction fires when the rendered token count crosses a configured compact_threshold, a value the team sets.
This matters because compaction and caching compete with each other on at least one platform — OpenAI’s own documentation notes that compaction changes the prefix, so the first request after a compaction event may reuse less of the previous cache even though the conversation is logically continuous. A trigger set too aggressively creates more compaction events than the task needs, and each one risks giving up cache reuse the conversation would otherwise have kept — not necessarily a full miss every time, but a real cost the source material itself flags as a direct tradeoff against over-triggering.
3. Don’t parallelize a task that doesn’t decompose
The 4x/15x multiplier from the companion readout is the price of admission for running a multi-agent architecture, and it only pays for itself when the task actually splits into independent pieces. Anthropic states this limit directly: domains that require all agents to share the same context, or that involve many dependencies between agents, are not a good fit for multi-agent systems, and most coding tasks in particular involve fewer truly parallelizable pieces than research does. OpenAI’s orchestration guidance says essentially the same thing from the other direction: start with one agent whenever possible, and add specialists only when doing so materially improves capability isolation, policy isolation, prompt clarity, or trace legibility — splitting too early adds more prompts, more traces, and more approval surfaces without necessarily improving the workflow.
The decision rule both vendors converge on is the same one: before reaching for a multi-agent architecture, check whether the task actually decomposes into pieces that don’t need to share context. If it doesn’t, the multiplier is paid without being earned.
4. Scale effort to task complexity explicitly, in the prompt
Anthropic’s own early failure mode, by their account, was agents that couldn’t judge how much effort a task warranted — spawning far more subagents than a simple query needed. Their fix was to embed scaling rules directly in the prompt: simple fact-finding gets one agent with a handful of tool calls, direct comparisons get a small number of subagents, and only genuinely complex research gets a larger, explicitly divided set of subagents. This is a documented, first-party mitigation for the specific compounding pattern where a query’s cost balloons well past what the task required — the fix isn’t a runtime circuit breaker, it’s telling the agent, in the prompt, what the effort budget looks like for a task of this shape.
5. The diagnostic step: split the total before optimizing any of it
This one is different in kind from the four above it. Levers 1 through 4 change system behavior — they reduce cost directly. This one doesn’t reduce anything by itself; it tells you which of the other four is worth pulling. None of the first four can be applied intelligently against a single aggregate number. A total token cost doesn’t say whether the spend is dominated by cache misses, by output generation, or by an oversized multi-agent architecture — and each of those has a different fix. This is the one place the companion readout’s frame is a prerequisite rather than a separate concern: the cache-efficiency ratio and the multiplier-vs-baseline from that piece are exactly the breakdown that tells a team which of levers 1 through 4 actually applies to their spend, before they start pulling any of them. That breakdown is Luminity’s synthesis of the companion piece’s measurements, not a vendor-published cost-optimization technique — worth being clear about, since it sits in a different evidentiary category than the four mechanisms above it.
Every lever here reduces cost by changing what gets sent to the model or how the architecture is shaped — none of them touch whether the resulting spend is auditable. A team can apply the four mechanisms, cut its bill substantially, and still have no better an answer to the governance question the companion piece raised.
Cost and assurance are genuinely separate axes; optimizing one does not move the other, and a team that only tracks the invoice will not notice if the cheaper run is also a less governed one.
