GPT-6 Astra: Field Report on 100K+ LOC Long-Horizon Tasks, Reasoning Tiers, and Fast Mode

One-sentence conclusion

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.

Applicable scenarios

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

Test environment, inputs, and configuration

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

Reusable prompt

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.

Results and observations

Conclusions and applicable boundaries

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.

Reproduction steps

1. Fix the same repository commit, model snapshot, effort, service mode, tool permissions, and initial context.

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

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

4. Compare the old and new implementations using identical performance acceptance tests, including runtime, peak memory, correctness, non-manifold edges, and open edges.

5. For visual and 3D tasks, save the original inputs, GLB files, renders, iteration count, and human scores to avoid retaining only satisfaction descriptions.