How I Cut GPT-6 Astra Usage by ~95% Without Losing Quality

Ethan+ — Mon, 21 Sep 2026 15:03:51 +0000

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:

ethanplusai / astra-flash-orchestrator

Astra plans and reviews; DeepSeek Flash builds. A native Codex workflow with phased tasks, verification, safe installation and reversible setup.

Astra Flash Orchestrator

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.

Measured efficiency

In one substantial field build, Astra Flash Orchestrator used 98.9%…

View on GitHub

Across a full build it cut my Astra usage by roughly 95%, and the quality went up rather than down.

Swapping the model is not the answer

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.

What the package does differently

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%.

What the full build looked like

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:

6,875 tests passing, 80 skipped, 0 failing
88 browser QA captures
32 of 38 roadmap packets accepted
111 of 121 acceptance criteria passing

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.

The number moved

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.

Why the price gap is so extreme

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.

How the split works

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.

How it installs

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.

Codex Router brings external models into Codex natively. Your native GPT models, sign-in, and settings are untouched.
Connect DeepSeek or OpenRouter through the Router's own prompt. The package never asks for, reads, or stores a key.
The skill installs to ~/.agents/skills/astra-flash-orchestrator/
The Flash role installs to $CODEX_HOME/agents/astra_flash_builder.toml
A workflow policy is appended to $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.

Setup

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.

What I'm not claiming

This is field evidence from one project, not a controlled trial. It shows a real effect, not a proven cause.
Your savings will differ. Different repo, different task mix, different result.
The dollar figures are an estimator, not an OpenAI receipt.
Delegation sends your task context to DeepSeek. Keep production data and secrets out of briefs.
A subagent is not a sandbox. It inherits your existing sandbox and approvals.

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

DEV Community: Ethan+