LegalOn Cuts Daily Codex Costs by 65% Without Losing Speed

LegalOn cut its estimated daily Codex costs by 65% without losing development speed. OpenAI's blog reports the result. The headline of the piece says "by half," but the actual figure is higher: if spending fell by 65%, the company now pays about 35% of its previous amount, or roughly 2.9 times less.

What exactly did they do?

The published summary names two techniques. First, LegalOn matched tasks to the Astra, Sol and Luna options. Second, the company managed its budgets strategically. The available excerpt does not say what Astra, Sol and Luna are (different models, modes or configurations) or how they differ in price and capability. So we won't speculate.

The underlying logic is clear, though, and familiar to anyone who pays for tokens. Routine work should not run through the most expensive option. Simple edits, boilerplate code generation and small refactorings can go to a cheaper tier, while complex architectural decisions and tangled debugging context stay with the pricier, stronger one.

Key figures and facts

• Reduction in estimated daily Codex costs: 65%.
• Development speed: maintained, but the source gives no quantitative data.
• Three options involved: Astra, Sol and Luna.
• Approach: matching the option to the task type, plus budget management.
• Metric type: estimated daily costs specifically, not confirmed invoices for a period.

Where the figure calls for caution

The word "estimated" matters here. This is a calculation, not a number from the accounting department, and a lot depends on the chosen baseline. If all requests previously went through the most expensive option, 65% savings look realistic and even modest. If the baseline was already a partly optimized setup, the result is more impressive.

The second question is speed. "Maintained development speed" could mean cycle time from task to merge, the number of closed tickets, or the team's subjective assessment. Without a metric and a measurement period, this remains a claim, not proof. So far the source shows neither the number of review iterations nor the share of tasks that had to be redone on a stronger option. Those redos are exactly what eats into savings.

Finally, the scale is unknown: 65% of a small sum and 65% of a large budget look very different for a team.

What you can put to work

You can apply this approach even without access to LegalOn's details.

• Sort tasks by complexity. Start with three buckets: mechanical edit, standard feature, nonstandard problem. For each, pick the minimum sufficient option.
• Count the cost of a task, not of a request. A cheap model that needs three attempts can cost more than one attempt by a strong model.
• Set budgets per team or workstream and check them daily. The daily granularity LegalOn mentions lets you catch an overrun before the month ends.
• Measure speed before optimizing. Without a baseline, you cannot verify that it stayed the same.
• Track the share of escalations from the cheap tier to the expensive one. If it grows, your routing is poorly tuned.

The LegalOn case shows that AI coding spend can be managed as well as cloud bills. The full picture will be clearer once details appear: what Astra, Sol and Luna are, and how speed was measured.