From f1558ae72dff45681becb01f762b1c63ad5a0752 Mon Sep 17 00:00:00 2001 From: Konstantine Kahadze Date: Tue, 8 Sep 2026 13:35:23 -0700 Subject: [PATCH] Sync public OpenAI Docs fallbacks for GPT-6 Astra --- .../openai-docs/references/latest-model.md | 50 ++-- .../openai-docs/references/prompting-guide.md | 247 +++++------------- .../openai-docs/references/upgrade-guide.md | 187 +------------ .../references/upgrading-to-gpt-6-astra.md | 221 ++++++++++++++++ .../openai-docs/references/latest-model.md | 49 ++-- .../openai-docs/references/prompting-guide.md | 247 +++++------------- .../openai-docs/references/upgrade-guide.md | 187 +------------ .../references/upgrading-to-gpt-6-astra.md | 221 ++++++++++++++++ 8 files changed, 626 insertions(+), 783 deletions(-) create mode 100644 skills/.curated/openai-docs/references/upgrading-to-gpt-6-astra.md create mode 100644 skills/.system/openai-docs/references/upgrading-to-gpt-6-astra.md diff --git a/skills/.curated/openai-docs/references/latest-model.md b/skills/.curated/openai-docs/references/latest-model.md index a1ffbfb..d4fca8c 100644 --- a/skills/.curated/openai-docs/references/latest-model.md +++ b/skills/.curated/openai-docs/references/latest-model.md @@ -1,37 +1,25 @@ -# Latest model guide +# Latest model fallback -This file is a curated helper. Every recommendation here must be verified against current OpenAI docs before it is repeated to a user. +This is a compact, non-authoritative fallback, not a source for current availability, prices, aliases, or defaults. First search for and fetch current official model guidance at `https://developers.openai.com/api/docs/guides/latest-model` and the relevant official model page. The fetched official documentation wins if this snapshot has drifted. Disclose any use of this fallback. -## Current model map +## Model roles -| Model ID | Use for | +| Model ID | Documented workload to verify against the current model page | | --- | --- | -| `gpt-5.5` | Latest/default text and reasoning model for most new apps, including coding and tool-heavy workflows | -| `gpt-5.5-pro` | Maximum reasoning or quality when latency and cost matter less | -| `gpt-5.4` | Previous default text and reasoning model; use for existing GPT-5.4 integrations | -| `gpt-5.4-mini` | Lower-cost testing and lighter production workflows | -| `gpt-5.4-nano` | High-throughput simple tasks and classification | -| `gpt-5.5` | Explicit no-reasoning text path via `reasoning.effort: none` | -| `gpt-4.1-mini` | Cheaper no-reasoning text | -| `gpt-4.1-nano` | Fastest and cheapest no-reasoning text | -| `gpt-5.3-codex` | Agentic coding, code editing, and tool-heavy coding workflows | -| `gpt-5.1-codex-mini` | Cheaper coding workflows | -| `gpt-image-2` | Best image generation and edit quality | -| `gpt-image-1.5` | Less expensive image generation and edit quality | -| `gpt-image-1-mini` | Cost-optimized image generation | -| `gpt-4o-mini-tts` | Text-to-speech | -| `gpt-4o-mini-transcribe` | Speech-to-text, fast and cost-efficient | -| `gpt-realtime-1.5` | Realtime voice and multimodal sessions | -| `gpt-realtime-mini` | Cheaper realtime sessions | -| `gpt-audio` | Chat Completions audio input and output | -| `gpt-audio-mini` | Cheaper Chat Completions audio workflows | -| `sora-2` | Faster iteration and draft video generation | -| `sora-2-pro` | Higher-quality production video | -| `omni-moderation-latest` | Text and image moderation | -| `text-embedding-3-large` | Higher-quality retrieval embeddings; default in this skill because no best-specific row exists | -| `text-embedding-3-small` | Lower-cost embeddings | +| `gpt-6` | GPT-6 family alias; verify its currently documented routing and availability. | +| `gpt-6-astra` | Quality-first flagship, reasoning, and difficult coding work. | +| `gpt-5.6-terra` | Balanced quality, latency, and cost. | +| `gpt-5.6-luna` | Primary choice for faster or cheaper workloads. | -## Maintenance notes +Use `https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#migration-quickstart` for an actual GPT-6 migration and `https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices` for requested GPT-6 prompting. Open and read the relevant page before recommending a request shape, reasoning setting, endpoint, tool behavior, or migration. -- This file will drift unless it is periodically re-verified against current OpenAI docs. -- If this file conflicts with current docs, the docs win. +## Explicitly requested existing models + +| Model ID | Boundary | +| --- | --- | +| `gpt-4.1` | Preserve only when the user explicitly requests this model or existing migration target; search and fetch its own current official guide. | +| `gpt-5.4` | Preserve only when the user explicitly requests this model or existing migration target; search and fetch its own current official guide. | + +Do not promote a legacy model as the current default, substitute it into an unrelated task, or replace an explicitly requested legacy target with GPT-6 Astra. Recommend a specialized image, audio, realtime, coding, moderation, or embedding model only after verifying the requested modality against current official documentation. + +Verify GPT-6 Pro against current official Responses and model documentation before describing model IDs, reasoning modes, request parameters, or account availability; do not invent a separate `gpt-6-pro` model slug. diff --git a/skills/.curated/openai-docs/references/prompting-guide.md b/skills/.curated/openai-docs/references/prompting-guide.md index 0d9273c..2370a8a 100644 --- a/skills/.curated/openai-docs/references/prompting-guide.md +++ b/skills/.curated/openai-docs/references/prompting-guide.md @@ -1,244 +1,115 @@ -GPT-5.5 works best when prompts define the outcome and leave room for the model to choose an efficient solution path. Compared with earlier models, you can often use shorter, more outcome-oriented prompts: describe what good looks like, what constraints matter, what evidence is available, and what the final answer should contain. +## Retrieve the live GPT-6 prompting guidance -Avoid carrying over every instruction from an older prompt stack. Legacy prompts often over-specify the process because earlier models needed more help staying on track. With GPT-5.5, that can add noise, narrow the model's search space, or lead to overly mechanical answers. +Use already-callable official documentation search and fetch, or immediately use official-domain web search and fetch, to retrieve the live GPT-6 prompting guidance from: -For more detail on GPT-5.5 behavior changes, start with the [Using GPT-5.5 guide](/api/docs/guides/latest-model). This guide focuses on prompt changes that follow from those behavior changes. +https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices -The patterns here are starting points. Adapt them to your product surface, tools, evals, and user experience goals. +Read only the `## Prompting best practices` section, stopping at the next H2 heading. The URL anchor points to the section visually, but a documentation fetch may return the full page, so explicitly extract only that section. -## Personality and behavior +Treat the live section as the canonical model-specific prompting guidance. Use the local copy below only when live guidance is unavailable. Keep it identical to the page's `## Prompting best practices` section when refreshing this reference. -GPT-5.5's default style is efficient, direct, and task-oriented. This is useful for production systems: responses stay focused, behavior is easier to steer, and the model avoids unnecessary conversational padding. +## Prompting best practices -For customer-facing assistants, support workflows, coaching experiences, and other conversational products, define both personality and collaboration style. +GPT-6 Astra is more intelligent and capable than prior models like GPT-5.6 Sol, and also exhibits behavior patterns that can be optimized through prompting the model for your use case. -- **Personality** controls how the assistant sounds: tone, warmth, directness, formality, humor, empathy, and level of polish. -- **Collaboration style** controls how the assistant works: when it asks questions, when it makes assumptions, how proactive it should be, how much context it gives, when it checks work, and how it handles uncertainty or risk. +### GPT-6 Astra behavior -Keep both short. Personality instructions should shape the user experience. Collaboration instructions should shape task behavior. Neither should replace clear goals, success criteria, tool rules, or stopping conditions. +- [Initiative and follow-through](#initiative-and-follow-through) – The model is designed to be a more effective collaborator and is thus more likely to ask the user a question when additional input could materially change the result. This can cause it to stop when the user may expect it to make reasonable assumptions and persist. +- [Instruction following](#instruction-following) – GPT-6 Astra is stronger at general instruction following than our previous models, giving you greater control over its behavior. It can be more sensitive to instructions contained in skills and other files, such as `AGENTS.md`. We **strongly recommend** auditing skills and other files accessible to your model for instructions that could influence its behavior. +- [Personality and writing style](#personality-and-writing-style) – The model tends toward detailed, formatted responses and may use recurring phrases across sessions. Specify the writing style and structure your application needs. +- [Subagent delegation](#subagent-delegation) – The model may delegate less often than desired for your workflow. Specify when and how much it should use subagents for parallel work. +- [Testing and verification](#testing-and-verification) – For coding tasks, the model tends to be thorough in testing before considering a task complete. For smaller tasks, this can result in broader tests than the task requires. -Example personality block for a steady task-focused assistant: +### Initiative and follow-through + +GPT-6 Astra is generally better than GPT-5.6 Sol and earlier models at staying coherent during long tasks. It is also more likely to ask for clarification where earlier models would make assumptions. + +To encourage more autonomous work, start with this prompt: ```text -# Personality -You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness. +You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion. -Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow. - -Stay concise without becoming curt. Give enough context for the user to understand and trust the answer, then stop. Use examples, comparisons, or simple analogies when they make the point easier to grasp. When correcting the user or disagreeing, be candid but constructive. When an error is pointed out, acknowledge it plainly and focus on fixing it. - -Match the user's tone within professional bounds. Avoid emojis and profanity by default, unless the user explicitly asks for that style or has clearly established it as appropriate for the conversation. +When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible. ``` -Example personality block for an expressive collaborative assistant: +When the user’s intent is unclear, the model is more likely to ask the user for clarification to proceed. Prompt the model to follow through if the user’s prompt implies authorization: ```text -# Personality -Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context. - -Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints. - -Be thoughtful and grounded when the task calls for synthesis or advice. State a clear recommendation when you have enough context, explain important tradeoffs, and name uncertainty without becoming evasive. +When the user's prompt indicates a request for action, such as "can you...", "I want to...", "help me..." and similar expressions, treat these as instructions to do the work and take action. Do not stop at acknowledging capability (e.g. "Yes…"), proposing a plan, or offering to continue. Do not settle for a partial or "helpful enough" solution that does not fully satisfy the user's task to save time, effort or tokens. If a task requires sustained work, complete all the necessary work until the intended outcome is fulfilled. ``` -For more expressive products, add warmth, curiosity, humor, or point of view explicitly, but keep the block short. Use personality to shape the experience, not to compensate for unclear goals or missing task instructions. - -## Improve time to first visible token with a preamble - -In streaming applications, users notice how long it takes before the first visible response appears. GPT-5.5 may spend time reasoning, planning, or preparing tool calls before emitting visible text. - -For longer or tool-heavy tasks, prompt the model to start with a short preamble: a brief visible update that acknowledges the request and states the first step. This can improve perceived responsiveness without changing the underlying task. - -Use this pattern when the task may take more than one step, require tool calls, or involve a long-running agent workflow. +Prompt the model to ask for approval only after preparing a concrete, reviewable result. This avoids blocking the task before the model has done the work it can, and often leads to quicker task completion. ```text -Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences. +Before asking the user clarifying questions, you should complete the work that is already authorized from context and necessary to make the proposed action concrete and reviewable. The user should be approving a concrete, reviewable result. For example, before deploying a change, writing to an external application, merging a PR or publishing a site, do all the required work first so that user approval is the final step. You don't need user permission for reversible tasks, read-only actions, reviews or fixes, or anything for which authorization is provided earlier in the session or strongly implied from the task instruction. + +Do not introduce unsolicited warnings, disclaimers, approval flows, or safety/compliance checklists due to hypothetical risk. ``` -For coding agents that expose separate message phases, you can be more explicit: +The model also likes to ask non-blocking questions as it’s working by default, so adjust these prompts to match the level of autonomy your application needs. + +### Instruction following + +GPT-6 Astra is better able to follow longer instructions, but can also be more sensitive to information in context. For example, unclear or conflicting guidance in a skill file may cause the model to pause and block work early. Make the priority of user instructions and skills explicit. ```text -You must always start with an intermediary update before any content in the analysis channel if the task will require calling tools. The user update should acknowledge the request and explain your first step. +The user's instructions take precedence over guidelines provided in a skill. If explicit user instructions conflict with a skill's instructions, prioritize the user's instructions. ``` -## Outcome-first prompts and stopping conditions - -GPT-5.5 is strongest when the prompt defines the target outcome, success criteria, constraints, and available context, then lets the model choose the path. - -For many tasks, describe the destination rather than every step. This gives the model room to choose the right search, tool, or reasoning strategy for the task. - -Prefer this: +Asking the model to identify the skill and instruction that caused it to pause or change direction can also be effective in providing transparency into model behavior. ```text -Resolve the customer's issue end to end. - -Success means: -- the eligibility decision is made from the available policy and account data -- any allowed action is completed before responding -- the final answer includes completed_actions, customer_message, and blockers -- if evidence is missing, ask for the smallest missing field +If a skill causes you to ask for permission or confirmation, pause, leave requested work unfinished, or diverge from the user's intent, name and link to the exact SKILL.md file you read, quote the relevant instruction, and briefly explain how it applies. Distinguish explicit skill requirements from your interpretation of guidelines. ``` -**Avoid unnecessary absolute rules.** Older prompts often use strict instructions like `ALWAYS`, `NEVER`, `must`, and `only` to control model behavior. Use those words for true invariants, such as safety rules, required output fields, or actions that should never happen. For judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead. +Use this prompt to find silent and conflicting guidance when your application loads many skills and instruction files such as `AGENTS.md`. -Avoid this style of instruction unless every step is truly required: +### Personality and writing style + +GPT-6 Astra tends to use lists, tables and Markdown to make responses scannable. If your application needs prose with less formatting, specify that preference. ```text -First inspect A, then inspect B, then compare every field, then think through -all possible exceptions, then decide which tool to call, then call the tool, -then explain the entire process to the user. +Default to using clear, concise paragraphs, each developing one main idea. Use lists only when the information is genuinely parallel, sequential, or easier to compare, and avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use plain, simple language: familiar words, concrete examples, and precise verbs. Prefer active voice and direct statements. + +Make sure to state the main point clearly and early, then develop it with the explanation and detail the reader needs. Let each sentence build on what came before. Develop the points that matter and provide enough support to be useful. ``` -Add explicit stopping conditions: +For technical communication, the following prompt helps strike a balance between using clear, coherent language while remaining domain appropriate: ```text -Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims. - -After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer. +Use plain language over jargon, and reference technical details only to the degree that it helps illustrate an idea or your work to the user. Communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the level of background knowledge assumed from the user's prompt and context. ``` -Define missing-evidence behavior: +To reduce jargon and stock phrases in writing, start with this prompt: ```text -Use the minimum evidence sufficient to answer correctly, cite it precisely, then stop. +Avoid using slop words or phrases like "Bottom Line:" in conclusions, "delve," "foster," "leverage," "it's worth noting," "importantly," "Question? Answer." or "This isn't about X. It's about Y.", "genuinely" or hyphenated compound descriptions and adjectives. Do not use concluding summary statements such as "In short:..", "The simplest mental model is:...". + +State the intended action directly. Avoid adding what you won't do, what will remain unchanged, or how you'll separate or categorize results. Do not use contrastive framing such as "X, not Y" or "X—not Y" that introduces an unprompted alternative that the user didn't ask about. Avoid invented compound labels like "exact-head checks" and "editorial-row layouts", vague qualifiers, and canned transitions; use plain verbs and prepositions to state the actual relationship directly. ``` -## Formatting +### Subagent delegation -GPT-5.5 is highly steerable on output format and structure. Use that control when it improves comprehension or product fit. - -Set `text.verbosity`, describe the expected output shape, and reserve heavier structure for cases where it improves comprehension or your product UI needs a stable artifact. The API default for `text.verbosity` is `medium`; use `low` when you prefer shorter, more concise responses. - -Plain conversational formatting: +GPT-6 Astra is trained to be able to divide and delegate work to subagents that work in parallel. If you are implementing a multi-agent system in your harness, use the following prompt to tune how much GPT-6 Astra should delegate work: ```text -Let formatting serve comprehension. Use plain paragraphs as the default format for normal conversation, explanations, reports, documentation, and technical writeups. Keep the presentation clean and readable without making the structure feel heavier than the content. - -Use headers, bold text, bullets, and numbered lists sparingly. Reach for them when the user requests them, when the answer needs clear comparison or ranking, or when the information would be harder to scan as prose. Otherwise, favor short paragraphs and natural transitions. - -Respect formatting preferences from the user. If they ask for a terse answer, minimal formatting, no bullets, no headers, or a specific structure, follow that preference unless there is a strong reason not to. +If at any point you can parallelize work by delegating tasks to another agent (no matter if you are the root or subagent), you should do so using collaboration tools if it could save time or improve quality. ``` -Add explicit audience and length guidance: +Messages between agents may contain grammar or spacing errors. Use this prompt to make inter-agent messages easier to read: ```text -Write for a senior business audience. Keep the answer under 400 words. Use short paragraphs and only include bullets when they improve scannability. Prioritize the conclusion first, then the reasoning, then caveats. +Messages that you send to other agents and your final answer may be read by a human, so ensure they are legible. Always put proper spaces between words and/or numbers. ``` -For editing, rewriting, summaries, or customer-facing messages, tell the model what to preserve before asking it to improve style. This pattern is useful when you want polish without expansion. +The model tends to respond well to prompting for how and when it should delegate work to subagents, so tune this behavior to fit with your harness and multi-agent implementation. + +### Testing and verification + +For coding tasks, calibrate how much testing and verification a change requires. This can help avoid unnecessary tests or repeated checks for small changes. ```text -Preserve the requested artifact, length, structure, and genre first. Quietly improve clarity, flow, and correctness. Do not add new claims, extra sections, or a more promotional tone unless explicitly requested. -``` +Do not write tests for reversible, low-impact changes that mirror the implementation. If you do choose to verify your work with tests, make sure that the tests are meaningful and necessary to verify implementation. -## Grounding, citations, and retrieval budgets - -For grounded answers, citation behavior should be part of the prompt. Define what needs support, what counts as enough evidence, and how the model should behave when evidence is missing. Absence of evidence shouldn't automatically become a factual "no." For more details and examples, see the [citation formatting guide](/api/docs/guides/citation-formatting). - -### Add an explicit retrieval budget - -Retrieval budgets are stopping rules for search. They tell the model when enough evidence is enough. - -```text -For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again. - -Make another retrieval call only when: -- The top results do not answer the core question. -- A required fact, parameter, owner, date, ID, or source is missing. -- The user asked for exhaustive coverage, a comparison, or a comprehensive list. -- A specific document, URL, email, meeting, record, or code artifact must be read. -- The answer would otherwise contain an important unsupported factual claim. - -Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic. -``` - -## Creative drafting guardrails - -For drafting tasks, tell the model which claims must come from sources and which parts may be creatively written. This is especially important for slides, launch copy, customer summaries, talk tracks, leadership blurbs, and narrative framing. - -```text -For creative or generative requests such as slides, leadership blurbs, outbound copy, summaries for sharing, talk tracks, or narrative framing, distinguish source-backed facts from creative wording. - -- Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims. -- Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger. -- If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics. -``` - -## Frontend engineering and visual taste - -For frontend work, refer to the [example instructions](/api/docs/guides/frontend-prompt) for practical ways to steer UI quality. They cover product and user context, design-system alignment, first-screen usability, familiar controls, expected states, responsive behavior, and common generated-UI defaults to avoid, such as generic heroes, nested cards, decorative gradients, visible instructional text, and broken layouts. - -## Prompt the model to check its work - -Give GPT-5.5 access to tools that let it check outputs when validation is possible. - -For coding agents, ask for concrete validation commands: - -```text -After making changes, run the most relevant validation available: -- targeted unit tests for changed behavior -- type checks or lint checks when applicable -- build checks for affected packages -- a minimal smoke test when full validation is too expensive - -If validation cannot be run, explain why and describe the next best check. -``` - -For visual artifacts, ask for inspection after rendering: - -```text -Render the artifact before finalizing. Inspect the rendered output for layout, clipping, spacing, missing content, and visual consistency. Revise until the rendered output matches the requirements. -``` - -For engineering and planning tasks, make implementation plans traceable: - -```text -For implementation plans, include: -- requirements and where each is addressed -- named resources, files, APIs, or systems involved -- state transitions or data flow where relevant -- validation commands or checks -- failure behavior -- privacy and security considerations -- open questions that materially affect implementation -``` - -## Phase parameter - -Starting with GPT-5.4, long-running or tool-heavy Responses workflows can use assistant-item `phase` values to distinguish intermediate updates from final answers. GPT-5.5 uses the same pattern. - -If you use `previous_response_id`, the API preserves prior assistant state automatically. If your application manually replays assistant output items into the next request, preserve each original `phase` value and pass it back unchanged. This matters most when a response includes preambles, repeated tool calls, or a final answer after intermediate assistant updates. - -```text -If manually replaying assistant items: -- Preserve assistant `phase` values exactly. -- Use `phase: "commentary"` for intermediate user-visible updates. -- Use `phase: "final_answer"` for the completed answer. -- Do not add `phase` to user messages. -``` - -## Suggested prompt structure - -Use this structure as a starting point for complex prompts. Keep each section short. Add detail only where it changes behavior. - -```text -Role: [1-2 sentences defining the model's function, context, and job] - -# Personality -[tone, demeanor, and collaboration style] - -# Goal -[user-visible outcome] - -# Success criteria -[what must be true before the final answer] - -# Constraints -[policy, safety, business, evidence, and side-effect limits] - -# Output -[sections, length, and tone] - -# Stop rules -[when to retry, fallback, abstain, ask, or stop] +Run tests appropriate to the change and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it; otherwise, continue toward completing the task. ``` diff --git a/skills/.curated/openai-docs/references/upgrade-guide.md b/skills/.curated/openai-docs/references/upgrade-guide.md index b29f137..af059c1 100644 --- a/skills/.curated/openai-docs/references/upgrade-guide.md +++ b/skills/.curated/openai-docs/references/upgrade-guide.md @@ -1,181 +1,22 @@ -# Upgrading to GPT-5.5 +# Model upgrade guidance -Use this guide when the user explicitly asks to upgrade an existing integration to GPT-5.5. Pair it with current OpenAI docs lookups. The default target string is `gpt-5.5`. +Use this file only as a bundled routing fallback when the live migration guide cannot be fetched. -## Freshness check +For latest, current, default, or unspecified-model upgrades: -Before applying this bundled guide for a latest/current/default model upgrade, run `node scripts/resolve-latest-model-info.js` from the OpenAI Docs skill directory. +1. Run `node scripts/resolve-latest-model-info.js`. +2. Fetch the returned `migrationGuideUrl` and `promptingGuideUrl` exactly. +3. Treat the live guides as canonical. +4. If remote retrieval fails, disclose that bundled fallback guidance is being used. -- If the command returns `modelSlug: "gpt-5p5"`, continue with this bundled guide and use `references/prompting-guide.md` when prompt updates are needed. -- If the command returns a different `modelSlug`, fetch both the returned `migrationGuideUrl` and `promptingGuideUrl` and use them as the current source of truth instead of the bundled references. -- If the command fails, metadata is missing, or either remote guide cannot be fetched, continue with bundled fallback references and say the remote freshness check was unavailable. -- If the user explicitly named a target model, preserve that target and use current docs only to check compatibility or caveats. +For an explicit GPT-6 Astra migration: -## Upgrade posture +1. Preserve the user's explicit target; do not run the latest-model resolver. +2. Fetch the live GPT-6 model guidance: -Upgrade with the narrowest safe change set: + https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md -- replace the model string first -- update only the prompts that are directly tied to that model usage -- do not automatically upgrade older or ambiguous model usages that may be intentionally pinned, such as historical docs, examples, tests, eval baselines, comparison code, or low-cost fallback/routing paths. Unless the user explicitly asks to upgrade all model usage, leave those sites unchanged and list them as confirmation-needed -- prefer prompt-only upgrades when possible -- if the upgrade would require API-surface changes, parameter rewrites, tool rewiring, provider migration, or broader code edits, mark it as blocked instead of stretching the scope +3. Read `references/upgrading-to-gpt-6-astra.md` for skill-specific migration judgment. +4. Read `references/prompting-guide.md` only when prompt changes are needed. -## Upgrade workflow - -1. Inventory current model usage. - - Search for model strings, client calls, and prompt-bearing files. - - Include inline prompts, prompt templates, YAML or JSON configs, Markdown docs, and saved prompts when they are clearly tied to a model usage site. -2. Pair each model usage with its prompt surface. - - Prefer the closest prompt surface first: inline system or developer text, then adjacent prompt files, then shared templates. - - If you cannot confidently tie a prompt to the model usage, say so instead of guessing. -3. Classify the source model family. - - Common buckets: GPT-5.4, GPT-5.3-Codex or GPT-5.2-Codex, earlier GPT-5.x, GPT-4o or GPT-4.1, reasoning models such as o1 or o3 or o4-mini, third-party model, or mixed and unclear. -4. Decide the upgrade class. - - `model string only` - - `model string + light prompt rewrite` - - `blocked without code changes` -5. Run the compatibility gate. - - Check whether the current integration can accept `gpt-5.5` without API-surface changes or implementation changes. - - Check whether structured outputs, tool schemas, function names, and downstream parsers can remain unchanged. - - For long-running Responses or tool-heavy agents, check whether `phase` is already preserved or round-tripped when the host replays assistant items or uses preambles. - - If compatibility depends on code changes, return `blocked`. - - If compatibility is unclear, return `unknown` rather than improvising. -6. Apply the upgrade when it is in scope. - - Default replacement string: `gpt-5.5`. - - Keep the intervention small and behavior-preserving. - - Start from the current reasoning effort when it is visible unless there is a measured reason to change it. - - For in-scope changes, update the model string and directly related prompts. - - For blocked or unknown changes, do not edit; report the blocker or uncertainty. -7. Summarize the result. - - `Current model usage` - - `Model-string updates` - - `Reasoning-effort handling` - - `Prompt updates` - - `Structured output and formatting assessment` - - `Tool-use assessment` when the flow uses tools, retrieval, or terminal actions - - `Phase assessment` when the flow is long-running, replayed, or tool-heavy - - `Compatibility check` - - `Validation performed` - -Output rule: - -- For each usage site, state the starting reasoning-effort recommendation. -- If the repo exposes the current reasoning setting, recommend preserving it first unless current OpenAI docs say otherwise. -- If the repo does not expose the current setting, recommend not adding one unless current OpenAI docs require it. - -## Upgrade outcomes - -### `model string only` - -Choose this when: - -- the source model is GPT-5.4 -- the existing prompts are already short, explicit, and task-bounded -- the workflow does not rely on strict output formats, tool-call behavior, batch completeness, or long-horizon execution that should be validated after the upgrade -- there are no obvious compatibility blockers - -Default action: - -- replace the model string with `gpt-5.5` -- preserve the current reasoning effort -- keep prompts unchanged -- validate behavior with existing tests, realistic spot checks, or an existing eval suite when one is already available - -### `model string + light prompt rewrite` - -Choose this when: - -- the task needs stronger completeness, citation discipline, verification, or dependency handling -- the upgraded model becomes too verbose, too dense, or hard to scan unless formatting is constrained -- the workflow has strict output shape requirements and lacks an explicit format contract, schema, or parser validation -- the workflow is research-heavy and needs stronger handling of sparse or empty retrieval results -- the workflow is coding-oriented, terminal-based, tool-heavy, or multi-agent, but the existing API surface and tool definitions can remain unchanged - -Default action: - -- replace the model string with `gpt-5.5` -- preserve the current reasoning effort for the first pass -- make only the smallest prompt edits needed for the observed workflow risk -- read the [GPT-5.5 prompting guide](/api/docs/guides/prompt-guidance?model=gpt-5.5) to choose the smallest prompt changes that recover or improve behavior -- avoid broad prompt cleanup unrelated to the upgrade -- for research workflows, add citation rules, retrieval budgets, missing-evidence behavior, and validation guidance from the prompting guide -- for dependency-aware or tool-heavy workflows, add prerequisite checks, missing-context handling, explicit tool budgets, stop conditions, and validation guidance -- for coding or terminal workflows, add repo-specific constraints, acceptance criteria, and concrete validation commands -- for multi-agent support or triage workflows, add task ownership, handoff, completeness, and stopping criteria -- for long-running Responses agents with preambles or multiple assistant messages, explicitly review whether `phase` is already handled; if adding or preserving `phase` would require code edits, mark the path as `blocked` -- do not classify a coding or tool-using Responses workflow as `blocked` just because the visible snippet is minimal; prefer `model string + light prompt rewrite` unless the repo clearly shows that a safe GPT-5.5 path would require host-side code changes - -### `blocked` - -Choose this when: - -- the upgrade appears to require API-surface changes -- the upgrade appears to require parameter rewrites or reasoning-setting changes that are not exposed outside implementation code -- the upgrade would require changing tool definitions, tool handler wiring, or schema contracts -- the user is asking for a tooling, IDE, plugin, shell, or environment migration rather than a model and prompt migration -- the integration depends on provider-specific APIs that do not map to the current OpenAI API surface without implementation work -- you cannot confidently identify the prompt surface tied to the model usage - -Default action: - -- do not improvise a broader upgrade -- report the blocker and explain that the fix is out of scope for this guide -- if useful, describe the smallest follow-up implementation task that would unblock the migration - -## Compatibility checklist - -Before applying or recommending a model-and-prompt-only upgrade, check: - -1. Can the current host accept the `gpt-5.5` model string without changing client code or API surface? -2. Are the related prompts identifiable and editable? -3. Does the host depend on behavior that likely needs API-surface changes, parameter rewrites, provider migration, or tool rewiring? -4. Would the likely fix be prompt-only, or would it need implementation changes? -5. Is the prompt surface close enough to the model usage that you can make a targeted change instead of a broad cleanup? -6. Do strict structured outputs, schemas, or downstream parsers still have an explicit contract? -7. For long-running Responses or tool-heavy agents, is `phase` already preserved if the host relies on preambles, replayed assistant items, or multiple assistant messages? -8. Are latency, token, or price assumptions validated by tests, realistic spot checks, or an existing eval suite rather than inferred from general model positioning? - -If item 1 is no, items 3 through 4 point to implementation work, or item 7 is no and the fix needs code changes, return `blocked`. - -If item 2 is no, return `unknown` unless the user can point to the prompt location. - -Important: - -- Existing use of tools, agents, or multiple usage sites is not by itself a blocker. -- If the current host can keep the same API surface and the same tool definitions, prefer `model string + light prompt rewrite` over `blocked`. -- Reserve `blocked` for cases that truly require implementation changes, not cases that only need stronger prompt steering. -- Do not claim token savings without task-level validation. - -## Scope boundaries - -This guide may: - -- update or recommend updated model strings -- update or recommend updated prompts -- inspect code and prompt files to understand where those changes belong -- inspect whether existing Responses flows already preserve `phase` -- flag compatibility blockers -- propose validation with existing tests, realistic spot checks, or existing eval suites - -This guide may not: - -- move Chat Completions code to Responses -- move Responses code to another API surface -- migrate SDKs, APIs, IDE configuration, shell hooks, plugins, or provider-specific tooling -- rewrite parameter shapes -- change tool definitions or tool-call handling -- change structured-output wiring -- add or retrofit `phase` handling in implementation code -- edit business logic, orchestration logic, SDK usage, IDE configuration, shell hooks, or plugin integration behavior except for model-string replacements and directly related prompt edits - -If a safe GPT-5.5 upgrade requires any of those changes, mark the path as blocked and out of scope. - -## Validation plan - -- Validate each upgraded usage site with existing tests, realistic spot checks, or an existing eval suite when one is already available. -- Compare against the current GPT-5.4 baseline when available. -- Check task success, retry count, tool-call count, total tokens, latency, output shape, and user-visible quality. -- For specialized workflows, validate the contract that matters most instead of judging only general output quality. -- If prompt edits were added, confirm each block is doing real work instead of adding noise. -- If the workflow has downstream impact, add a lightweight verification pass before finalization. +For another explicit model target, preserve that target and fetch its current official guidance. Do not reuse GPT-6-specific defaults, API shapes, or compatibility rules for a different model. diff --git a/skills/.curated/openai-docs/references/upgrading-to-gpt-6-astra.md b/skills/.curated/openai-docs/references/upgrading-to-gpt-6-astra.md new file mode 100644 index 0000000..49d138e --- /dev/null +++ b/skills/.curated/openai-docs/references/upgrading-to-gpt-6-astra.md @@ -0,0 +1,221 @@ +# Upgrading to GPT-6 Astra + +Use this guide when the user asks to migrate an existing OpenAI API integration, repository, prompt stack, agent, model router, or model picker to GPT-6 Astra. + +The default explicit target is `gpt-6-astra`. Verify the `gpt-6` family alias's currently documented routing and availability before using it. Do not treat every old model usage as an Astra candidate: retain Terra for balanced work and Luna as the primary faster or cheaper model. + +Before changing code, retrieve the current live GPT-6 model guidance using already-callable official documentation search and fetch, or immediately use official-domain web search and fetch: + +https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md + +For prompt changes, also read only the `## Prompting best practices` section from: + +https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices + +Treat live docs as canonical for current model IDs, parameters, limits, pricing, and feature availability. The skill-specific workflow below covers repository inspection, scope preservation, and validation. The fallback after it includes all non-prompting guidance, including access notices, examples, caveats, and `## Migration quickstart`; the full prompting section is in `references/prompting-guide.md`. When refreshing, preserve all guide content unless it is specific to the website rather than useful to the skill, and record any omission. Remove website metadata and component markup while retaining their readable content. Resolve site-relative links against `https://developers.openai.com` and section-only links against the canonical model-guide URL above. + +## Core principle + +Do not perform a blind model-string replacement. + +First preserve the behavior, latency class, cost class, reasoning level, endpoint contract, tool semantics, cache behavior, and output contract of each usage site. Then make the smallest safe migration. Adopt new GPT-6 capabilities only when they solve a measured problem or the user explicitly asks for them. + +A model upgrade alone does not authorize adding reasoning fields, changing request schemas, or rewriting tests. Set a supported reasoning effort explicitly to preserve the source model's effective behavior; verify omitted defaults rather than guessing. + +## Migration posture + +Classify every usage site before editing: + +1. `simple Astra migration` + - One flagship model usage. + - Same endpoint and request shape can remain. + - Reasoning effort is explicit or its old effective value is known. + - No cache, vision, file, tool, or parser behavior needs implementation changes. +2. `tier-aware family migration` + - The repository exposes multiple model roles, model choices, fallbacks, routers, pricing data, or capability metadata. + - Map each role to Astra, Terra, or Luna instead of replacing everything with Astra. +3. `compatibility migration` + - The safe move requires parameter, endpoint, cache, state, tool-loop, or multimodal-detail changes. + - Make these changes only when implementation work is inside the user's requested scope. Otherwise report the exact blocker and smallest follow-up. +4. `prompt migration` + - The API shape can remain, but representative traces show a prompt-specific regression. + - Make a surgical prompt edit tied to that failure; do not rewrite a working prompt stack wholesale. + - When the task is to update prompting guidance, edit the directly tied prompt surface only. Do not modify runtime request code, model schemas, or tests unless the prompt change requires it. +5. `optional feature adoption` + - Pro mode, persisted reasoning, explicit caching, Programmatic Tool Calling, or multi-agent behavior is being added deliberately. + - Keep this separate from the baseline migration so its effect can be measured. +6. `leave unchanged` + - Historical examples, documentation about old models, snapshots, fixtures, eval baselines, comparison code, intentionally pinned fallbacks, unsupported providers, or ambiguous usages. + +When intent is unclear, prefer leaving a usage unchanged and list it for confirmation over silently changing its role. + +## Inventory before editing + +Search for more than literal model IDs. Inventory: + +- model strings, aliases, environment variables, CLI flags, config defaults, and deployment settings; +- SDK calls to Responses, Chat Completions, Batch, or provider adapters; +- reasoning settings, token budgets, sampling settings, and latency timeouts; +- function tools, hosted tools, structured outputs, response parsers, and replay logic; +- system, developer, user, and tool-description prompts tied to each usage; +- routers, fallbacks, model allowlists, enums, regexes, validation schemas, and capability maps; +- model picker UI, display labels, descriptions, context limits, pricing metadata, and provider catalogs; +- prompt-cache keys, retention options, stable-prefix construction, and cache metrics; +- image, PDF, file, OCR, and computer-use inputs; +- tests, fixtures, snapshots, evals, analytics labels, billing tables, and docs. + +When changing a default model, search every active default surface: runtime config, environment/config files, setup docs, tests, CLI defaults, and deployment examples. Update them together. + +For each usage site, record: + +- source model and why it appears to be used; +- endpoint and SDK/client surface; +- prompt surface; +- effective reasoning effort, including defaults; +- latency, cost, context, and quality role; +- tools, structured outputs, caching, state replay, and multimodal inputs; +- downstream parsers or user-visible contracts; +- migration class and validation plan. + +## Choose the target model by role + +Use this as a starting map, then validate against the repository's workload: + +| Existing role | Starting target | Reason | +| --- | --- | --- | +| GPT-5.6 Sol or an earlier flagship | `gpt-6-astra` | Astra is the flagship-equivalent tier. | +| Balanced quality, latency, and cost | `gpt-5.6-terra` | Terra is the balanced option. | +| Faster or cheaper work, classification, extraction, routing, high-volume, or strict-latency route | `gpt-5.6-luna` | Luna is the primary speed and cost option. | +| GPT-4.1 or GPT-4o latency-sensitive flow | Start with Luna; evaluate Terra or Astra if quality requires it | A flagship replacement can change latency and cost materially. | +| Reasoning-heavy or hardest quality-first flow | Start with Astra at the old effective effort | Preserve the reasoning contract before tuning. | +| Router, fallback, or model picker | Add the family by role | Do not collapse a multi-model design into Astra. | +| Third-party or provider-specific model | Leave unchanged unless the user explicitly requests provider migration | Model-name similarity is not a safe mapping. | + +Important limits to check in live docs: + +- Each model's context window and maximum output. +- Long-context pricing thresholds for each route. +- Token pricing for GPT-6. + +Do not invent prices, limits, or capability flags. Fetch them from current docs before updating a registry or UI. + +For model pickers and registries, preserve existing model entries by default. Add GPT-6 Astra and retain the existing Terra and Luna options unless the user explicitly asks to replace or remove them. Do not invent pricing, context limits, capabilities, or metadata unless confirmed from canonical docs. + +If using the `gpt-6` alias, record the returned `response.model` during validation. Do not assume an alias and an explicit Astra slug appear identically in dashboards, rate-limit configuration, analytics, or billing metadata. + +## Structured outputs, parsers, and tool contracts + +Keep output contracts explicit: + +- preserve JSON schemas, required fields, enums, refusal handling, and parser expectations; +- preserve tool names, parameter schemas, call IDs, and retry behavior; +- keep citations, evidence fields, or native artifacts when downstream consumers require them; +- validate that the final answer still satisfies the contract, not merely that a tool call succeeded. + +Do not fix a failing migration by weakening a schema, deleting required behavior, removing routes, dropping tools, or changing business logic unless the user explicitly asked for that product change. + +## Prompt migration judgment + +After the model and API baseline is working, run representative traces before editing prompts. Change prompts only for measured failures. Read `references/prompting-guide.md` for the exact canonical prompting section when prompt changes are needed. + +## Upgrade workflow + +1. Fetch current live GPT-6 docs. Fetch the Prompting Best Practices section only when prompt changes are needed. +2. Inventory every usage site and its adjacent prompt, config, registry, parser, and test surfaces. +3. Classify each usage by role and migration class. +4. Choose Astra, Terra, or Luna by the existing workload's role. +5. Preserve the old effective reasoning effort explicitly when supported; follow the canonical migration guidance for unsupported settings. +6. Run the compatibility gates: + - endpoint and SDK support; + - Chat Completions plus function tools; + - cache topology and cache fields; + - context length and long-context cost; + - image, PDF, and file detail; + - structured outputs and parsers; + - Responses state replay and tool continuation; + - mixed-model routing and unsupported new fields. +7. Apply the smallest safe model, config, registry, and prompt changes. +8. Do not add optional Pro, persisted reasoning, PTC, explicit caching, async tools, or multi-agent behavior unless needed and measurable. +9. Run existing tests and representative evals. +10. Report changed, unchanged, blocked, and confirmation-needed sites separately. + +## Validation matrix + +Prefer a controlled comparison: + +1. old model + old prompt + old settings; +2. GPT-6 target + same prompt + preserved effective reasoning; +3. GPT-6 target + same prompt + one lower supported effort; +4. GPT-6 target + the smallest prompt or API fix required by a measured failure; +5. optional feature treatment, isolated from the baseline. + +Measure what matters for the workflow: + +- task success and user-visible quality; +- structured-output validity and parser success; +- tool choice, tool arguments, retries, loop count, and completion rate; +- TTFT, end-to-end latency, timeout rate, and concurrency behavior; +- input, output, reasoning, cached, and cache-write tokens; +- total cost per successful task; +- long-context, compaction, and replay behavior; +- image/PDF token use and visual/OCR accuracy; +- completeness, preserved behavior, citations, and validation evidence. + +For model routers and pickers, test at least one representative workload for each role. Verify that the cheapest or fastest tier is not accidentally used for quality-critical work and that Astra is not accidentally used for every workload. + +## Required final report + +Return: + +- `Current usage inventory`: each model site, endpoint, role, prompt surface, and old effective reasoning. +- `Target mapping`: Astra, Terra, Luna, unchanged, or confirmation-needed, with the reason. +- `Changes made`: model strings, reasoning settings, prompts, registries, metadata, tests, and API-shape changes. +- `Compatibility checks`: Chat Completions/tools, caching, state replay, multimodal detail, context/cost, schemas, and mixed-model routing. +- `Prompt changes`: each surgical edit and the failure mode it addresses. +- `Validation`: commands, evals, traces, before/after measurements, and remaining gaps. +- `Unchanged sites`: historical, pinned, ambiguous, or intentionally role-specific usages. +- `Blockers and open questions`: exact issue, why it is unsafe to guess, and the smallest next step. + +Never say the migration is complete merely because model strings changed. It is complete only when the affected behavior and contracts have been validated or the remaining gaps are stated explicitly. + +## Introduction + +GPT-6 Astra is our most intelligent model yet, with state-of-the-art performance in computer use, browsing, software engineering, science, and professional work. It excels at carrying out multistep workflows across code, browsers, and professional software. In several evaluations, Astra achieves stronger results while using substantially fewer output tokens—delivering a lower estimated API cost per task than earlier models despite its higher per-token pricing. + +GPT-6 Astra is also our most aligned model yet. It excels at exercising care, respecting task boundaries, and communicating transparently. When instructions leave room for interpretation, it uses the context it has to fill in routine gaps and asks focused questions when the answer could change the outcome. It incorporates new requirements, changes course when asked, and answers side questions without losing track of the broader task. + +To build with Astra, set `model` to `gpt-6-astra` in a [Responses API](https://developers.openai.com/api/docs/guides/migrate-to-responses) request. + +## What's new + +- **Async tool calling:** GPT-6 Astra can continue reasoning, call other tools, or answer independent parts of a request while your application runs a tool. Set `async: true` on a function or custom tool and return its result when ready using the original `call_id`. Your application still executes the tool and manages pending work. See [Async tool calling](https://developers.openai.com/api/docs/guides/async-tool-calling) for basic usage and a developer-defined wait-tool pattern. +- **Mid-turn steering:** Send additional user instructions while GPT-6 Astra is working, such as a correction or a change in requirements. Over a WebSocket connection, the Responses API preserves completed work and includes the update in a continuation. See [Mid-turn steering](https://developers.openai.com/api/docs/guides/steering) for the event flow and tool-result handling. +- **Change reasoning mid-conversation while preserving cache:** Add a `configuration_update` input item to increase reasoning effort for difficult work or reduce it for routine follow-ups without rewriting the original prompt prefix. The updated reasoning effort applies until another `configuration_update` input item overrides it. See [Change reasoning mid-conversation](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) for examples and compatibility. +- **Misalignment monitoring:** As part of our strengthened safeguards for GPT-6 Astra, our systems asynchronously monitor for misalignment and trigger alerts when necessary. See [Misalignment monitoring](https://developers.openai.com/api/docs/guides/safety-checks/misalignment-monitoring) for more information. +- **Limitations:** GPT-6 Astra does not support the `none` reasoning effort. [Fast mode](https://developers.openai.com/api/docs/guides/fast-mode) is unavailable for GPT-6 Astra with EU data residency. + +GPT-6 Astra also supports the existing API capabilities available with GPT-5.6, including [computer use](https://developers.openai.com/api/docs/guides/tools-computer-use), [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs), [streaming](https://developers.openai.com/api/docs/guides/streaming-responses), [Programmatic Tool Calling](https://developers.openai.com/api/docs/guides/tools-programmatic-tool-calling), [multi-agent orchestration](https://developers.openai.com/api/docs/guides/responses-multi-agent), [prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching), [persisted reasoning](https://developers.openai.com/api/docs/guides/reasoning#preserve-reasoning-across-calls), [compaction](https://developers.openai.com/api/docs/guides/compaction), and [pro mode](https://developers.openai.com/api/docs/guides/reasoning#reasoning-mode). + +## Migration quickstart + +### Migrate with Codex + +Codex can apply the recommended changes in this guide with the OpenAI Docs skill. + +```text +$openai-docs migrate this project to GPT-6 Astra +``` + +To use this skill in other coding agents, download it from the OpenAI skills repository. + +### Update API and model parameters + +Set `model` to `gpt-6-astra`, then check the following: + +- **Reasoning effort:** If you currently use `none` or `minimal`, start with `low` and compare results. Otherwise, preserve your current effective [reasoning effort](https://developers.openai.com/api/docs/guides/reasoning#reasoning-effort). Use `reasoning.effort` in Responses or `reasoning_effort` in Chat Completions. +- **Tool calling:** Use the [Responses API](https://developers.openai.com/api/docs/guides/migrate-to-responses#migrating-from-chat-completions). GPT-6 Astra supports Chat Completions, but tool calling requires Responses. +- **Unsupported parameters:** Remove `temperature`, `top_p`, and `top_logprobs`. For Chat Completions, also remove `logprobs`. For Responses, remove `message.output_text.logprobs` from `include`. +- **Fast mode:** For EU data residency, use Standard processing. GPT-6 Astra does not support `service_tier: "fast"` or `service_tier: "priority"` with EU data residency. Fast mode for GPT-6 Astra does not include a latency SLA. See [Fast mode compatibility](https://developers.openai.com/api/docs/guides/fast-mode#is-fast-mode-compatible-with-data-residency-zero-data-retention-and-a-baa). +- **Changing reasoning effort:** If your application changes effort between responses, use `configuration_update` items in standard, single-agent requests. Keep request-level `reasoning.effort` unchanged to preserve the prompt prefix for caching. Check the [compatibility limits](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) before adopting this feature. +- **Prompt caching:** When migrating from GPT-5.5 or earlier, replace `prompt_cache_retention` with `prompt_cache_options.ttl` set to `"30m"`. Review the [prompt caching changes](https://developers.openai.com/api/docs/guides/prompt-caching#summary-of-model-differences), including cache boundaries and cache-write billing. +- **Unnecessary approval pauses:** If you run into issues where the model keeps asking for approval before proceeding, use the [initiative and follow-through guidance](https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#initiative-and-follow-through) to prompt for more autonomous execution. See the rest of [Prompting best practices](https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices) for guidance on instruction following, writing style, subagent delegation, and testing. diff --git a/skills/.system/openai-docs/references/latest-model.md b/skills/.system/openai-docs/references/latest-model.md index 04aa84b..d4fca8c 100644 --- a/skills/.system/openai-docs/references/latest-model.md +++ b/skills/.system/openai-docs/references/latest-model.md @@ -1,36 +1,25 @@ -# Latest model guide +# Latest model fallback -This file is a curated helper. Every recommendation here must be verified against current OpenAI docs before it is repeated to a user. +This is a compact, non-authoritative fallback, not a source for current availability, prices, aliases, or defaults. First search for and fetch current official model guidance at `https://developers.openai.com/api/docs/guides/latest-model` and the relevant official model page. The fetched official documentation wins if this snapshot has drifted. Disclose any use of this fallback. -## Current model map +## Model roles -| Model ID | Use for | +| Model ID | Documented workload to verify against the current model page | | --- | --- | -| `gpt-5.5` | Latest/default text and reasoning model for most new apps, including coding and tool-heavy workflows | -| `gpt-5.5-pro` | Maximum reasoning or quality when latency and cost matter less | -| `gpt-5.4` | Previous default text and reasoning model; use for existing GPT-5.4 integrations | -| `gpt-5.4-mini` | Lower-cost testing and lighter production workflows | -| `gpt-5.4-nano` | High-throughput simple tasks and classification | -| `gpt-5.5` | Explicit no-reasoning text path via `reasoning.effort: none` | -| `gpt-4.1-mini` | Cheaper no-reasoning text | -| `gpt-4.1-nano` | Fastest and cheapest no-reasoning text | -| `gpt-5.3-codex` | Agentic coding, code editing, and tool-heavy coding workflows | -| `gpt-5.1-codex-mini` | Cheaper coding workflows | -| `gpt-image-1.5` | Best image generation and edit quality | -| `gpt-image-1-mini` | Cost-optimized image generation | -| `gpt-4o-mini-tts` | Text-to-speech | -| `gpt-4o-mini-transcribe` | Speech-to-text, fast and cost-efficient | -| `gpt-realtime-1.5` | Realtime voice and multimodal sessions | -| `gpt-realtime-mini` | Cheaper realtime sessions | -| `gpt-audio` | Chat Completions audio input and output | -| `gpt-audio-mini` | Cheaper Chat Completions audio workflows | -| `sora-2` | Faster iteration and draft video generation | -| `sora-2-pro` | Higher-quality production video | -| `omni-moderation-latest` | Text and image moderation | -| `text-embedding-3-large` | Higher-quality retrieval embeddings; default in this skill because no best-specific row exists | -| `text-embedding-3-small` | Lower-cost embeddings | +| `gpt-6` | GPT-6 family alias; verify its currently documented routing and availability. | +| `gpt-6-astra` | Quality-first flagship, reasoning, and difficult coding work. | +| `gpt-5.6-terra` | Balanced quality, latency, and cost. | +| `gpt-5.6-luna` | Primary choice for faster or cheaper workloads. | -## Maintenance notes +Use `https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#migration-quickstart` for an actual GPT-6 migration and `https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices` for requested GPT-6 prompting. Open and read the relevant page before recommending a request shape, reasoning setting, endpoint, tool behavior, or migration. -- This file will drift unless it is periodically re-verified against current OpenAI docs. -- If this file conflicts with current docs, the docs win. +## Explicitly requested existing models + +| Model ID | Boundary | +| --- | --- | +| `gpt-4.1` | Preserve only when the user explicitly requests this model or existing migration target; search and fetch its own current official guide. | +| `gpt-5.4` | Preserve only when the user explicitly requests this model or existing migration target; search and fetch its own current official guide. | + +Do not promote a legacy model as the current default, substitute it into an unrelated task, or replace an explicitly requested legacy target with GPT-6 Astra. Recommend a specialized image, audio, realtime, coding, moderation, or embedding model only after verifying the requested modality against current official documentation. + +Verify GPT-6 Pro against current official Responses and model documentation before describing model IDs, reasoning modes, request parameters, or account availability; do not invent a separate `gpt-6-pro` model slug. diff --git a/skills/.system/openai-docs/references/prompting-guide.md b/skills/.system/openai-docs/references/prompting-guide.md index 0d9273c..2370a8a 100644 --- a/skills/.system/openai-docs/references/prompting-guide.md +++ b/skills/.system/openai-docs/references/prompting-guide.md @@ -1,244 +1,115 @@ -GPT-5.5 works best when prompts define the outcome and leave room for the model to choose an efficient solution path. Compared with earlier models, you can often use shorter, more outcome-oriented prompts: describe what good looks like, what constraints matter, what evidence is available, and what the final answer should contain. +## Retrieve the live GPT-6 prompting guidance -Avoid carrying over every instruction from an older prompt stack. Legacy prompts often over-specify the process because earlier models needed more help staying on track. With GPT-5.5, that can add noise, narrow the model's search space, or lead to overly mechanical answers. +Use already-callable official documentation search and fetch, or immediately use official-domain web search and fetch, to retrieve the live GPT-6 prompting guidance from: -For more detail on GPT-5.5 behavior changes, start with the [Using GPT-5.5 guide](/api/docs/guides/latest-model). This guide focuses on prompt changes that follow from those behavior changes. +https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices -The patterns here are starting points. Adapt them to your product surface, tools, evals, and user experience goals. +Read only the `## Prompting best practices` section, stopping at the next H2 heading. The URL anchor points to the section visually, but a documentation fetch may return the full page, so explicitly extract only that section. -## Personality and behavior +Treat the live section as the canonical model-specific prompting guidance. Use the local copy below only when live guidance is unavailable. Keep it identical to the page's `## Prompting best practices` section when refreshing this reference. -GPT-5.5's default style is efficient, direct, and task-oriented. This is useful for production systems: responses stay focused, behavior is easier to steer, and the model avoids unnecessary conversational padding. +## Prompting best practices -For customer-facing assistants, support workflows, coaching experiences, and other conversational products, define both personality and collaboration style. +GPT-6 Astra is more intelligent and capable than prior models like GPT-5.6 Sol, and also exhibits behavior patterns that can be optimized through prompting the model for your use case. -- **Personality** controls how the assistant sounds: tone, warmth, directness, formality, humor, empathy, and level of polish. -- **Collaboration style** controls how the assistant works: when it asks questions, when it makes assumptions, how proactive it should be, how much context it gives, when it checks work, and how it handles uncertainty or risk. +### GPT-6 Astra behavior -Keep both short. Personality instructions should shape the user experience. Collaboration instructions should shape task behavior. Neither should replace clear goals, success criteria, tool rules, or stopping conditions. +- [Initiative and follow-through](#initiative-and-follow-through) – The model is designed to be a more effective collaborator and is thus more likely to ask the user a question when additional input could materially change the result. This can cause it to stop when the user may expect it to make reasonable assumptions and persist. +- [Instruction following](#instruction-following) – GPT-6 Astra is stronger at general instruction following than our previous models, giving you greater control over its behavior. It can be more sensitive to instructions contained in skills and other files, such as `AGENTS.md`. We **strongly recommend** auditing skills and other files accessible to your model for instructions that could influence its behavior. +- [Personality and writing style](#personality-and-writing-style) – The model tends toward detailed, formatted responses and may use recurring phrases across sessions. Specify the writing style and structure your application needs. +- [Subagent delegation](#subagent-delegation) – The model may delegate less often than desired for your workflow. Specify when and how much it should use subagents for parallel work. +- [Testing and verification](#testing-and-verification) – For coding tasks, the model tends to be thorough in testing before considering a task complete. For smaller tasks, this can result in broader tests than the task requires. -Example personality block for a steady task-focused assistant: +### Initiative and follow-through + +GPT-6 Astra is generally better than GPT-5.6 Sol and earlier models at staying coherent during long tasks. It is also more likely to ask for clarification where earlier models would make assumptions. + +To encourage more autonomous work, start with this prompt: ```text -# Personality -You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness. +You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion. -Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow. - -Stay concise without becoming curt. Give enough context for the user to understand and trust the answer, then stop. Use examples, comparisons, or simple analogies when they make the point easier to grasp. When correcting the user or disagreeing, be candid but constructive. When an error is pointed out, acknowledge it plainly and focus on fixing it. - -Match the user's tone within professional bounds. Avoid emojis and profanity by default, unless the user explicitly asks for that style or has clearly established it as appropriate for the conversation. +When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible. ``` -Example personality block for an expressive collaborative assistant: +When the user’s intent is unclear, the model is more likely to ask the user for clarification to proceed. Prompt the model to follow through if the user’s prompt implies authorization: ```text -# Personality -Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context. - -Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints. - -Be thoughtful and grounded when the task calls for synthesis or advice. State a clear recommendation when you have enough context, explain important tradeoffs, and name uncertainty without becoming evasive. +When the user's prompt indicates a request for action, such as "can you...", "I want to...", "help me..." and similar expressions, treat these as instructions to do the work and take action. Do not stop at acknowledging capability (e.g. "Yes…"), proposing a plan, or offering to continue. Do not settle for a partial or "helpful enough" solution that does not fully satisfy the user's task to save time, effort or tokens. If a task requires sustained work, complete all the necessary work until the intended outcome is fulfilled. ``` -For more expressive products, add warmth, curiosity, humor, or point of view explicitly, but keep the block short. Use personality to shape the experience, not to compensate for unclear goals or missing task instructions. - -## Improve time to first visible token with a preamble - -In streaming applications, users notice how long it takes before the first visible response appears. GPT-5.5 may spend time reasoning, planning, or preparing tool calls before emitting visible text. - -For longer or tool-heavy tasks, prompt the model to start with a short preamble: a brief visible update that acknowledges the request and states the first step. This can improve perceived responsiveness without changing the underlying task. - -Use this pattern when the task may take more than one step, require tool calls, or involve a long-running agent workflow. +Prompt the model to ask for approval only after preparing a concrete, reviewable result. This avoids blocking the task before the model has done the work it can, and often leads to quicker task completion. ```text -Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences. +Before asking the user clarifying questions, you should complete the work that is already authorized from context and necessary to make the proposed action concrete and reviewable. The user should be approving a concrete, reviewable result. For example, before deploying a change, writing to an external application, merging a PR or publishing a site, do all the required work first so that user approval is the final step. You don't need user permission for reversible tasks, read-only actions, reviews or fixes, or anything for which authorization is provided earlier in the session or strongly implied from the task instruction. + +Do not introduce unsolicited warnings, disclaimers, approval flows, or safety/compliance checklists due to hypothetical risk. ``` -For coding agents that expose separate message phases, you can be more explicit: +The model also likes to ask non-blocking questions as it’s working by default, so adjust these prompts to match the level of autonomy your application needs. + +### Instruction following + +GPT-6 Astra is better able to follow longer instructions, but can also be more sensitive to information in context. For example, unclear or conflicting guidance in a skill file may cause the model to pause and block work early. Make the priority of user instructions and skills explicit. ```text -You must always start with an intermediary update before any content in the analysis channel if the task will require calling tools. The user update should acknowledge the request and explain your first step. +The user's instructions take precedence over guidelines provided in a skill. If explicit user instructions conflict with a skill's instructions, prioritize the user's instructions. ``` -## Outcome-first prompts and stopping conditions - -GPT-5.5 is strongest when the prompt defines the target outcome, success criteria, constraints, and available context, then lets the model choose the path. - -For many tasks, describe the destination rather than every step. This gives the model room to choose the right search, tool, or reasoning strategy for the task. - -Prefer this: +Asking the model to identify the skill and instruction that caused it to pause or change direction can also be effective in providing transparency into model behavior. ```text -Resolve the customer's issue end to end. - -Success means: -- the eligibility decision is made from the available policy and account data -- any allowed action is completed before responding -- the final answer includes completed_actions, customer_message, and blockers -- if evidence is missing, ask for the smallest missing field +If a skill causes you to ask for permission or confirmation, pause, leave requested work unfinished, or diverge from the user's intent, name and link to the exact SKILL.md file you read, quote the relevant instruction, and briefly explain how it applies. Distinguish explicit skill requirements from your interpretation of guidelines. ``` -**Avoid unnecessary absolute rules.** Older prompts often use strict instructions like `ALWAYS`, `NEVER`, `must`, and `only` to control model behavior. Use those words for true invariants, such as safety rules, required output fields, or actions that should never happen. For judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead. +Use this prompt to find silent and conflicting guidance when your application loads many skills and instruction files such as `AGENTS.md`. -Avoid this style of instruction unless every step is truly required: +### Personality and writing style + +GPT-6 Astra tends to use lists, tables and Markdown to make responses scannable. If your application needs prose with less formatting, specify that preference. ```text -First inspect A, then inspect B, then compare every field, then think through -all possible exceptions, then decide which tool to call, then call the tool, -then explain the entire process to the user. +Default to using clear, concise paragraphs, each developing one main idea. Use lists only when the information is genuinely parallel, sequential, or easier to compare, and avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use plain, simple language: familiar words, concrete examples, and precise verbs. Prefer active voice and direct statements. + +Make sure to state the main point clearly and early, then develop it with the explanation and detail the reader needs. Let each sentence build on what came before. Develop the points that matter and provide enough support to be useful. ``` -Add explicit stopping conditions: +For technical communication, the following prompt helps strike a balance between using clear, coherent language while remaining domain appropriate: ```text -Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims. - -After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer. +Use plain language over jargon, and reference technical details only to the degree that it helps illustrate an idea or your work to the user. Communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the level of background knowledge assumed from the user's prompt and context. ``` -Define missing-evidence behavior: +To reduce jargon and stock phrases in writing, start with this prompt: ```text -Use the minimum evidence sufficient to answer correctly, cite it precisely, then stop. +Avoid using slop words or phrases like "Bottom Line:" in conclusions, "delve," "foster," "leverage," "it's worth noting," "importantly," "Question? Answer." or "This isn't about X. It's about Y.", "genuinely" or hyphenated compound descriptions and adjectives. Do not use concluding summary statements such as "In short:..", "The simplest mental model is:...". + +State the intended action directly. Avoid adding what you won't do, what will remain unchanged, or how you'll separate or categorize results. Do not use contrastive framing such as "X, not Y" or "X—not Y" that introduces an unprompted alternative that the user didn't ask about. Avoid invented compound labels like "exact-head checks" and "editorial-row layouts", vague qualifiers, and canned transitions; use plain verbs and prepositions to state the actual relationship directly. ``` -## Formatting +### Subagent delegation -GPT-5.5 is highly steerable on output format and structure. Use that control when it improves comprehension or product fit. - -Set `text.verbosity`, describe the expected output shape, and reserve heavier structure for cases where it improves comprehension or your product UI needs a stable artifact. The API default for `text.verbosity` is `medium`; use `low` when you prefer shorter, more concise responses. - -Plain conversational formatting: +GPT-6 Astra is trained to be able to divide and delegate work to subagents that work in parallel. If you are implementing a multi-agent system in your harness, use the following prompt to tune how much GPT-6 Astra should delegate work: ```text -Let formatting serve comprehension. Use plain paragraphs as the default format for normal conversation, explanations, reports, documentation, and technical writeups. Keep the presentation clean and readable without making the structure feel heavier than the content. - -Use headers, bold text, bullets, and numbered lists sparingly. Reach for them when the user requests them, when the answer needs clear comparison or ranking, or when the information would be harder to scan as prose. Otherwise, favor short paragraphs and natural transitions. - -Respect formatting preferences from the user. If they ask for a terse answer, minimal formatting, no bullets, no headers, or a specific structure, follow that preference unless there is a strong reason not to. +If at any point you can parallelize work by delegating tasks to another agent (no matter if you are the root or subagent), you should do so using collaboration tools if it could save time or improve quality. ``` -Add explicit audience and length guidance: +Messages between agents may contain grammar or spacing errors. Use this prompt to make inter-agent messages easier to read: ```text -Write for a senior business audience. Keep the answer under 400 words. Use short paragraphs and only include bullets when they improve scannability. Prioritize the conclusion first, then the reasoning, then caveats. +Messages that you send to other agents and your final answer may be read by a human, so ensure they are legible. Always put proper spaces between words and/or numbers. ``` -For editing, rewriting, summaries, or customer-facing messages, tell the model what to preserve before asking it to improve style. This pattern is useful when you want polish without expansion. +The model tends to respond well to prompting for how and when it should delegate work to subagents, so tune this behavior to fit with your harness and multi-agent implementation. + +### Testing and verification + +For coding tasks, calibrate how much testing and verification a change requires. This can help avoid unnecessary tests or repeated checks for small changes. ```text -Preserve the requested artifact, length, structure, and genre first. Quietly improve clarity, flow, and correctness. Do not add new claims, extra sections, or a more promotional tone unless explicitly requested. -``` +Do not write tests for reversible, low-impact changes that mirror the implementation. If you do choose to verify your work with tests, make sure that the tests are meaningful and necessary to verify implementation. -## Grounding, citations, and retrieval budgets - -For grounded answers, citation behavior should be part of the prompt. Define what needs support, what counts as enough evidence, and how the model should behave when evidence is missing. Absence of evidence shouldn't automatically become a factual "no." For more details and examples, see the [citation formatting guide](/api/docs/guides/citation-formatting). - -### Add an explicit retrieval budget - -Retrieval budgets are stopping rules for search. They tell the model when enough evidence is enough. - -```text -For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again. - -Make another retrieval call only when: -- The top results do not answer the core question. -- A required fact, parameter, owner, date, ID, or source is missing. -- The user asked for exhaustive coverage, a comparison, or a comprehensive list. -- A specific document, URL, email, meeting, record, or code artifact must be read. -- The answer would otherwise contain an important unsupported factual claim. - -Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic. -``` - -## Creative drafting guardrails - -For drafting tasks, tell the model which claims must come from sources and which parts may be creatively written. This is especially important for slides, launch copy, customer summaries, talk tracks, leadership blurbs, and narrative framing. - -```text -For creative or generative requests such as slides, leadership blurbs, outbound copy, summaries for sharing, talk tracks, or narrative framing, distinguish source-backed facts from creative wording. - -- Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims. -- Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger. -- If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics. -``` - -## Frontend engineering and visual taste - -For frontend work, refer to the [example instructions](/api/docs/guides/frontend-prompt) for practical ways to steer UI quality. They cover product and user context, design-system alignment, first-screen usability, familiar controls, expected states, responsive behavior, and common generated-UI defaults to avoid, such as generic heroes, nested cards, decorative gradients, visible instructional text, and broken layouts. - -## Prompt the model to check its work - -Give GPT-5.5 access to tools that let it check outputs when validation is possible. - -For coding agents, ask for concrete validation commands: - -```text -After making changes, run the most relevant validation available: -- targeted unit tests for changed behavior -- type checks or lint checks when applicable -- build checks for affected packages -- a minimal smoke test when full validation is too expensive - -If validation cannot be run, explain why and describe the next best check. -``` - -For visual artifacts, ask for inspection after rendering: - -```text -Render the artifact before finalizing. Inspect the rendered output for layout, clipping, spacing, missing content, and visual consistency. Revise until the rendered output matches the requirements. -``` - -For engineering and planning tasks, make implementation plans traceable: - -```text -For implementation plans, include: -- requirements and where each is addressed -- named resources, files, APIs, or systems involved -- state transitions or data flow where relevant -- validation commands or checks -- failure behavior -- privacy and security considerations -- open questions that materially affect implementation -``` - -## Phase parameter - -Starting with GPT-5.4, long-running or tool-heavy Responses workflows can use assistant-item `phase` values to distinguish intermediate updates from final answers. GPT-5.5 uses the same pattern. - -If you use `previous_response_id`, the API preserves prior assistant state automatically. If your application manually replays assistant output items into the next request, preserve each original `phase` value and pass it back unchanged. This matters most when a response includes preambles, repeated tool calls, or a final answer after intermediate assistant updates. - -```text -If manually replaying assistant items: -- Preserve assistant `phase` values exactly. -- Use `phase: "commentary"` for intermediate user-visible updates. -- Use `phase: "final_answer"` for the completed answer. -- Do not add `phase` to user messages. -``` - -## Suggested prompt structure - -Use this structure as a starting point for complex prompts. Keep each section short. Add detail only where it changes behavior. - -```text -Role: [1-2 sentences defining the model's function, context, and job] - -# Personality -[tone, demeanor, and collaboration style] - -# Goal -[user-visible outcome] - -# Success criteria -[what must be true before the final answer] - -# Constraints -[policy, safety, business, evidence, and side-effect limits] - -# Output -[sections, length, and tone] - -# Stop rules -[when to retry, fallback, abstain, ask, or stop] +Run tests appropriate to the change and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it; otherwise, continue toward completing the task. ``` diff --git a/skills/.system/openai-docs/references/upgrade-guide.md b/skills/.system/openai-docs/references/upgrade-guide.md index b29f137..af059c1 100644 --- a/skills/.system/openai-docs/references/upgrade-guide.md +++ b/skills/.system/openai-docs/references/upgrade-guide.md @@ -1,181 +1,22 @@ -# Upgrading to GPT-5.5 +# Model upgrade guidance -Use this guide when the user explicitly asks to upgrade an existing integration to GPT-5.5. Pair it with current OpenAI docs lookups. The default target string is `gpt-5.5`. +Use this file only as a bundled routing fallback when the live migration guide cannot be fetched. -## Freshness check +For latest, current, default, or unspecified-model upgrades: -Before applying this bundled guide for a latest/current/default model upgrade, run `node scripts/resolve-latest-model-info.js` from the OpenAI Docs skill directory. +1. Run `node scripts/resolve-latest-model-info.js`. +2. Fetch the returned `migrationGuideUrl` and `promptingGuideUrl` exactly. +3. Treat the live guides as canonical. +4. If remote retrieval fails, disclose that bundled fallback guidance is being used. -- If the command returns `modelSlug: "gpt-5p5"`, continue with this bundled guide and use `references/prompting-guide.md` when prompt updates are needed. -- If the command returns a different `modelSlug`, fetch both the returned `migrationGuideUrl` and `promptingGuideUrl` and use them as the current source of truth instead of the bundled references. -- If the command fails, metadata is missing, or either remote guide cannot be fetched, continue with bundled fallback references and say the remote freshness check was unavailable. -- If the user explicitly named a target model, preserve that target and use current docs only to check compatibility or caveats. +For an explicit GPT-6 Astra migration: -## Upgrade posture +1. Preserve the user's explicit target; do not run the latest-model resolver. +2. Fetch the live GPT-6 model guidance: -Upgrade with the narrowest safe change set: + https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md -- replace the model string first -- update only the prompts that are directly tied to that model usage -- do not automatically upgrade older or ambiguous model usages that may be intentionally pinned, such as historical docs, examples, tests, eval baselines, comparison code, or low-cost fallback/routing paths. Unless the user explicitly asks to upgrade all model usage, leave those sites unchanged and list them as confirmation-needed -- prefer prompt-only upgrades when possible -- if the upgrade would require API-surface changes, parameter rewrites, tool rewiring, provider migration, or broader code edits, mark it as blocked instead of stretching the scope +3. Read `references/upgrading-to-gpt-6-astra.md` for skill-specific migration judgment. +4. Read `references/prompting-guide.md` only when prompt changes are needed. -## Upgrade workflow - -1. Inventory current model usage. - - Search for model strings, client calls, and prompt-bearing files. - - Include inline prompts, prompt templates, YAML or JSON configs, Markdown docs, and saved prompts when they are clearly tied to a model usage site. -2. Pair each model usage with its prompt surface. - - Prefer the closest prompt surface first: inline system or developer text, then adjacent prompt files, then shared templates. - - If you cannot confidently tie a prompt to the model usage, say so instead of guessing. -3. Classify the source model family. - - Common buckets: GPT-5.4, GPT-5.3-Codex or GPT-5.2-Codex, earlier GPT-5.x, GPT-4o or GPT-4.1, reasoning models such as o1 or o3 or o4-mini, third-party model, or mixed and unclear. -4. Decide the upgrade class. - - `model string only` - - `model string + light prompt rewrite` - - `blocked without code changes` -5. Run the compatibility gate. - - Check whether the current integration can accept `gpt-5.5` without API-surface changes or implementation changes. - - Check whether structured outputs, tool schemas, function names, and downstream parsers can remain unchanged. - - For long-running Responses or tool-heavy agents, check whether `phase` is already preserved or round-tripped when the host replays assistant items or uses preambles. - - If compatibility depends on code changes, return `blocked`. - - If compatibility is unclear, return `unknown` rather than improvising. -6. Apply the upgrade when it is in scope. - - Default replacement string: `gpt-5.5`. - - Keep the intervention small and behavior-preserving. - - Start from the current reasoning effort when it is visible unless there is a measured reason to change it. - - For in-scope changes, update the model string and directly related prompts. - - For blocked or unknown changes, do not edit; report the blocker or uncertainty. -7. Summarize the result. - - `Current model usage` - - `Model-string updates` - - `Reasoning-effort handling` - - `Prompt updates` - - `Structured output and formatting assessment` - - `Tool-use assessment` when the flow uses tools, retrieval, or terminal actions - - `Phase assessment` when the flow is long-running, replayed, or tool-heavy - - `Compatibility check` - - `Validation performed` - -Output rule: - -- For each usage site, state the starting reasoning-effort recommendation. -- If the repo exposes the current reasoning setting, recommend preserving it first unless current OpenAI docs say otherwise. -- If the repo does not expose the current setting, recommend not adding one unless current OpenAI docs require it. - -## Upgrade outcomes - -### `model string only` - -Choose this when: - -- the source model is GPT-5.4 -- the existing prompts are already short, explicit, and task-bounded -- the workflow does not rely on strict output formats, tool-call behavior, batch completeness, or long-horizon execution that should be validated after the upgrade -- there are no obvious compatibility blockers - -Default action: - -- replace the model string with `gpt-5.5` -- preserve the current reasoning effort -- keep prompts unchanged -- validate behavior with existing tests, realistic spot checks, or an existing eval suite when one is already available - -### `model string + light prompt rewrite` - -Choose this when: - -- the task needs stronger completeness, citation discipline, verification, or dependency handling -- the upgraded model becomes too verbose, too dense, or hard to scan unless formatting is constrained -- the workflow has strict output shape requirements and lacks an explicit format contract, schema, or parser validation -- the workflow is research-heavy and needs stronger handling of sparse or empty retrieval results -- the workflow is coding-oriented, terminal-based, tool-heavy, or multi-agent, but the existing API surface and tool definitions can remain unchanged - -Default action: - -- replace the model string with `gpt-5.5` -- preserve the current reasoning effort for the first pass -- make only the smallest prompt edits needed for the observed workflow risk -- read the [GPT-5.5 prompting guide](/api/docs/guides/prompt-guidance?model=gpt-5.5) to choose the smallest prompt changes that recover or improve behavior -- avoid broad prompt cleanup unrelated to the upgrade -- for research workflows, add citation rules, retrieval budgets, missing-evidence behavior, and validation guidance from the prompting guide -- for dependency-aware or tool-heavy workflows, add prerequisite checks, missing-context handling, explicit tool budgets, stop conditions, and validation guidance -- for coding or terminal workflows, add repo-specific constraints, acceptance criteria, and concrete validation commands -- for multi-agent support or triage workflows, add task ownership, handoff, completeness, and stopping criteria -- for long-running Responses agents with preambles or multiple assistant messages, explicitly review whether `phase` is already handled; if adding or preserving `phase` would require code edits, mark the path as `blocked` -- do not classify a coding or tool-using Responses workflow as `blocked` just because the visible snippet is minimal; prefer `model string + light prompt rewrite` unless the repo clearly shows that a safe GPT-5.5 path would require host-side code changes - -### `blocked` - -Choose this when: - -- the upgrade appears to require API-surface changes -- the upgrade appears to require parameter rewrites or reasoning-setting changes that are not exposed outside implementation code -- the upgrade would require changing tool definitions, tool handler wiring, or schema contracts -- the user is asking for a tooling, IDE, plugin, shell, or environment migration rather than a model and prompt migration -- the integration depends on provider-specific APIs that do not map to the current OpenAI API surface without implementation work -- you cannot confidently identify the prompt surface tied to the model usage - -Default action: - -- do not improvise a broader upgrade -- report the blocker and explain that the fix is out of scope for this guide -- if useful, describe the smallest follow-up implementation task that would unblock the migration - -## Compatibility checklist - -Before applying or recommending a model-and-prompt-only upgrade, check: - -1. Can the current host accept the `gpt-5.5` model string without changing client code or API surface? -2. Are the related prompts identifiable and editable? -3. Does the host depend on behavior that likely needs API-surface changes, parameter rewrites, provider migration, or tool rewiring? -4. Would the likely fix be prompt-only, or would it need implementation changes? -5. Is the prompt surface close enough to the model usage that you can make a targeted change instead of a broad cleanup? -6. Do strict structured outputs, schemas, or downstream parsers still have an explicit contract? -7. For long-running Responses or tool-heavy agents, is `phase` already preserved if the host relies on preambles, replayed assistant items, or multiple assistant messages? -8. Are latency, token, or price assumptions validated by tests, realistic spot checks, or an existing eval suite rather than inferred from general model positioning? - -If item 1 is no, items 3 through 4 point to implementation work, or item 7 is no and the fix needs code changes, return `blocked`. - -If item 2 is no, return `unknown` unless the user can point to the prompt location. - -Important: - -- Existing use of tools, agents, or multiple usage sites is not by itself a blocker. -- If the current host can keep the same API surface and the same tool definitions, prefer `model string + light prompt rewrite` over `blocked`. -- Reserve `blocked` for cases that truly require implementation changes, not cases that only need stronger prompt steering. -- Do not claim token savings without task-level validation. - -## Scope boundaries - -This guide may: - -- update or recommend updated model strings -- update or recommend updated prompts -- inspect code and prompt files to understand where those changes belong -- inspect whether existing Responses flows already preserve `phase` -- flag compatibility blockers -- propose validation with existing tests, realistic spot checks, or existing eval suites - -This guide may not: - -- move Chat Completions code to Responses -- move Responses code to another API surface -- migrate SDKs, APIs, IDE configuration, shell hooks, plugins, or provider-specific tooling -- rewrite parameter shapes -- change tool definitions or tool-call handling -- change structured-output wiring -- add or retrofit `phase` handling in implementation code -- edit business logic, orchestration logic, SDK usage, IDE configuration, shell hooks, or plugin integration behavior except for model-string replacements and directly related prompt edits - -If a safe GPT-5.5 upgrade requires any of those changes, mark the path as blocked and out of scope. - -## Validation plan - -- Validate each upgraded usage site with existing tests, realistic spot checks, or an existing eval suite when one is already available. -- Compare against the current GPT-5.4 baseline when available. -- Check task success, retry count, tool-call count, total tokens, latency, output shape, and user-visible quality. -- For specialized workflows, validate the contract that matters most instead of judging only general output quality. -- If prompt edits were added, confirm each block is doing real work instead of adding noise. -- If the workflow has downstream impact, add a lightweight verification pass before finalization. +For another explicit model target, preserve that target and fetch its current official guidance. Do not reuse GPT-6-specific defaults, API shapes, or compatibility rules for a different model. diff --git a/skills/.system/openai-docs/references/upgrading-to-gpt-6-astra.md b/skills/.system/openai-docs/references/upgrading-to-gpt-6-astra.md new file mode 100644 index 0000000..49d138e --- /dev/null +++ b/skills/.system/openai-docs/references/upgrading-to-gpt-6-astra.md @@ -0,0 +1,221 @@ +# Upgrading to GPT-6 Astra + +Use this guide when the user asks to migrate an existing OpenAI API integration, repository, prompt stack, agent, model router, or model picker to GPT-6 Astra. + +The default explicit target is `gpt-6-astra`. Verify the `gpt-6` family alias's currently documented routing and availability before using it. Do not treat every old model usage as an Astra candidate: retain Terra for balanced work and Luna as the primary faster or cheaper model. + +Before changing code, retrieve the current live GPT-6 model guidance using already-callable official documentation search and fetch, or immediately use official-domain web search and fetch: + +https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md + +For prompt changes, also read only the `## Prompting best practices` section from: + +https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices + +Treat live docs as canonical for current model IDs, parameters, limits, pricing, and feature availability. The skill-specific workflow below covers repository inspection, scope preservation, and validation. The fallback after it includes all non-prompting guidance, including access notices, examples, caveats, and `## Migration quickstart`; the full prompting section is in `references/prompting-guide.md`. When refreshing, preserve all guide content unless it is specific to the website rather than useful to the skill, and record any omission. Remove website metadata and component markup while retaining their readable content. Resolve site-relative links against `https://developers.openai.com` and section-only links against the canonical model-guide URL above. + +## Core principle + +Do not perform a blind model-string replacement. + +First preserve the behavior, latency class, cost class, reasoning level, endpoint contract, tool semantics, cache behavior, and output contract of each usage site. Then make the smallest safe migration. Adopt new GPT-6 capabilities only when they solve a measured problem or the user explicitly asks for them. + +A model upgrade alone does not authorize adding reasoning fields, changing request schemas, or rewriting tests. Set a supported reasoning effort explicitly to preserve the source model's effective behavior; verify omitted defaults rather than guessing. + +## Migration posture + +Classify every usage site before editing: + +1. `simple Astra migration` + - One flagship model usage. + - Same endpoint and request shape can remain. + - Reasoning effort is explicit or its old effective value is known. + - No cache, vision, file, tool, or parser behavior needs implementation changes. +2. `tier-aware family migration` + - The repository exposes multiple model roles, model choices, fallbacks, routers, pricing data, or capability metadata. + - Map each role to Astra, Terra, or Luna instead of replacing everything with Astra. +3. `compatibility migration` + - The safe move requires parameter, endpoint, cache, state, tool-loop, or multimodal-detail changes. + - Make these changes only when implementation work is inside the user's requested scope. Otherwise report the exact blocker and smallest follow-up. +4. `prompt migration` + - The API shape can remain, but representative traces show a prompt-specific regression. + - Make a surgical prompt edit tied to that failure; do not rewrite a working prompt stack wholesale. + - When the task is to update prompting guidance, edit the directly tied prompt surface only. Do not modify runtime request code, model schemas, or tests unless the prompt change requires it. +5. `optional feature adoption` + - Pro mode, persisted reasoning, explicit caching, Programmatic Tool Calling, or multi-agent behavior is being added deliberately. + - Keep this separate from the baseline migration so its effect can be measured. +6. `leave unchanged` + - Historical examples, documentation about old models, snapshots, fixtures, eval baselines, comparison code, intentionally pinned fallbacks, unsupported providers, or ambiguous usages. + +When intent is unclear, prefer leaving a usage unchanged and list it for confirmation over silently changing its role. + +## Inventory before editing + +Search for more than literal model IDs. Inventory: + +- model strings, aliases, environment variables, CLI flags, config defaults, and deployment settings; +- SDK calls to Responses, Chat Completions, Batch, or provider adapters; +- reasoning settings, token budgets, sampling settings, and latency timeouts; +- function tools, hosted tools, structured outputs, response parsers, and replay logic; +- system, developer, user, and tool-description prompts tied to each usage; +- routers, fallbacks, model allowlists, enums, regexes, validation schemas, and capability maps; +- model picker UI, display labels, descriptions, context limits, pricing metadata, and provider catalogs; +- prompt-cache keys, retention options, stable-prefix construction, and cache metrics; +- image, PDF, file, OCR, and computer-use inputs; +- tests, fixtures, snapshots, evals, analytics labels, billing tables, and docs. + +When changing a default model, search every active default surface: runtime config, environment/config files, setup docs, tests, CLI defaults, and deployment examples. Update them together. + +For each usage site, record: + +- source model and why it appears to be used; +- endpoint and SDK/client surface; +- prompt surface; +- effective reasoning effort, including defaults; +- latency, cost, context, and quality role; +- tools, structured outputs, caching, state replay, and multimodal inputs; +- downstream parsers or user-visible contracts; +- migration class and validation plan. + +## Choose the target model by role + +Use this as a starting map, then validate against the repository's workload: + +| Existing role | Starting target | Reason | +| --- | --- | --- | +| GPT-5.6 Sol or an earlier flagship | `gpt-6-astra` | Astra is the flagship-equivalent tier. | +| Balanced quality, latency, and cost | `gpt-5.6-terra` | Terra is the balanced option. | +| Faster or cheaper work, classification, extraction, routing, high-volume, or strict-latency route | `gpt-5.6-luna` | Luna is the primary speed and cost option. | +| GPT-4.1 or GPT-4o latency-sensitive flow | Start with Luna; evaluate Terra or Astra if quality requires it | A flagship replacement can change latency and cost materially. | +| Reasoning-heavy or hardest quality-first flow | Start with Astra at the old effective effort | Preserve the reasoning contract before tuning. | +| Router, fallback, or model picker | Add the family by role | Do not collapse a multi-model design into Astra. | +| Third-party or provider-specific model | Leave unchanged unless the user explicitly requests provider migration | Model-name similarity is not a safe mapping. | + +Important limits to check in live docs: + +- Each model's context window and maximum output. +- Long-context pricing thresholds for each route. +- Token pricing for GPT-6. + +Do not invent prices, limits, or capability flags. Fetch them from current docs before updating a registry or UI. + +For model pickers and registries, preserve existing model entries by default. Add GPT-6 Astra and retain the existing Terra and Luna options unless the user explicitly asks to replace or remove them. Do not invent pricing, context limits, capabilities, or metadata unless confirmed from canonical docs. + +If using the `gpt-6` alias, record the returned `response.model` during validation. Do not assume an alias and an explicit Astra slug appear identically in dashboards, rate-limit configuration, analytics, or billing metadata. + +## Structured outputs, parsers, and tool contracts + +Keep output contracts explicit: + +- preserve JSON schemas, required fields, enums, refusal handling, and parser expectations; +- preserve tool names, parameter schemas, call IDs, and retry behavior; +- keep citations, evidence fields, or native artifacts when downstream consumers require them; +- validate that the final answer still satisfies the contract, not merely that a tool call succeeded. + +Do not fix a failing migration by weakening a schema, deleting required behavior, removing routes, dropping tools, or changing business logic unless the user explicitly asked for that product change. + +## Prompt migration judgment + +After the model and API baseline is working, run representative traces before editing prompts. Change prompts only for measured failures. Read `references/prompting-guide.md` for the exact canonical prompting section when prompt changes are needed. + +## Upgrade workflow + +1. Fetch current live GPT-6 docs. Fetch the Prompting Best Practices section only when prompt changes are needed. +2. Inventory every usage site and its adjacent prompt, config, registry, parser, and test surfaces. +3. Classify each usage by role and migration class. +4. Choose Astra, Terra, or Luna by the existing workload's role. +5. Preserve the old effective reasoning effort explicitly when supported; follow the canonical migration guidance for unsupported settings. +6. Run the compatibility gates: + - endpoint and SDK support; + - Chat Completions plus function tools; + - cache topology and cache fields; + - context length and long-context cost; + - image, PDF, and file detail; + - structured outputs and parsers; + - Responses state replay and tool continuation; + - mixed-model routing and unsupported new fields. +7. Apply the smallest safe model, config, registry, and prompt changes. +8. Do not add optional Pro, persisted reasoning, PTC, explicit caching, async tools, or multi-agent behavior unless needed and measurable. +9. Run existing tests and representative evals. +10. Report changed, unchanged, blocked, and confirmation-needed sites separately. + +## Validation matrix + +Prefer a controlled comparison: + +1. old model + old prompt + old settings; +2. GPT-6 target + same prompt + preserved effective reasoning; +3. GPT-6 target + same prompt + one lower supported effort; +4. GPT-6 target + the smallest prompt or API fix required by a measured failure; +5. optional feature treatment, isolated from the baseline. + +Measure what matters for the workflow: + +- task success and user-visible quality; +- structured-output validity and parser success; +- tool choice, tool arguments, retries, loop count, and completion rate; +- TTFT, end-to-end latency, timeout rate, and concurrency behavior; +- input, output, reasoning, cached, and cache-write tokens; +- total cost per successful task; +- long-context, compaction, and replay behavior; +- image/PDF token use and visual/OCR accuracy; +- completeness, preserved behavior, citations, and validation evidence. + +For model routers and pickers, test at least one representative workload for each role. Verify that the cheapest or fastest tier is not accidentally used for quality-critical work and that Astra is not accidentally used for every workload. + +## Required final report + +Return: + +- `Current usage inventory`: each model site, endpoint, role, prompt surface, and old effective reasoning. +- `Target mapping`: Astra, Terra, Luna, unchanged, or confirmation-needed, with the reason. +- `Changes made`: model strings, reasoning settings, prompts, registries, metadata, tests, and API-shape changes. +- `Compatibility checks`: Chat Completions/tools, caching, state replay, multimodal detail, context/cost, schemas, and mixed-model routing. +- `Prompt changes`: each surgical edit and the failure mode it addresses. +- `Validation`: commands, evals, traces, before/after measurements, and remaining gaps. +- `Unchanged sites`: historical, pinned, ambiguous, or intentionally role-specific usages. +- `Blockers and open questions`: exact issue, why it is unsafe to guess, and the smallest next step. + +Never say the migration is complete merely because model strings changed. It is complete only when the affected behavior and contracts have been validated or the remaining gaps are stated explicitly. + +## Introduction + +GPT-6 Astra is our most intelligent model yet, with state-of-the-art performance in computer use, browsing, software engineering, science, and professional work. It excels at carrying out multistep workflows across code, browsers, and professional software. In several evaluations, Astra achieves stronger results while using substantially fewer output tokens—delivering a lower estimated API cost per task than earlier models despite its higher per-token pricing. + +GPT-6 Astra is also our most aligned model yet. It excels at exercising care, respecting task boundaries, and communicating transparently. When instructions leave room for interpretation, it uses the context it has to fill in routine gaps and asks focused questions when the answer could change the outcome. It incorporates new requirements, changes course when asked, and answers side questions without losing track of the broader task. + +To build with Astra, set `model` to `gpt-6-astra` in a [Responses API](https://developers.openai.com/api/docs/guides/migrate-to-responses) request. + +## What's new + +- **Async tool calling:** GPT-6 Astra can continue reasoning, call other tools, or answer independent parts of a request while your application runs a tool. Set `async: true` on a function or custom tool and return its result when ready using the original `call_id`. Your application still executes the tool and manages pending work. See [Async tool calling](https://developers.openai.com/api/docs/guides/async-tool-calling) for basic usage and a developer-defined wait-tool pattern. +- **Mid-turn steering:** Send additional user instructions while GPT-6 Astra is working, such as a correction or a change in requirements. Over a WebSocket connection, the Responses API preserves completed work and includes the update in a continuation. See [Mid-turn steering](https://developers.openai.com/api/docs/guides/steering) for the event flow and tool-result handling. +- **Change reasoning mid-conversation while preserving cache:** Add a `configuration_update` input item to increase reasoning effort for difficult work or reduce it for routine follow-ups without rewriting the original prompt prefix. The updated reasoning effort applies until another `configuration_update` input item overrides it. See [Change reasoning mid-conversation](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) for examples and compatibility. +- **Misalignment monitoring:** As part of our strengthened safeguards for GPT-6 Astra, our systems asynchronously monitor for misalignment and trigger alerts when necessary. See [Misalignment monitoring](https://developers.openai.com/api/docs/guides/safety-checks/misalignment-monitoring) for more information. +- **Limitations:** GPT-6 Astra does not support the `none` reasoning effort. [Fast mode](https://developers.openai.com/api/docs/guides/fast-mode) is unavailable for GPT-6 Astra with EU data residency. + +GPT-6 Astra also supports the existing API capabilities available with GPT-5.6, including [computer use](https://developers.openai.com/api/docs/guides/tools-computer-use), [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs), [streaming](https://developers.openai.com/api/docs/guides/streaming-responses), [Programmatic Tool Calling](https://developers.openai.com/api/docs/guides/tools-programmatic-tool-calling), [multi-agent orchestration](https://developers.openai.com/api/docs/guides/responses-multi-agent), [prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching), [persisted reasoning](https://developers.openai.com/api/docs/guides/reasoning#preserve-reasoning-across-calls), [compaction](https://developers.openai.com/api/docs/guides/compaction), and [pro mode](https://developers.openai.com/api/docs/guides/reasoning#reasoning-mode). + +## Migration quickstart + +### Migrate with Codex + +Codex can apply the recommended changes in this guide with the OpenAI Docs skill. + +```text +$openai-docs migrate this project to GPT-6 Astra +``` + +To use this skill in other coding agents, download it from the OpenAI skills repository. + +### Update API and model parameters + +Set `model` to `gpt-6-astra`, then check the following: + +- **Reasoning effort:** If you currently use `none` or `minimal`, start with `low` and compare results. Otherwise, preserve your current effective [reasoning effort](https://developers.openai.com/api/docs/guides/reasoning#reasoning-effort). Use `reasoning.effort` in Responses or `reasoning_effort` in Chat Completions. +- **Tool calling:** Use the [Responses API](https://developers.openai.com/api/docs/guides/migrate-to-responses#migrating-from-chat-completions). GPT-6 Astra supports Chat Completions, but tool calling requires Responses. +- **Unsupported parameters:** Remove `temperature`, `top_p`, and `top_logprobs`. For Chat Completions, also remove `logprobs`. For Responses, remove `message.output_text.logprobs` from `include`. +- **Fast mode:** For EU data residency, use Standard processing. GPT-6 Astra does not support `service_tier: "fast"` or `service_tier: "priority"` with EU data residency. Fast mode for GPT-6 Astra does not include a latency SLA. See [Fast mode compatibility](https://developers.openai.com/api/docs/guides/fast-mode#is-fast-mode-compatible-with-data-residency-zero-data-retention-and-a-baa). +- **Changing reasoning effort:** If your application changes effort between responses, use `configuration_update` items in standard, single-agent requests. Keep request-level `reasoning.effort` unchanged to preserve the prompt prefix for caching. Check the [compatibility limits](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) before adopting this feature. +- **Prompt caching:** When migrating from GPT-5.5 or earlier, replace `prompt_cache_retention` with `prompt_cache_options.ttl` set to `"30m"`. Review the [prompt caching changes](https://developers.openai.com/api/docs/guides/prompt-caching#summary-of-model-differences), including cache boundaries and cache-write billing. +- **Unnecessary approval pauses:** If you run into issues where the model keeps asking for approval before proceeding, use the [initiative and follow-through guidance](https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#initiative-and-follow-through) to prompt for more autonomous execution. See the rest of [Prompting best practices](https://developers.openai.com/api/docs/guides/latest-model/gpt-6-astra.md#prompting-best-practices) for guidance on instruction following, writing style, subagent delegation, and testing.