Start with a deliverable someone can check
A request such as "analyze this business" leaves the model to choose the scope, evidence, audience, and format. Our suggested alternative is a short task brief with five parts: the outcome, the materials, the constraints, the acceptance checks, and the actions you authorize. This is an editorial workflow, not an official OpenAI prompt or a measured performance guarantee.
For example, a website owner could use the following brief when commissioning an article. Replace the example details with the actual files and audience for the task.
Write an 800-word article for small business owners using the three attached reports. Explain the practical implications and link each numerical claim to its source. Flag conflicting evidence. Deliver the finished article and a short list of facts that still need verification. Ask about missing information that would change the conclusion; continue drafting the sections that have enough evidence. Prepare a draft for review before publication.
The word count is a format preference. The sources and verification requirements determine whether the result is usable. A stronger model still needs those inputs to make an evidence-based recommendation.
Check the materials before raising the effort
OpenAI's Work and Codex usage guide says reasoning effort is separate from model selection. Higher effort can consume more allowance without always improving the result; it cannot supply missing files or permissions. Low or Medium is a suggested starting point for Astra when moving from Sol at High.
Use that as a starting experiment. If a comparison omits a supplier, first check whether the supplier's file was attached and successfully read. If all the evidence is present but the tradeoff is difficult, increasing effort is a more relevant experiment. Save the original output so you can compare the specific omission afterward.
Match the workflow to the uncertainty
- Clear task, clear answer: try a lower effort setting for extraction, formatting, or a bounded edit, then check the required fields.
- Several sources or constraints: use a moderate starting setting and require source references for conclusions.
- Unfamiliar problem or repeated reasoning errors: test a higher setting on the difficult part and compare the result against a concrete acceptance check.
These are our task-level heuristics. They do not imply a fixed speed or quality gain. In an API application, set and log the supported effort value explicitly. The reasoning documentation identifies reasoning.effort as the Responses API control and notes that Astra does not support none. A ChatGPT interface may offer different controls from your API client.
Separate tasks at a useful boundary
For a report, sensible stages are gathering evidence, resolving contradictions, drafting, and checking the final claims. For a code change, they might be reproducing the issue, making the edit, and verifying the affected behavior. Keep each stage's output concrete so the next stage has something dependable to use.
Do not create a separate conversation for every sentence. Repeatedly reconstructing context adds work. Start a fresh task when the objective materially changes or the history has become difficult to audit, and bring a compact handoff: the current goal, confirmed facts, relevant files, open questions, and acceptance checks.
Give corrections that identify the failure
"This is bad, try harder" gives little information about the repair. A more useful follow-up is: "The second paragraph treats a vendor forecast as an observed result. Label it as a forecast, preserve the date, and check the other numerical claims for the same issue." This turns dissatisfaction into a checkable edit.
Our suggested stopping rule is simple: finish when the agreed checks pass and any unresolved gaps are visible. If repeated attempts still fail the same check, isolate that failure using the quality-drop diagnosis guide. Track the time spent reviewing with the efficiency scorecard so a longer answer does not automatically count as progress.