GPT-6 Long-Running Tasks: Keep Agents Making Useful Progress

GPT-6 Astra can work through extended projects, but a long run is useful only while it moves toward an accepted result. Give the agent a concrete milestone, a way to verify progress, and enough saved state to resume after interruption. Increase the scope after it completes a meaningful phase.

This matters for projects such as a website, a research package, a repository migration, or a multi-document deliverable. Each can generate hours of activity without resolving the central requirement. The operating question is whether the latest work makes the final result more usable.

Sources: Matt Shumer's review; Codex issue #43193; OpenAI release notes. Reviewed September 7, 2026. Results and experiences are attributed to their authors below.

What early experiences reveal

Matt Shumer's Astra review describes ambitious projects that slowed as the model became absorbed in details. He found a coordination setup helped maintain direction, while acknowledging that long-running autonomy remained unresolved.

A public Codex issue about orchestration and instruction following describes substantial usage alongside repeated process failures. It is a user's report, not a measured failure rate, but it illustrates why additional agent activity should not be mistaken for progress.

These experiences suggest an operational habit: evaluate what changed since the last checkpoint. If no acceptance criterion moved closer to completion, inspect the plan before adding more time or agents.

Diagnose the kind of interruption

A long task can stop because the model needs a decision, because a tool failed, because the application ended the run, or because the work has drifted. Each needs a different response. Repeating "continue" is unlikely to resolve a missing file or a conflicting instruction.

OpenAI's GPT-6 guidance describes a greater tendency to ask clarifying questions and sensitivity to instructions in accessible files. It also documents mid-turn steering and asynchronous tool calls. Those capabilities help an application coordinate work, but they do not guarantee that an arbitrary session will keep executing indefinitely.

An early document-review discussion describes stalls despite checkpoints and a coordinator. It is a single user's experience, but it highlights a practical limitation: a checkpoint preserves progress; it does not itself provide a scheduler or repair a stopped execution environment.

Worked example: review a large document set

Suppose your team needs a comparison of requirements across several documents. This illustrative project benefits from batching because you can verify coverage and findings as the work progresses. Start with an inventory rather than asking for a final report immediately.

Phase 1: establish what exists

Assign each document an identifier, version, date, and review status. Record unreadable files and missing references. Agree on the questions the review must answer so the model does not spend its budget summarizing material that cannot affect the decision.

Phase 2: review a representative batch

Choose a few documents with different structures and levels of complexity. Ask for findings tied to a page, section, or source identifier. Review this first batch before allowing the same method to process the entire set. A flawed extraction format becomes expensive when repeated hundreds of times.

Phase 3: reconcile across batches

The final synthesis should compare claims, definitions, and requirements across documents. Keep a record of contradictory sources and explain which version takes precedence. Do not treat the first summary as authoritative simply because later agents received it instead of the original file.

Phase 4: verify completion

Match the final report against the document inventory. Every required document should be reviewed, excluded for a stated reason, or still open. A polished report with missing coverage is an incomplete result even if the completed sections are accurate.

Document ID | Version | Review status | Findings file | Open questions
A-01        | 3       | Reviewed      | findings-a01  | None
A-02        | 2       | Blocked       | findings-a02  | Missing appendix
A-03        | 1       | Pending       | -             | Not yet reviewed

This gives a replacement session a clear starting point and gives the human reviewer a way to audit coverage without replaying the whole conversation.

Decide what a checkpoint must preserve

A useful checkpoint contains both the state of the work and evidence that the state is correct. "Finished phase two" is insufficient when nobody can locate the output. Include the artifact path, the input version, the acceptance checks completed, and the remaining discrepancy.

For code, record the working revision and relevant test result. For research, keep source links and retrieval dates. For a spreadsheet, preserve the input workbook and the changes applied. If another person edits the artifact, update the checkpoint before continuing so the agent does not work from stale assumptions.

Keep checkpoints at natural boundaries. Saving after every sentence can create administrative work; saving only after a multi-hour run makes recovery expensive. A completed batch, a validated change, or a resolved design decision is usually a useful boundary.

Restart without duplicating work

Resume this milestone from the saved task record.
Inspect the current artifacts before making changes.
Identify completed acceptance criteria and do not repeat them.
Check the outcome of any previously attempted external action.
Continue with the next unmet criterion.
If the record conflicts with the files, explain and reconcile it first.

