GPT-6 prompting guide: Astra, Sol and Luna, and what to change from 5.x

If you are moving to GPT-6, three changes cause most of the pain: none and minimal reasoning effort are gone on the bigger models, sampling parameters like temperature are rejected while reasoning is on, and tool calling has to go through the Responses API. After that, the work is mostly about instruction style: GPT-6 follows instructions more closely, asks more questions, and formats more than you probably want.

Everything below was read on OpenAI's own developer pages on 2026-10-09 (links in each section). I did not call the API for this post, so nothing here is a measured result. The one thing I ran is a small request linter, and its real output is further down. If you want the older model's story, GPT-5 prompting is a separate post.

Which GPT-6 model is which?

OpenAI's model catalog lists three current tiers. All three show a 1.05M context window, 128K max output and text plus image input. Prices are per million tokens, standard processing, prompts up to 272K tokens, from the pricing page:

Two details worth knowing. Prompts over 272K input tokens are billed at 2x input and 1.5x output for the whole request. Cache writes are billed at 1.25x the input rate. The pricing page also still lists gpt-6-sol and the gpt-5.6-* family, and the GPT-6 guide says that gpt-6-sol and Luna accept none while Astra and 6.1 Sol do not. Tier names have changed within weeks (the original gpt-6-sol now sits beside gpt-6.1-sol), so treat the vendor page as the source; our October digest tracks the rollout.

What breaks on a GPT-5.x request?

OpenAI's GPT-6 migration quickstart lists the changes. I turned them into a linter so you can paste your own request bodies into it. This is the core of it (trimmed; the full run also checked Chat Completions logprobs and adjacent configuration_update items). It is a plain Python function over a dict, no network:

SUPPORTED_EFFORT = {
    "gpt-6-astra": {"low", "medium", "high", "xhigh", "max"},
    "gpt-6.1-sol": {"low", "medium", "high", "xhigh", "max"},
    "gpt-6-luna": {"none", "low", "medium", "high", "xhigh", "max"},
}

def lint(req, api="responses"):
    out, model = [], req.get("model", "")
    effort = (req.get("reasoning") or {}).get("effort") if api == "responses" else req.get("reasoning_effort")
    if effort is not None and effort not in SUPPORTED_EFFORT[model]:
        out.append(f"ERROR effort '{effort}' is not listed for {model}: use 'low' and compare")
    if not (effort == "none" and model == "gpt-6-luna"):
        for p in ("temperature", "top_p", "top_logprobs"):
            if p in req:
                out.append(f"ERROR '{p}' must be removed when reasoning effort is not 'none'")
    if api == "chat" and req.get("tools") and not (model == "gpt-6-luna" and effort == "none"):
        out.append("ERROR tool calling needs the Responses API for this model and effort")
    if "prompt_cache_retention" in req:
        out.append('WARN  replace prompt_cache_retention with prompt_cache_options.ttl = "30m"')
    return out or ["OK"]

I ran the full version on four invented request shapes on 2026-10-09. Real output:

Old GPT-5.x style request on Astra
  ERROR effort 'none' is not listed for gpt-6-astra: use 'low' and compare
  ERROR 'temperature' must be removed when reasoning effort is not 'none'
  WARN  replace 'prompt_cache_retention' with prompt_cache_options.ttl = "30m"

Chat Completions with tools on Sol
  ERROR effort 'minimal' is not listed for gpt-6.1-sol: use 'low' and compare
  ERROR 'logprobs' must be removed on Chat Completions
  ERROR tool calling needs the Responses API for this model and effort

Luna, no reasoning, sampling kept
  OK    no rule from the migration notes was violated

Adjacent configuration updates
  ERROR two configuration_update items are adjacent; the API rejects that

Two caveats. The linter encodes only what OpenAI's pages state, so a clean result is not a guarantee. And the Luna case passes because the docs say sampling parameters are removed "when reasoning effort is not none"; I have not sent that request to the API. OpenAI also says that when migrating from GPT-5.5 or earlier you should replace prompt_cache_retention with prompt_cache_options.ttl, and review the cache-boundary and cache-write billing changes on the prompt caching page.

How should I set reasoning effort on GPT-6?

Treat effort as a dial you sweep on your own tasks, not a setting you inherit. OpenAI's reasoning guide describes low for tool use and drafting, medium for planning and judgement (the default on 6.1 Sol and Luna), high for hard debugging and deep planning, and xhigh and max only when your evals show a clear benefit that justifies the latency and cost. If you currently run xhigh, the guide says to evaluate whether max improves results.

Three controls are new or changed:

• configuration_update. Add {"type": "configuration_update", "reasoning": {"effort": "high"}} as an input item before the next user message to raise or lower effort without rewriting the prompt prefix, which keeps the cache. The response still reports the request-level effort, not the one set by the update.
• reasoning.mode: "pro". GPT-5.6 and GPT-6 models accept standard or pro. Pro does more model work, and those tokens are billed at the model's normal rates, so cost rises with it.
• Preserved reasoning. For function calling, pass back the reasoning items from the last tool call. previous_response_id is the simple way.

