The first week Astra came out, the usage was incredibly efficient. I ran something like 500M tokens and never got close to the weekly limit on the 20x plan. Then that stopped. I started hitting the ceiling constantly, and burned through four resets to cover the next 500M tokens.
Nothing about my work had changed. What changed was how much Astra I was spending on things that did not need Astra.
Here's what a long coding session actually is. Maybe 10% of it is architecture, interface design, security calls, and judging whether the result is right. The other 90% is discovery and typing: read the repo, write the function, run the test, read the failure, fix it, run it again. Astra is worth every credit for the first 10%. The other 90% is busy work you're paying a premium to watch.
So I built a package that splits the session along that line. Astra keeps scope, design, the hard calls, and final acceptance. DeepSeek V4.1 Flash takes discovery, implementation, testing, and debugging. Both run inside Codex as native subagents, with no second CLI and no API client of my own.
It's open source:
Save Astra for the decisions that need it. Let DeepSeek V4.1 Flash do the volume.
A personal Codex skill designed to preserve Astra usage without giving up Astra's judgment. Astra stays responsible for planning, architecture, high-stakes decisions and final review. DeepSeek V4.1 Flash takes the high-volume work repository discovery, implementation, testing, debugging and routine verification.
Bring an existing plan or start with a feature request. The workflow turns it into coherent implementation bundles, sends those bundles to Flash, then returns the completed patch and evidence to Astra for one focused acceptance pass.
Status: early release. Offline installation tests pass, and the workflow has completed a measured local field build. Results below describe that run, not guaranteed savings. A new installation still needs runtime routing verification on its first authorized task. Installation never runs paid inference.
In one substantial field build, Astra Flash Orchestrator used 98.9%…
Across a full build it cut my Astra usage by roughly 95%, and the quality went up rather than down.
The obvious move is to point the expensive model at a cheaper one and call it orchestration. I tried that repeatedly and it barely worked.
Reusing my existing skills with cheaper models. Pointing Astra at the smaller OpenAI models through skills I already had got me maybe 10% back, and introduced new problems.
Trying every obvious worker. Sol, Luna, Opus, and Sonnet each had something going for them. None moved the number enough to matter, and some cost me time in rework.
The pattern in both failures was the same, and it had nothing to do with the worker. I was still asking Astra to supervise. It dispatched, waited, re-read, re-reviewed. A cheaper worker saves you nothing if the expensive model stays parked in the loop watching it work.
1. A worker that can hold a long assignment. DeepSeek V4.1 Flash produced immediately better output than the other cheap options, comparable to Opus 5 for the same work. It writes solid code and stays on a long task without wandering off. That alone got me about 60%.
2. A root that gets out of the way. Astra does one planning batch, one dispatch, one wait, and one batched acceptance review. No progress polling, no narrating each tool call, no re-reading the worker's transcript. Flash owns discovery, implementation, its own test-and-fix cycles, and routine browser checks, then hands back a finished patch with evidence.
That second change is where 60% became the rest. The workflow is the product. The model underneath is replaceable.
In daily terms: a 7-hour build under the current setup used about 2% of my weekly usage. A 5-hour build done the old way used over 28%.
The complete run was 23 hours 3 minutes of active task runtime. The main 18.5-hour stretch on the current setup took four prompts from me across fifteen worker sessions.
What it produced (generated files, migrations, and docs excluded):
| Category | Files added | Files modified | Lines added |
|---|---|---|---|
| Product source | 177 | 205 | 45,590 |
| Tests | 106 | 81 | 29,944 |
| Total | 283 | 286 | 75,534 |
Volume proves nothing on its own, so here's the quality side:
Anything that needed a live provider, production access, or a decision I hadn't authorized stayed explicitly blocked. The workflow doesn't quietly mark those done.
The DeepSeek side of the entire run came to $19.32 at published rates.
When I first posted about this, the measurement said 98.9% less Astra input per 1,000 lines. Across the full run it settled at 94.2%, with total compute per 1,000 lines 91.5–92.9% lower than the all-Astra baseline. The measured phase also produced 119% more implementation and test lines than that baseline.
The ratio came down because the later hours were review, integration, and interface correction, exactly the work that pulls Astra back in. A headline number taken at the easy part of a build isn't the number you'll live with, so I'd rather publish this one.
| Per 1M tokens | Astra (estimator) | DeepSeek V4.1 Flash | Astra premium |
|---|---|---|---|
| Uncached input | $10.00 | $0.15–$0.30 | 33–67x |
| Cached input | $1.00 | $0.003–$0.006 | 167–333x |
| Output | $50.00 | $0.60–$1.20 | 42–83x |
Look at the cached input row. In a long agentic session, almost all your input is cached context being reread every turn. That's the biggest line item in a build, and it's up to 333x more expensive on Astra.
Astra has no public API price, so those figures are an estimator applied consistently for comparison, not a receipt.
Astra -> scope, design, task briefs across phases
Flash -> discover, implement, test, report each task
Astra -> review, verify, accept or request fixes
-> integrate, checkpoint, next task
Astra keeps everything that benefits from a frontier model: what to build, how it's structured, what the interfaces are, and whether the returned work meets the spec. Architecture, auth, tenancy, payments, and secrets never get handed down.
Flash gets one coherent assignment at a time and owns it end to end.
Then Astra reviews the actual patch, not the worker's summary. It runs the checks itself against a baseline captured before the worker started. Only Astra can accept. After two failed correction cycles it re-scopes instead of burning money on a loop.
That review gate is why quality holds.
There's no new runtime. Codex already knows how to run a child agent on a different model. This points it at the right one and gives Astra a process.
~/.agents/skills/astra-flash-orchestrator/
$CODEX_HOME/agents/astra_flash_builder.toml
$CODEX_HOME/AGENTS.md between markers
Direct DeepSeek is the default. OpenRouter, opencode Go, Command Code, Nous Research, and Ollama Cloud work by passing an explicit route.
The installer is the part I spent the most time on, because the failure I cared about was silently breaking someone's Codex setup. It runs read-only checks first, defaults to a dry run, backs up everything with a receipt, rolls back on any failed write, and can undo cleanly. It never spends money on test calls.
You need Codex with native subagents, Astra as your root model, Python 3.11+, and Codex Router configured with a Flash route.
git clone https://github.com/ethanplusai/astra-flash-orchestrator.git
cd astra-flash-orchestrator
python3 -B install.py # dry run, changes nothing
python3 -B install.py --apply
For a different provider:
python3 -B install.py --worker-route openrouter/deepseek-v4.1-flash --apply
Check it:
python3 -B skill/astra-flash-orchestrator/scripts/doctor.py
Fully quit and reopen Codex before your first task, since the model catalog is cached at launch.
Your first task looks like this:
$astra-flash-orchestrator Use the existing plan in docs/plan.md to implement
this feature. Keep Astra focused on planning and final review. Use one installed
Flash builder for a coherent implementation and verification bundle. Do not poll
the worker; review its completed patch and evidence in one batched pass.
Then verify routing yourself: the root thread should show Astra, and the child request should be attributed to DeepSeek in your Router's request metadata.
I'm still testing and changing this. If it breaks on your setup, open an issue. Feedback from other people's configurations is the most useful thing I can get right now.
Astra does the thinking. Flash does the typing. Your weekly limit stops deciding how much you get built.
Full write-up with complete methodology: ethanplus.ai