Back to Posts / Token Arbitrage: Sol vs Luna

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

By Max Trivedi

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

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

Condense operations are essentially summarization operations with some trivial constraints. They primarily need to preserve task state: the objective, repository findings, files changed, commands and tests run, failures encountered, decisions made, and unresolved work. Once a model reliably extracts those fields, additional general 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 + $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 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 even larger.

If you work exclusively in long-context loops, assuming context compaction is a 10% overhead cost, this change alone 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 Plan mode and Act mode. This was a special case since this is neither plan nor act, so I added a new concept of Utility model (well, the concept itself is not new; multiple agents out there already support a similar concept). Then, when the compaction is triggered at the configured context limit, the harness routes this through the utility 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 offload non-sequential operations to Luna, which returns only the result to the next main-model turn. MAIN SEQUENCE PRIMARY MODEL Sol Plan / Act DIRAC HARNESS Main agent loop NEXT TURN Sol continues OFFLOAD OUT-OF-BAND WORK UTILITY SIDE PATH OUTSIDE MAIN SEQUENCE UTILITY MODEL Luna sidecar UTILITY OPERATIONS Compaction Tasks Commits SIDE-LOAD RESULT
The main model or harness offloads non-sequential work to the utility sidecar, then loads only the result into the next turn.

Another advantage, of course, was to start reusing this in multiple other things such as task creation tooling, 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 one-off, so it can be called with cache writes disabled, saving you one whole cent per call!