One more line from that guide is worth taping to your monitor: treat reasoning.effort as a tuning knob, not the primary way to recover quality. If a task fails at low, ask first whether the prompt states what done looks like. For the cross-vendor view of these dials see reasoning effort controls, explained.

What changes in how you write the prompt?

OpenAI's GPT-6 page describes five behaviours observed with Astra and says to evaluate its starter prompts on your own model and workload. Paraphrased, with my own untested templates:

It asks before it acts. Astra is more likely to stop and ask when extra input could change the result, which can look like stalling in an agent. Tell it what you authorise. Untested template:

Treat requests like "can you...", "help me..." and "I want to..." as instructions to do the work.
Finish the task before replying. Ask a question only if the answer would change what you build
and you cannot find it in the context. Before any irreversible step (deploy, merge, send), prepare
the full change so my approval is the last step.

It reads your instruction files closely. OpenAI says Astra can be more sensitive to instructions in skills and files like AGENTS.md, and "strongly recommends" auditing them. Conflicting rules in an old skill file can make it pause. Add a precedence line (user instructions beat skill guidance) and grep your files for stale rules such as "always ask before editing".

It formats heavily. The vendor says Astra tends toward lists, tables and Markdown. If your product needs prose, say so in the system message with the structure you want, in one paragraph rather than five bullet rules.

It may delegate less than you want, and may over-test. For multi-agent harnesses, state when to use subagents. For coding, state how much verification a small change deserves, or you will pay for broad test runs on one-line edits.

Old habits to drop, with the evidence level stated honestly: "think step by step" is no longer needed to get reasoning, because the model reasons by default (the reasoning guide advises a goal, constraints and an output contract instead of prescribing steps; that sentence is written for GPT-5 reasoning models and I am assuming it carries over, so test it). Shouting in capitals to get compliance is also worth removing first, because OpenAI describes Astra's instruction following as stronger than earlier models, so forceful wording has more to push against. That second step is my inference rather than something the vendor states, and I have no measurement of it; test it.

How does tool use work on GPT-6?

Use the Responses API. On Astra and 6.1 Sol, Chat Completions is fine for requests without tools only. On Luna, function calling over Chat Completions works only with effort none. The model pages list web search, file search, code interpreter, hosted shell, apply patch, skills, computer use, MCP and tool search as Responses tools.

Two features change agent design:

• Async tool calling. Set async: true on a function or custom tool. The model keeps reasoning or calls other tools while your code runs it, and you return the result later with the original call_id. Your application still runs the tool and tracks what is pending.
• Mid-turn steering. Over a WebSocket connection you can send a correction while the model is working; completed work is preserved and the update goes into a continuation.

Both are described on OpenAI's pages (async tool calling, steering); I have not run either. If you build agents, pair this with a defined "done" and a tool-failure rule in the prompt, and read function calling explained first if the pattern is new to you.

How do I get structured output?

Structured Outputs works on GPT-6 per the GPT-6 page. In the Responses API you set text.format to a JSON Schema with strict on, and OpenAI's docs note that safety refusals become programmatically detectable. Unrun request body, shaped from the docs:

{
  "model": "gpt-6.1-sol",
  "reasoning": { "effort": "low" },
  "input": "Extract the event: Lunch with Priya on 2026-11-03.",
  "text": {
    "format": {
      "type": "json_schema",
      "name": "calendar_event",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "date": { "type": "string" }
        },
        "required": ["name", "date"],
        "additionalProperties": false
      }
    }
  }
}

A schema guarantees the shape, not the truth. A date can be well-formed and wrong. Validate values in code, and read structured outputs across providers for the comparison with Claude and Gemini.

GPT-5.x to GPT-6 migration checklist

1. Pick the target tier with a cheap eval, not by reputation. Run the same 30 to 50 real inputs on Luna, then Sol, then Astra. See migrating prompts to new models for the audit loop.
2. Replace none and minimal effort with low on Astra and 6.1 Sol, then compare.
3. Delete temperature, top_p, top_logprobs and logprobs includes wherever effort is not none.
4. Move every tool-calling path to Responses.
5. Replace prompt_cache_retention with prompt_cache_options.ttl: "30m" and re-check cache hit rates; cache writes now cost 1.25x.
6. Audit AGENTS.md, skills and system prompts for contradictions and add a precedence line.
7. Add follow-through, formatting and verification instructions only where you see the behaviour, one at a time.
8. If you vary effort between turns, use configuration_update rather than changing request-level effort.
9. Check data residency: Fast mode supports EU residency for 6.1 Sol, GPT-6 Sol and Luna but not Astra, and regional processing carries a 10% uplift on eligible models released on or after March 5, 2026, per the pricing page.
10. Compare cost per finished task, not price per token. OpenAI claims Astra used substantially fewer output tokens in several of its own evaluations, which is a vendor claim I have not checked. Measure it, and use LLM API cost per 1,000 requests for the arithmetic.

What I could not verify

I did not call the API, so I have not confirmed any 400 error string or the Luna none plus sampling case. I read the Markdown versions of OpenAI's docs through curl; the pages can change, and the model catalog page and guide were not fully consistent about which Sol is current, so check the model page for your account's access. I did not read the Realtime, GPT-Live or Codex model pages.