Sign in Subscribe
news

2026-10-04 Astra plans, Luna carries the context - route models by context length

Sebastien Dubois

Sebastien Dubois

— 5 min read

Canonical version: 2026-10-04 Astra plans, Luna carries the context - route models by context length.

On 16 September, Nate B. Jones posted a trick on X that got about 30K views. He says it saved him over $2K in API costs on a 68-agent build in the Codex harness, over one weekend. His recipe:

  1. Use Astra to plan the build
  2. Have Astra start a long-running Luna orchestrator
  3. Give Luna a handoff file with precise instructions for calling Astra subagents with clean context windows
  4. Start a fresh Astra "bulldozer" agent to watch Luna and unblock it

His summary: "Luna ends up with the super long context window. Astra windows stay short and clean, so you're not paying for big context windows on a big model." And: "yes, quality is solid!"

The usual advice is to send the hard steps to the expensive model. Nate also asks which model has to hold the LONG context, and gives that job to the cheap one.

Why it saves money

An orchestrator rereads its whole history on every turn. Over a weekend, that history gets huge, and you pay for it again each time. The per-token prices:

Input Cached input Output
GPT-6 Astra $10 $1 $50
GPT-5.6 Luna $0.20 $1.20
GPT-6 Luna $0.10 $0.01 $0.50

Prices per million tokens.

The post is from 16 September, six days before GPT-6 Luna shipped. So "Luna" in Codex was most likely still GPT-5.6 Luna, 50 times cheaper than Astra on input. GPT-6 Luna doubles that gap to 100×, and cached reads cost 100× less ($0.01 vs $1).

Cache reads add up fast on long runs. In one comparison from my Astra note, two thirds of Astra's bill on a 447-turn coding task was cache reads. Both models also charge a premium above 272K input tokens (2× input, 1.5× output, for the whole request). A weekend-long orchestration context on Astra pays the top price on the biggest token count; on Luna, the same tokens cost almost nothing.

Astra only sees short windows: the plan, one hard subtask, one unblocking session. You pay Astra prices on small token counts, where its judgement matters.

The pattern behind the trick

This is Model routing with context length as the main criterion (my note already lists it, next to complexity, latency and cost). On top of splitting by difficulty, Nate splits by memory:

  • Big model, short and clean windows: planning, hard subtasks, unblocking. Every call starts fresh, with only what it needs
  • Cheap model, long window: the orchestration state. Which agent is doing what, what's done, what failed, what comes next

The orchestrator does bookkeeping and dispatching. That's well-specified work, and OpenAI's own model-selection guide puts Luna there.

The same idea with Claude

You can already do this with Claude, at different price points:

  • Plan with Fable, execute with Opus. The rough consensus from the Hacker News thread on Claude Opus 5.5 tips: Claude Fable 5.1 for high-level planning and code review, Opus 5.5 for "sterile execution". Fable costs $10 / $50, about 2.5× Opus 5.5 per token
  • AI Subagents with clean context. Anthropic's tips for Opus 5.5 recommend one subagent per item for big audits and migrations, with evidence (file paths, test output) required before accepting a report. Each subagent starts fresh; only its summary returns to the parent
  • A task list in a file. The same tips say to keep a checklist in TASKS.md so progress survives when the context window fills up and gets compacted. That's Nate's handoff file, under a different name
  • Prompt caching. Opus 5.5 cache reads cost $0.20 per million (5% of the input price), so a long-context orchestrator costs less there. The logic still holds: the more often a context gets reread, the cheaper the model holding it should be

The price gap is much smaller, though. Fable costs 2.5× Opus; Astra costs 50 to 100× Luna. With Claude, this trick saves less.

What I'd do with it

  • Before asking "who does the hard work?", ask "who holds the long context?" Map your workflow: which agent lives for hours, which ones live for minutes. The long-lived one goes on the cheap model
  • Write the handoff file with the big model, and review it yourself. It's the contract between the planner and the orchestrator. For each subagent call: the goal, the inputs, the definition of done, the evidence to return, and when to escalate
  • Have subagents return evidence along with "done". The orchestrator is the cheapest model in the system, so don't ask it to judge quality from vibes
  • Keep the orchestrator below 272K tokens. Compact it, or restart it from the handoff file and a progress log. Past that line, you pay the long-prompt premium on every turn (Context size reduction has the Codex-specific tricks)
  • Give the watcher a clean window too. The "bulldozer" works because it reads Luna's state from fresh, so have it read the progress file instead of Luna's whole transcript
  • Run a smaller build both ways and compare cost AND quality before trusting anyone's savings number

Caveats

  • The $2K is self-reported, with no baseline. No cost breakdown, no comparison run, no definition of "solid" quality; the post only says 68 agents and one weekend. I'd treat it as an anecdote that fits the price math
  • The handoff file is a single point of failure. If it's vague, Luna will dispatch vague subagent prompts, and Astra will do good work on the wrong task. Luna's record on judgement is mixed: on 50 public PRs, GPT-5.6 Luna found three quarters of Astra's verified bugs but missed the auth and permission bugs, and one in four of its comments was wrong
  • Long contexts drift, and a weekend-long orchestrator accumulates noise. Codex CLI sessions already reach 100K+ tokens by turn 5 to 10 without compaction. Even Astra drifted on Armin Ronacher's 35-hour unattended run (task names went from "1, 2, 3" to "8b2c2b2b checkpoint1"). I don't expect a cheaper model holding a longer context to do better, and that's probably why Nate needed the bulldozer in the first place
  • Watch tool failures. OpenAI's own eval shows GPT-6 Luna not telling the user about a broken search tool in 28.7% of adversarial cases. An orchestrator that hides a failed subagent call keeps going on a broken state

I strongly believe this pattern will outlast the current model names. Prices move every few weeks, but keeping the expensive model's windows short and clean pays as long as big models cost more per token than small ones. It's Context Engineering applied to the whole system: which model sees which context, and for how long.

All the pricing and benchmark details are in my GPT-6 Astra and GPT-6 Luna notes.

That's it for today! ✨

References

About Sébastien

Ready to get to the next level?

Found this valuable? Share it with someone who needs it.

Join 6,000+ readers. Get practical systems for knowledge & AI. Free.

Subscribe ✨

Free: Knowledge System Checklist

A clear roadmap to building your own knowledge system. Subscribe and get it straight to your inbox.

6,000+ readers. No spam. Unsubscribe anytime.

Subscribe