What Astra High and Astra Low Mean
Astra High and Astra Low are my shorthand for the same GPT-6 Astra model at two reasoning-effort settings. OpenAI documents both high and low; they are not separate model families. The official Astra model page describes it as a model for complex reasoning, coding, and work involving tools.
I use high during planning so the hard decisions get more attention: understanding an unfamiliar repository, comparing approaches, and finding gaps in a request. Once those decisions are settled, I start with low to implement a bounded change. That is my preference. Low is not guaranteed to be faster, and high is not guaranteed to write better code.
Reasoning effort also has nothing to do with whether the agent may edit files. I make the phase explicit: first investigate and propose a plan, then implement after I accept it. If execution exposes a design problem, I switch back to high, revise the decision, and carry on.
Start with the Problem and the Repository
A useful brief says who needs the change, what happens today, what should happen afterward, and which constraints matter. For a bug, include the reproduction steps, the expected and actual results, and a sanitized error or example. For a feature, describe the user journey and where the request ends.
Before it proposes a design, the agent should read the relevant code, nearby examples, dependencies, and tests. I ask it to name the files and entry points behind its recommendation. That catches a common problem early: a plausible plan built around an API or component the project does not have.
Keep repository instructions such as AGENTS.md short and accurate, with the setup commands, conventions, and checks that really apply. OpenAI’s Astra guidance mentions stronger instruction following and sensitivity to instructions in repository files and skills. So I fix outdated project guidance before a long session.
Write a Specification That Can Be Checked
The specification describes the required behavior, and the implementation plan explains how to deliver it. Keeping the two apart makes it easier to spot when a technical solution has changed the requirement without anyone saying so.
Take an illustrative task: adding a status filter to an internal order list. A short specification could say:
- Outcome: a sales user can show all orders or only pending orders, within their existing access permissions.
- Behavior: changing the filter resets pagination to page one, and refreshing the page keeps the selected filter.
- States: loading is visible, an empty result explains that no orders match, and a failed request offers a retry.
- Boundaries: use the existing list components and authentication rules. Order editing and export are outside this ticket.
- Acceptance: pending results contain only pending orders, clearing the filter brings back the normal list, and unauthorized records never appear.
- Open question: check whether the backend already supports status filtering before deciding where to implement it.
The developer and the reviewer can both observe each of these. “Make filtering work well” hides too many decisions. Resolve the questions that affect behavior, permissions, or data before you accept the specification, and write down the routine assumptions so they stay visible.
Plan with Astra High, Then Review the Plan
With the specification in place, I ask Astra High for the smallest complete implementation plan. It should name the affected areas, explain the approach, show which steps depend on which, and link each acceptance criterion to a check. Where there is a real trade-off, I ask for the alternatives and why it recommends one.
For the order filter, the plan might cover confirming the API contract, keeping the filter in the page URL, passing it through the existing request layer, building the interface states, and checking pagination and access control. Any schema change or migration needs its own explanation and a way to recover.
I review the plan against the request and the codebase, and before accepting it I want these answered:
- Does every required behavior have an implementation step and a way to verify it?
- Are the important assumptions backed by evidence from the repository?
- Does the approach reuse existing code and follow the project’s conventions?
- Are failure states, compatibility, and data access handled where they matter?
- Can the work be split into changes small enough to review?
A separate critique pass helps find gaps: I ask the agent for missing decisions and concrete failure cases in the plan. The acceptance decision stays with me. A polished plan can still rest on a wrong assumption, and accepting it is the last cheap moment to catch that before it becomes code.
Hand a Complete Plan to Astra Low
The handoff to implementation includes the accepted specification, the ordered steps, file references, constraints, and the expected checks. For longer tasks, a small plan file in the repository keeps those decisions across sessions. When a decision changes, I update the file so there is one current version.
A practical implementation instruction is: “Implement the accepted plan using the existing project patterns. Complete and verify each logical step. Keep changes within scope, report any mismatch between the plan and the repository, and identify which acceptance criteria were checked when you finish.”
Astra Low then carries out a defined piece of work. In the filter example, that means wiring up the agreed URL state, request behavior, and interface states. If the backend cannot return the required result, the design needs another look. The agent should not settle for filtering only the orders already loaded on the current page.
I also raise the reasoning effort after repeated failures, for a hard race condition, or when an architecture problem turns up. Low is the default for execution in this workflow, and the actual difficulty of the problem decides when to change it.
Verify Behavior and Review the Actual Code
Verification should produce evidence against the specification. For the filter, that means checking a pending result, an empty result, a failed request, a page refresh, and a filter change from a later page. Check the server-side access rules as well as what the interface shows. A passing build proves none of those behaviors.
Run the project’s relevant tests, static checks, and build commands. Add a regression test for a meaningful bug or new behavior where it makes sense, and make sure the test would catch a broken requirement instead of restating the implementation. For interface changes, look at the result at a few screen sizes and try it with the keyboard. The checks should match the change and its risks.
After verification, I review the diff against the accepted specification. A review pass with Astra High can look for correctness problems, missed requirements, unnecessary complexity, and regressions. Give it the actual diff and the surrounding code, and ask for findings with a location, a failure scenario, and the impact.
A fresh review session depends less on the implementer’s earlier explanation, though it is still the same kind of judgment. I read the important changes myself, check each finding, fix the real problems, and rerun the affected checks. If a check could not run, I say so in the handoff.
GPT Astra Compared with Sol
OpenAI positions GPT-6 Astra for its hardest tasks that span many steps and tools, and GPT-5.6 Sol as a model for complex professional work. Its model guidance describes Astra as more capable than Sol and better at staying coherent across long tasks. That is OpenAI’s positioning. I have not run a controlled benchmark on my own projects.
| Aspect | GPT-6 Astra | GPT-5.6 Sol |
|---|---|---|
| My workflow | Current high/low pairing | Previous high/low pairing |
| Context window | 1,050,000 tokens | 1,050,000 tokens |
| Output limit | 128,000 tokens | 128,000 tokens |
| API token rates | Higher base rates | Lower base rates |
The technical figures come from OpenAI’s model comparison, checked September 7, 2026. API token rates say nothing about a ChatGPT subscription’s usage allowance, and a lower rate does not guarantee a lower total cost for a finished task.
In practice I use Astra High when the work needs careful exploration and Astra Low once the direction is clear. Sol is still worth evaluating for familiar, well-specified work where cost matters. Both need repository context, a usable specification, and review.
To compare them fairly, give each the same task from the same starting revision, with the same tools, requirements, and checks. Record the time to an accepted result, defects found in review, correction cycles, and actual usage. Test planning and implementation separately, so a better specification is not mistaken for a better implementing model.
Finish with Delivery and Feedback
A complete handoff explains what changed, why it solves the request, what was checked, and what is still uncertain. Include setup or migration steps when needed, update the documentation, and make the change easy to review as a commit or pull request. Then follow the project’s release process (mine is in A Practical Deployment Pipeline) and check the deployed behavior along with any errors or metrics.
The full loop is: define the problem, inspect the repository, write the specification, plan, review and accept, implement, verify, review the code, fix the findings, and deliver. Feedback from real use can become the next clearly scoped task.
How much of this a change needs depends on the change. A small text correction may need only a clear request, an edit, and a quick check. A feature that touches payments, permissions, or data migration deserves much more careful specification and review. The steps exist to surface decisions that would otherwise slip through.
Splitting the work this way lets me spend more effort deciding what good looks like, hand the accepted work to the agent, and judge the result from code and evidence. What I want at the end is software that solves the request, behaves well in real use, and makes sense to the next person who maintains it.