Sultan Kautsar

Published: September 7, 2026

Coding with GPT Astra

My current coding workflow uses GPT-6 Astra at high reasoning for planning and GPT-6 Astra at low reasoning for executing the plan. This follows the approach I described in Working with GPT, where I used Sol high to plan and Sol low to implement. The model has changed, while reviewing the direction before implementation remains central to how I work.

I want the agent to help turn a request into a clear specification, make the technical decisions visible, and produce code that I can inspect and verify. Getting there takes more than asking it to plan and then saying “implement.” Each stage needs a useful output that the next stage can rely on.

What Astra High and Astra Low mean

Astra High and Astra Low are shorthand for the same GPT-6 Astra model with different reasoning-effort settings. OpenAI documents support for both high and low; these are not separate model families. The official Astra model page describes its use for complex reasoning, coding, and work involving tools.

My reason for choosing high during planning is to give difficult decisions more attention: understanding an unfamiliar repository, comparing approaches, and finding gaps in a request. Once the decisions are settled, low is my starting point for implementing a bounded change. That is a workflow preference, not a guarantee that low will always be faster or that high will always produce better code.

Reasoning effort also does not decide whether the agent may edit files. I make the phase explicit: investigate and propose a plan first; implement after I accept it. When execution reveals a design problem, I can return to high reasoning, revise the relevant decision, and continue.

Start with the problem and the repository

A useful brief explains who needs the change, what happens today, what should happen afterward, and which constraints matter. For a bug, include the reproduction steps, expected result, actual result, and a sanitized error or example. For a feature, describe the user journey and the boundary of the request.

Before proposing a design, the agent should inspect the relevant implementation, nearby examples, dependencies, and tests. Ask it to identify the actual files and entry points behind its recommendation. This catches a common problem early: a technically plausible plan built around an API or component that the project does not have.

Keep repository instructions such as AGENTS.md short and accurate, with setup commands, conventions, and checks that really apply. OpenAI's Astra guidance notes stronger instruction following and sensitivity to instructions in repository files and skills. For me, that makes outdated project guidance something to fix before a long session.

Write a specification that can be checked

The specification describes the required behavior. The implementation plan explains how to deliver it. Keeping those purposes clear makes it easier to notice when a proposed technical solution has quietly changed the requirement.

Consider an illustrative task: adding a status filter to an internal order list. A brief specification could contain:

• 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 preserves 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 changes are outside this ticket.
• Acceptance: pending results contain only pending orders, clearing the filter restores the normal list, and unauthorized records never appear.
• Open question: confirm whether the backend already supports status filtering before choosing where to implement it.

These statements give the developer and reviewer something observable to check. “Make filtering work well” leaves too many decisions hidden. Resolve questions that affect behavior, permissions, or data before accepting the specification; record routine assumptions so they remain visible.

Plan with Astra High, then review the plan

With the specification in place, ask Astra High for the smallest complete implementation plan. It should name the affected areas, explain the approach, identify dependencies between steps, and connect each acceptance criterion to a check. Where there is a meaningful tradeoff, ask for the alternatives and the reason for the recommendation.

For the order filter, the plan might cover confirming the API contract, handling the filter in the page URL, passing it through the existing request layer, implementing the interface states, and checking pagination and access control. Any schema change or migration needs its own explanation and recovery approach.

I review the plan against the request and the codebase. Before accepting it, these are the questions I want answered:

• Does every required behavior have an implementation step and a way to verify it?
• Are important assumptions supported by repository evidence?
• Does the approach reuse existing code and respect the project's conventions?
• Are failure states, compatibility, and data access handled where relevant?
• Can the work be divided into changes that are small enough to review?

A separate critique pass can help expose gaps: ask the agent to find missing decisions and concrete failure cases in the plan. I still make the acceptance decision myself. A polished plan can contain the wrong assumption, and approving it is the moment to resolve that assumption before it becomes code.

Hand a complete plan to Astra Low

The implementation handoff should include the accepted specification, ordered steps, relevant file references, constraints, and expected checks. For longer tasks, a small plan file in the repository can preserve those decisions across sessions. Update it when a decision changes so there is one current version to follow.

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 is then responsible for carrying out a defined piece of work. For the filter example, that means connecting the agreed URL state, request behavior, and interface states. If the backend cannot support the required result, that is a reason to revisit the design. It should not quietly become filtering only the currently loaded page of orders.

I would also increase reasoning effort for repeated failures, a difficult race condition, or a newly discovered architecture issue. Low is the default for execution in this workflow; the complexity of the actual problem still determines when to change it.

Verify behavior and review the actual code

Verification should produce evidence against the specification. For the filter example, check a pending result, an empty result, a failed request, a page refresh, and a filter change from a later page. Confirm server-side access rules as well as what the interface displays. A successful build alone cannot establish those behaviors.

Use the project's relevant tests, static checks, and build commands. Add a regression test for a meaningful bug or new behavior when appropriate; a test should catch a failure in the requirement rather than simply repeat the implementation. For interface changes, inspect the result at useful screen sizes and exercise keyboard interaction. Match the checks to the change and its risks.

After verification, 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 surrounding code, and request findings with a location, a failure scenario, and an explanation of the impact.

Using a fresh review session can reduce reliance on the implementer's earlier explanation, but it does not guarantee independent judgment. I still read the important changes myself. Validate each finding, fix the real problems, and rerun the affected checks. If a check could not run, keep that limitation explicit in the handoff.

GPT Astra compared with Sol

OpenAI positions GPT-6 Astra for its hardest tasks spanning multiple steps and tools, while GPT-5.6 Sol remains a model for complex professional work. Its model guidance describes Astra as more capable than Sol and better at maintaining coherence across long tasks. That is the documented positioning; I have not established a controlled benchmark for my own projects.

The technical comparison follows OpenAI's model comparison, checked September 7, 2026. API token rates do not describe a ChatGPT subscription's usage allowance, and a lower rate does not establish a lower total cost for a finished task.

My practical choice is Astra High when the work needs careful exploration and Astra Low once the direction is clear. Sol is still a reasonable candidate to evaluate 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 time to an accepted result, defects found during review, correction cycles, and actual usage. Test planning and implementation separately so a better initial specification does not get 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 remains uncertain. Include setup or migration instructions when needed, update relevant documentation, and make the change easy to review in a commit or pull request. Follow the project's release process, then check the deployed behavior and relevant errors or metrics.

The full loop I recommend is: define the problem, inspect the repository, write the specification, plan, review and accept, implement, verify, review the code, fix findings, and deliver. Feedback from real use can then become the next clearly scoped task.

The depth should match the work. A small text correction may need only a clear request, an edit, and a quick check. A feature involving payments, permissions, or data migration deserves much more deliberate specification and review. The purpose of these steps is to expose the decisions that could otherwise be missed.

Using Astra High for planning and Astra Low for implementation gives me a clear division of attention. I can spend more effort deciding what good looks like, let the agent carry out the accepted work, and judge the result through code and evidence. The result I want is software that solves the request, behaves well in real use, and remains understandable to the next person who maintains it.