In a real commercial codebase with 100K+ LOC, the author regarded Astra High as the sweet spot for implementation and planning, but very long refactors and Fast/Ultra consumed the allowance quickly, and the “major rewrite” ultimately remained unfinished.
Suitable tasks: Implementation, planning, UI iteration, 3D asset generation, shader or mod porting in complex codebases, and engineering experiments that require long-running Agent execution.
Unsuitable tasks: Extrapolating a single user’s subscription allowance consumption into API costs, or treating an unfinished major refactor as a success benchmark.
Applicable model versions: GPT-6 Astra; the author also made subjective comparisons with GPT-5.6 Sol, Terra, Luna, Fable 5.1, Opus, and other models.
Applicable clients, Agents, or APIs: Codex GUI, remote control from a phone, and long-horizon workflows using /goal.
Recommended reasoning tier and parameters: The author assigned Light to UI work, Medium to software explanations, and generally used High for implementation and planning; in their experience, XHigh offered no obvious gain, while Fast consumed the allowance too quickly. This is not a universal configuration conclusion.
The project is miniskyline.com, which has been iterated on continuously by Codex and Claude since June; the author says the site receives approximately $200–300 in donations per month.
The author is not a professional developer; the codebase exceeds 100K LOC, and the geometry-engine refactor used /goal for approximately 70 hours.
The first Astra High session was explicitly instructed not to use subagents. It consumed approximately 60% of the 20x allowance in the first 24 hours; other UI and optimization work consumed the remainder, and the first full allowance was exhausted after approximately 36 hours.
After a reset, the author switched to Astra High + Fast; the same /goal exhausted the allowance in approximately 12 hours. After another reset, 1 Ultra + Fast and 1 Ultra + Standard took the allowance from approximately 90% to 0% in under 6 hours.
The author did not publish a model snapshot, input/output token counts, a complete rollout, a commit diff, or a standardized comparison task.
The author published the original prompt for a 3D game-asset task; the quotation in the original post was not closed, so the following reproduces the visible content verbatim without filling in the missing portion.
Produce a GLB asset pack for a game about X. The printer must appear to work properly with all of its major hardware fully modelled and animatied where necessary. I dont want it to look fancy/modern, more junky/put together.| Task or configuration | Visible result | Key boundary |
|---|---|---|
| 100K+ LOC geometry-engine refactor | Still unfinished after approximately 70 hours | The new implementation regressed from the target of 8 seconds and 800 MB to approximately 8 minutes and 4 GB, although the author said the geometry result was more watertight |
| Astra High, no subagents | Approximately 60% of the 20x allowance consumed in 24 hours | The same allowance also covered other UI/optimization work, so it cannot be converted into pure model cost |
| Astra High + Fast | One reset exhausted in approximately 12 hours | A single-user subscription observation only; there is no token ledger |
| 1 Ultra + Fast, 1 Ultra + Standard | Dropped from approximately 90% to 0% in under 6 hours | The two tasks ran in parallel, so their individual consumption cannot be separated |
| 3D GLB assets | The author considered the result better than Sol and showed animated assets | No geometry score, files, or blind evaluation |
| DLSS/shader and Minecraft mod porting | The author said they were completed within minutes and worked well | No public repository or test log |
| Animated loading page for the website | The author said Astra understood the design direction better than Sol and required fewer iterations | Subjective visual judgment with no fixed-input comparison |
This report supports two limited conclusions: High may be the practical tier for this user’s complex implementation work; and even when a long-horizon major refactor can continue making progress, it may consume a large allowance before meeting its performance target. It does not show that High is optimal for all coding tasks, nor that the API cost of a single task in Fast mode is necessarily higher. The author themselves believed that more targeted patching might be preferable to rewriting the entire pipeline.
Another user in the comments reported that executing in small steps—“Plan → Build → Plan → Build”—was more effective, and noted that their repository required only approximately 40K tokens per round. The original author, in turn, explained that they maintained a modular structure and dependency graph for the pipeline. This suggests that task granularity, initial context, and the dependency graph should be treated as control variables when reproducing the result.
Fix the same repository commit, model snapshot, effort, service mode, tool permissions, and initial context.
Split the same refactor into two groups: a “large-scope /goal” group and a “small-step Plan/Build” group. Record the objective and stopping condition for each round.
Run Standard and Fast separately without mixing them in parallel; record allowance changes, input/cache/output/reasoning tokens, wall-clock time, compaction count, and human intervention.
Compare the old and new implementations using identical performance acceptance tests, including runtime, peak memory, correctness, non-manifold edges, and open edges.
For visual and 3D tasks, save the original inputs, GLB files, renders, iteration count, and human scores to avoid retaining only satisfaction descriptions.
GPT-6 Astra