The distinction between attempted and completed matters. A tool can time out after creating a record. Before retrying, read the destination and establish what happened. For local artifacts, check whether the previous run saved a partial result that can be completed rather than overwritten.

Budget around useful progress

Use a bounded pilot to learn how much work the task requires. For document review, track verified documents and corrected findings. For coding, track accepted behaviors. Include human review time because a large output that takes hours to repair may not be productive.

Set an explicit response when the budget is nearly exhausted: save the current artifact, update the task record, and return the next decision. A token ceiling alone prevents further spending but does not ensure a useful handoff. The handoff needs to be part of the task contract.

If progress stops improving across checkpoints, pause expansion and inspect the bottleneck. The right next step may be a missing source, a narrower milestone, a different tool, or a human decision. Increasing reasoning effort is only one possible intervention.

Define the first finish line

"Build the whole product" contains too many implicit decisions. Start with an inspectable slice: one working journey, one validated analysis, or one migrated component. The slice should be useful enough to reveal whether the model understands the project.

Set the milestone before the run starts. Changing the goal after every intermediate result makes it difficult to distinguish correction from scope growth.

Matt Shumer's review-preparation progress view. Checklist counts record progress; they are not independent verification.

Keep a compact task record

The model needs the current objective, decisions, working files, failed approaches, and remaining checks. A long transcript is not always the best place to recover that information. Maintain a short record that can be inspected and corrected.

Current milestone:
Acceptance criteria:
Artifacts and source locations:
Decisions already made:
Approaches ruled out and why:
Verified results:
Open problems:
Next action:

Update the record after a meaningful result or an important change in direction. Avoid replacing it with a narrative of every tool call. Its purpose is to make the next decision easier.

Recognize three kinds of stalled work

Repeating an unsuccessful approach

Ask what new evidence justifies another attempt. A retry after a transient tool error can be sensible; repeating the same reasoning without new information is less promising. Preserve failed attempts so the next session does not rediscover them.

Polishing before completing the core task

An agent may refine wording or visual details while the essential journey remains broken. Return to the acceptance criteria and identify the most important unmet requirement. Finish that before increasing polish.

Adding scope to solve ambiguity

When the task is unclear, a model may build more infrastructure instead of resolving the missing choice. Ask it to state the smallest uncertainty that changes the design. Resolve that decision before allowing a broad rewrite.

Use checkpoints to make interruption recoverable

OpenAI's Astra announcement notes that safeguards can interrupt legitimate tasks. Network failures, application crashes, and user changes can also stop a run. Save useful artifacts throughout the task and verify their state before resuming.

A resumed task should read the current files and task record, identify what is already complete, and continue from the next unmet criterion. If a previous run may have performed an external action, check its outcome before repeating it.

A long-task prompt template

Complete this milestone: [specific outcome].
Acceptance criteria: [observable checks].
Use these materials and tools: [scope].
Keep a brief task record with decisions and verified progress.
Prioritize unfinished core requirements before polish.
If progress stalls, explain the blocker and the evidence needed.
At the budget limit, return usable artifacts and the next action.

You do not need multiple agents for every project. Add a separate role only when it has a distinct output that can be reviewed independently. More coordination can itself become work, particularly when several agents edit the same artifact.

Measure progress and cost together

Track completed criteria, reviewer corrections, elapsed time, and total usage. A useful checkpoint might say that two of three journeys now pass, the third has a reproducible failure, and the patch is ready for review. "Still working" does not provide enough information to decide whether another hour is justified.

Keep the brief, sources, drafts, and review decisions together in Ottermind. For shorter starting tasks, use the templates in how to use GPT-6; for integration-level budgets, see the API guide.

FAQ

Can GPT-6 complete a project from one prompt?

Some creators describe projects that began that way, but the environment, tools, prior setup, and later review still matter. Start with a concrete milestone.

How long should I let an agent run?

Set a budget appropriate to the task and inspect progress at meaningful checkpoints. There is no universal useful duration.

What if the agent keeps improving minor details?

Restate the most important unfinished criterion and defer optional polish until that criterion is met.

Should I create more agents when progress slows?

First determine the cause. Missing requirements and a mistaken approach need clarification or correction, not more parallel work.

What should a stopped run return?

Usable artifacts, verified results, open problems, and a concrete next action so the work can resume without repeating completed steps.