In my testing with GPT-6 Astra, I've had to keep correcting work that was already covered by my instructions. That has included pointing back to a writing guide supplied earlier, reasserting when tests should run, and asking for requested work missing from a completion handoff.
Read the full study, or explore the data and methods in the research repo.
I use Codex for ongoing work with documented scope, repository context, standard operating procedures, and verification before delivery. When I have to repeat those instructions during a task, that adds supervision. I wanted to understand how often that was happening in my own records, so I reviewed six days of Astra activity and the conversations around it.
The process was already documented
In June, I wrote about using Codex for ongoing work, setting up the task and its constraints, and keeping SOPs in versioned files.
Eric Provencher from OpenAI's Codex DX team described closely aligned practices in his July article on GPT-5.6 orchestration. His guidance covers distinct assignments, preserving constraints when delegating, and choosing reasoning effort to fit the work.
What needed correction?
The review identified 147 corrective contributions among 538 substantive contributions from me. A contribution is a message or a reconciled piece of voice input, so several can belong to the same problem. The corrections grouped into 78 episodes, and 31 of those needed repeated corrective contributions.
Forty episodes involved process or SOP concerns. One testing-related episode alone contained 17 corrective contributions. The retained record shows the repeated intervention, although it doesn't establish that every test rerun was unnecessary.
The review also identified 154 contributions expressing dissatisfaction. Ninety-one of those included corrective steering.
The review applied a coding rubric to the conversations. Several corrections can address one problem, so these counts don't measure a model failure rate.
How much work was in the records?
The retained records contained 25,254 responses across 557 turns. Recorded tokens totaled 3.42 billion, including 3.35 billion cached input tokens. Cached input accounted for 98.2% of input tokens; output totaled 10.99 million tokens, including reasoning. The large total includes repeated context, so it can't tell us how much useful work was completed or what it cost.
Across 17 identifiable repositories associated with the work, 410 PRs merged during the broader window. That count includes all authors. The explorer lets you inspect the activity and corrections by relative day and generic project label, with repository activity shown separately for the full window.
What might explain it?
I have two hypotheses from roughly four or five days of personal experience: shortcuts toward finishing may displace requirements, and requirements may get lost when work is delegated. Both are entirely untested. The audit records the intervention; it doesn't establish either cause or a matched difference between GPT-5.6 and GPT-6. A deployment runbook contained outdated instructions.
Other practitioners described related problems in replies to my posts. Arbaz reported drift with detailed design instructions, and Billovskii described behavior recurring after explicit prohibitions. John Collins reported good instruction-following when the steps were explained.
Help make the comparison useful
I've published the reviewed aggregates, methods, figures, and a contribution kit in Astra Field Study under MIT. The kit produces a local aggregate for review before submission. Project labels and days are generic, and raw conversations stay private. GitHub contributions still identify the contributor's account.
This is what I currently think, and I want to know more. If your established workflow transferred cleanly to Astra, I'd like to understand the instructions, task boundaries, and checks that made it work. You can contribute through the repo or reach me on Twitter. Successful examples and experiences that contradict mine are welcome.