Token Arbitrage: Use Sol for coding, Luna for compaction, save 84% - Dirac Posts

Features

Docs

Posts

Token Market Share by<br>Lab

Evals

Discord

GitHub

Install Dirac

Back to Posts

Token Arbitrage: Sol vs Luna

The recent Luna price drop unlocked some neat uses for OpenAI users such as<br>scout, test writer, test maintainer, trigger executor, and many more. We will specifically focus on context<br>compression in this post.

Suppose you are running a fairly long agentic loop that has a compaction threshold around 200k tokens and<br>compaction triggers 5 times during the full loop. Each time, let’s say the compaction generates ~10k tokens (20:1<br>compaction ratio). Somewhere between 8 to 12% of the total cost of such a loop will be solely from compaction,<br>easily making it the most expensive tool call per invocation, largely due to the large token output that<br>necessarily has to be generated each time.

Condense operations are essentially summarization operations with some trivial constraints. They primarily need to<br>preserve task state: the objective, repository findings, files changed, commands and tests run, failures<br>encountered, decisions made, and unresolved work. Once a model reliably extracts those fields, additional general<br>reasoning capability is unlikely to produce any measurable improvement in the summary. (source: arXiv 2606.02875 + many similar results)

Scenario A: Sol condenses its own context

200k × $0.50/M (cached input price) + 10k × $30/M (output + reasoning tokens emitted for condense) = $0.10 +<br>$0.30 = $0.40

Scenario B: The harness detects the condense threshold and hands the work over to Luna.

200k × $0.25/M (cache write price; Luna does not benefit from read cache) + 10k × $1.20/M (output + reasoning<br>tokens emitted for condense) = $0.05 + $0.012 = $0.062

Compared to Sol, just swapping in Luna for compaction saves:

1 − ($0.062 / $0.40) = 84.5%

This is a comparison solely between Sol and Luna; if you use something like DeepSeek V4 Flash, the savings would be<br>even larger.

If you work exclusively in long-context loops, assuming context compaction is a 10% overhead cost, this change alone<br>reduces your overall bill (or saves usage limit) by 8.4% with no regressions.

Now supported in Dirac

Dirac already supported a separate model for<br>Plan mode and Act mode. This was a special case since this is neither plan nor act, so I added a new concept of<br>Utility model (well, the concept itself is not new; multiple agents out there already support a similar concept).<br>Then, when the compaction is triggered at the configured context limit, the harness routes this through the utility<br>model and the main model starts its next response with condensed context.

Utility model sidecar architecture

Sol handles the main Plan and Act sequence through the Dirac harness. The main model or harness can<br>offload non-sequential operations to Luna, which returns only the result to the next main-model turn.

MAIN<br>SEQUENCE

PRIMARY<br>MODEL<br>Sol<br>Plan / Act

DIRAC<br>HARNESS<br>Main agent loop

NEXT<br>TURN<br>Sol continues

OFFLOAD<br>OUT-OF-BAND WORK

UTILITY<br>SIDE PATH<br>OUTSIDE<br>MAIN SEQUENCE

UTILITY<br>MODEL<br>Luna<br>sidecar

UTILITY<br>OPERATIONS

Compaction

Tasks

Commits

SIDE-LOAD<br>RESULT

The main model or harness offloads non-sequential work to the utility sidecar, then loads only the result into<br>the next turn.

Another advantage, of course, was to start reusing this in multiple other things such as task creation tooling,<br>generating the commit message automatically, and so forth.

If you want to push it to the limits

Notice that we used $0.25/M input price earlier for Luna, which is a cache write price. This content is strictly<br>one-off, so it can be called with cache writes disabled, saving you one whole cent per call!

All Posts