For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主要導覽

建議

選擇模型

文字與程式碼

提示詞

推理

圖像與影片

即時互動與音訊

專用模型

API Dashboard
試用 ChatGPT

推理模型

瞭解推理模型的運作方式，以及如何有效使用。

推理模型 會在產生回應之前使用內部推理 Token。這有助於模型規劃、有效使用工具、檢視其他方案、釐清模糊之處，並解決更困難的多步驟任務。推理模型特別適合解決複雜問題、編寫程式碼、科學推理，以及多步驟的智慧體工作流程。它們也是我們的輕量程式碼編寫智慧體 Codex CLI 最適合使用的模型。

大多數推理工作負載都可以先使用 gpt-6-astra。若要降低成本，可考慮 gpt-5.6-terra；若要達到最低成本與延遲，則可選擇 gpt-5.6-luna。如果你使用的是 GPT-5.6 模型，請參閱推理模式，瞭解其 pro 選項。

推理模型搭配 Responses API 使用時表現更好。雖然仍支援 Chat Completions API， 但使用 Responses 可以提升模型的智慧能力 與效能。

開始使用推理

呼叫 Responses API，並指定推理模型與推理強度：

在 Responses API 中使用推理模型
from openai import OpenAI

client = OpenAI()

prompt = """
Write a bash script that takes a matrix represented as a string with
format '[1,2],[3,4],[5,6]' and prints the transpose in the same format.
"""

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "low"},
    input=[{"role": "user", "content": prompt}],
)

print(response.output_text)

推理強度

reasoning.effort 參數會引導模型在執行任務時投入多少思考。

支援的值因模型而異，可能包含 none、minimal、low、medium、high、xhigh 和 max。較低的推理強度偏重速度與較少的 Token 用量；較高的強度則讓模型思考得更周全，提供品質更高的回應。在各種推理強度下，模型也會依任務調整推理：簡單任務使用較少的 Token，複雜任務則投入更多思考。

GPT-6 Astra 不支援 none 推理強度。 將 reasoning.effort（Responses）或 reasoning_effort（Chat Completions）設為 none 時，會傳回 HTTP 400。

請使用 Responses API 進行函式呼叫。 Chat Completions 不支援使用 GPT-6 Astra 進行函式呼叫。

預設值也因模型而異，並非所有模型都相同。gpt-5.5 的預設推理強度為 medium。若要讓 gpt-5.5 在品質、可靠性與效能之間取得全面平衡，這是最佳的起始設定。

強度最適合
none對延遲要求嚴格，且無法從推理或多重串接的工具呼叫中獲益的任務。對於使用 gpt-5.5 且對延遲敏感的使用案例，建議先嘗試 low，再視需要改用 none。

常見使用案例包括語音、快速資訊檢索與分類。
low僅略微增加延遲，就能有效推理。適合需要使用工具、規劃、搜尋或多步驟決策，同時注重速度與成本的使用案例。

常見使用案例包括資料分析、草擬內容、著重實作的程式碼編寫，以及客戶支援／對話助理工作流程。
medium適合重視品質與可靠性，且涉及規劃、複雜推理與判斷的任務。這是大多數工作負載的預設組態，也是在延遲、效能與成本的帕累托曲線上相當均衡的選擇。

常見使用案例包括智慧體式程式碼編寫、研究、處理試算表與投影片，以及委派耗時較長的工作。
high適合高難度推理、複雜除錯、深入規劃，以及品質與智慧能力比延遲更重要的高價值任務。建議用於複雜工作流程與智慧體任務。

常見使用案例包括智慧體式程式碼編寫、耗時較長的研究，以及知識工作。請依任務的複雜程度，同時評估 medium 與 high。
xhigh適合深度研究、非同步工作流程，以及需要長時間執行的智慧體任務。只有在評估結果顯示明確效益，足以抵銷額外延遲與成本時，才應使用。

常見使用案例包括安全性與程式碼審查、企業生產力、較深入的研究任務，以及具挑戰性的程式碼編寫工作流程。
max為最複雜的任務投入最大程度的推理。如果你目前使用 xhigh，請評估 max 是否能帶來更好的表現。

對於延遲敏感的應用程式，若要縮短第一個可見 Token 出現前的等待時間，可要求模型先產生簡短的開場說明，再繼續深入推理。

部分模型僅支援其中一些值，因此請先查閱相關模型頁面，再選擇設定。

推理模式

GPT-5.6 模型在 Responses API 中支援 standard 與 pro 推理模式，預設為 standard。對於需要模型投入更多運算，且能接受較高延遲與 Token 用量的困難任務，請將 reasoning.mode 設為 pro。

推理模式與推理強度彼此獨立。模式用來選擇標準或 pro 執行方式，而 reasoning.effort 則控制模型在該模式下投入多少推理。如果省略 reasoning.effort，GPT-5.6 在兩種模式下都預設為 medium。

使用 pro 推理模式
curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-5.6",
    "reasoning": {
      "mode": "pro",
      "effort": "medium"
    },
    "input": "Review this database migration plan and identify potential failure modes."
  }'

Pro 模式會加總模型為產生最終答案所執行的運算，並依所選模型的標準 Token 費率計算這些 Token 的費用。Pro 模式執行的模型運算比標準模式更多，因此會增加 Token 用量與成本。現有 Pro 模型 ID 的行為與定價維持不變。

推理的運作方式

除了輸入與輸出 Token，推理模型還引入了 推理 Token 。模型使用這些推理 Token 來「思考」，拆解提示詞，並考量多種產生回應的方法。我們的推理模型（例如 gpt-5.5 與 gpt-5.4）支援交錯式思考，能在思考之前及思考的間隙產生可見的輸出 Token，也能在工具呼叫之間思考。

對於 GPT-5.6 之前發布的模型，多步驟對話的預設行為是沿用每個步驟的輸入與輸出 Token，但不將先前回合的推理納入下一次取樣。GPT-5.6 模型則預設會納入先前回合中可用的推理。在支援的模型上，可使用 reasoning.context 選擇這兩種行為之一。

使用目前回合上下文的推理 Token

雖然無法透過 API 查看推理 Token，但它們仍會占用 模型的上下文視窗空間，並依輸出 Token 計費。

控制成本

若要管理使用推理模型的成本，可以使用 max_output_tokens 參數，限制模型產生的 Token 總數， 包括推理 Token、可見的輸出 Token，以及不可見的格式 Token。 如需瞭解產生的 Token 如何計入用量與輸出限制，請參閱輸出 Token 計數。

管理上下文視窗

建立回應時，務必確保上下文視窗有足夠空間容納推理 Token。依問題的複雜程度而定，模型可能產生數百到數萬個推理 Token。你可以在回應物件的 usage 物件中，透過 output_tokens_details 查看實際使用的推理 Token 數量：

{
  "usage": {
    "input_tokens": 75,
    "input_tokens_details": {
      "cached_tokens": 0
    },
    "output_tokens": 1186,
    "output_tokens_details": {
      "reasoning_tokens": 1024
    },
    "total_tokens": 1261
  }
}

上下文視窗長度可在模型參考資料頁面查閱，且會因模型快照而異。

為推理預留空間

如果產生的 Token 達到上下文視窗上限或你設定的 max_output_tokens 值，你收到的回應中，status 會是 incomplete，而 incomplete_details 中的 reason 會設為 max_output_tokens。這可能發生在產生任何可見的輸出 Token 之前，也就是說，你可能已產生輸入與推理 Token 的費用，卻未收到可見的回應。

若要避免這種情況，請確保上下文視窗有足夠空間，或調高 max_output_tokens 的值。OpenAI 建議，剛開始試用這些模型時，至少為推理與輸出預留 25,000 個 Token。熟悉提示詞所需的推理 Token 數量後，就能據此調整預留空間。

處理未完成的回應
from openai import OpenAI

client = OpenAI()

prompt = """
Write a bash script that takes a matrix represented as a string with
format '[1,2],[3,4],[5,6]' and prints the transpose in the same format.
"""

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "medium"},
    input=[{"role": "user", "content": prompt}],
    max_output_tokens=300,
)

if (
    response.status == "incomplete"
    and response.incomplete_details.reason == "max_output_tokens"
):
    print("Ran out of tokens")
    if response.output_text:
        print("Partial output:", response.output_text)
    else:
        print("Ran out of tokens during reasoning")

跨呼叫保留推理

對話狀態與推理狀態的用途不同。在呼叫之間傳遞訊息，可讓模型取得可見的對話歷程。在支援的模型上，保留推理還能讓模型將先前回合中相容的推理項目納入下一次的上下文。

保留推理可提供連貫性，但不會揭露模型的原始推理。推理項目的內容仍無法直接檢視，API 也不會傳回其中的推理文字。設定 reasoning.context 可控制模型能使用哪些可用的推理項目：

GPT-5.6 模型系列 支援 all_turns，並預設使用此值。較早的模型則預設為 current_turn。省略 reasoning.context 或將其設為 auto，即可使用所選模型的預設值。

值行為
auto使用所選模型的預設值。省略 reasoning.context 的效果與設為 auto 相同。
current_turn讓目前回合的推理可供使用，但不會將先前回合的推理納入下一次取樣。
all_turns將先前回合中可用且相容的推理項目納入下一次取樣。GPT-5.6 模型支援此值。

回應的 reasoning.context 欄位包含實際生效的模式，值為 current_turn 或 all_turns。請檢查每個回應的此欄位，以確認模型使用的模式。這項設定不會建立原本不存在的推理項目。

只有當請求能存取先前的回應項目時，all_turns 才會生效。請使用 previous_response_id、將回應附加至對話，或手動重新傳入完整的回應歷程。第一次請求時，由於沒有先前的推理，current_turn 與 all_turns 的行為相同。

保留的推理只能在同一模型系列內重複使用。例如，gpt-5.6-sol、gpt-5.6-terra 與 gpt-5.6-luna 可以重複使用彼此的推理，但 GPT-5.6 與 GPT-5.5 系列之間無法沿用推理。

切換模型系列時，即使 reasoning.context 設為 all_turns，API 仍會從模型的上下文中排除不相容的推理。

使用已儲存的回應延續推理

使用 previous_response_id，即可用最精簡的方式整合有狀態功能：

透過先前的回應保留推理
from openai import OpenAI

client = OpenAI()
model = "gpt-5.6"

first = client.responses.create(
    model=model,
    input="Inspect this repository and identify the likely bug.",
    reasoning={"context": "current_turn"},
)

second = client.responses.create(
    model=model,
    previous_response_id=first.id,
    input="Now patch the bug and explain the change.",
    reasoning={"context": "all_turns"},
)

print(second.output_text)

重新傳入模型已不再需要的舊回應項目時，請使用 current_turn。這些推理項目可以保留在 API 酬載中以維持連續性，但服務不會將它們納入新一輪取樣。這能減少長時間執行的工作流程在取樣時使用的上下文。

不儲存回應也能保留推理

以無狀態模式建立回應時，回應的 output 陣列中的推理項目預設會包含 encrypted_content 屬性。當 store 為 false，或您的組織使用零資料保留 (ZDR) 時，就會採用無狀態模式。為維持相容性，API 仍接受在 include 中使用舊版的 reasoning.encrypted_content 值，但不要求提供此值。

以下請求不指定 include，也會傳回加密的推理內容：

curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6-astra",
    "store": false,
    "reasoning": {"effort": "medium"},
    "input": "What is the weather like today?",
    "tools": [ ... function config here ... ]
  }'

output 陣列中的推理項目會包含 encrypted_content 屬性，其中存放加密的推理 Token，可傳入後續呼叫。

若要在 store: false 的情況下使用 all_turns，請保留每個輸出項目，附加下一則使用者訊息，然後重新傳入完整歷史記錄：

不儲存回應也能保留推理
from openai import OpenAI

client = OpenAI()
model = "gpt-5.6"

history = [
    {
        "role": "user",
        "content": "Inspect this repository and identify the likely bug.",
    }
]

first = client.responses.create(
    model=model,
    store=False,
    input=history,
    reasoning={"context": "current_turn"},
)

# Keep every output item, including encrypted reasoning and assistant phase.
history.extend(item.model_dump() for item in first.output)
history.append(
    {
        "role": "user",
        "content": "Now patch the bug and explain the change.",
    }
)

second = client.responses.create(
    model=model,
    store=False,
    input=history,
    reasoning={"context": "all_turns"},
)

print(second.output_text)

在上下文中保留推理項目

在 Responses API 中使用推理模型進行函式呼叫時，除了函式的輸出之外，我們強烈建議您也傳回最後一次函式呼叫所傳回的所有推理項目。如果模型連續呼叫多個函式，您應傳回自最後一則 user 訊息以來的所有推理項目、函式呼叫項目及函式呼叫輸出項目。這能讓模型延續推理過程，以最節省 Token 的方式產生更好的結果。

最簡單的做法是將前一次回應中的所有推理項目傳入下一次回應。我們的系統會自動判斷並忽略與您的函式無關的推理項目，只在上下文中保留相關項目。您可以使用 previous_response_id 參數傳入先前回應的推理項目，也可以手動將先前回應的所有輸出項目傳入新回應的輸入。

在進階使用案例中，您可能會先截斷並最佳化部分上下文視窗內容，再將其傳入下一次回應。此時，只要確保最後一則使用者訊息與函式呼叫輸出之間的所有項目都原封不動地傳入下一次回應，就能讓模型取得所需的完整上下文。

如需進一步瞭解如何手動管理上下文，請參閱這份指南。

在對話中途調整推理

使用 configuration_update，可在處理困難工作時提高推理強度，或在處理例行後續請求時降低推理強度。請在兩次回應之間加入更新，並保持請求層級的 reasoning.effort 不變。這樣就能保留原始提示詞前綴，供提示詞快取使用。

只有 GPT-6 Astra (gpt-6-astra) 在 標準、單一智慧體模式下支援組態更新。組態更新只能變更推理強度。

請在 HTTP Responses 請求或 WebSocket response.create 請求的 input 陣列中，於下一則使用者訊息之前加入以下項目：

{
  "type": "configuration_update",
  "reasoning": {
    "effort": "high"
  }
}

例如，若對話開始時請求層級的推理強度為 low，這項更新會將下一次及後續回應的推理強度設為 high，直到另一項更新覆寫此設定為止。

提高後續回應的推理強度
from openai import OpenAI

client = OpenAI()
model = "gpt-6-astra"

response = client.responses.create(
    model=model,
    reasoning={"effort": "low"},
    input="Draft a database migration plan.",
    store=True,
)
print(response.output_text)

response = client.responses.create(
    model=model,
    previous_response_id=response.id,
    reasoning={"effort": "low"},
    input=[
        {
            "type": "configuration_update",
            "reasoning": {"effort": "high"},
        },
        {
            "role": "user",
            "content": "Analyze the failure modes and propose rollback steps.",
        },
    ],
    store=True,
)
print(response.output_text)

使用 previous_response_id 保留更新，或在手動管理對話歷史記錄時，依照更新的原始位置重新傳入。回應的 reasoning.effort 仍會回報請求層級的設定，而非更新所選定的推理強度。

請勿在對話歷史記錄中將兩個 configuration_update 項目緊鄰放置；API 會拒絕相鄰的更新。

請勿將組態更新與自動壓縮或自動截斷搭配使用。獨立的 /responses/compact 端點也會拒絕包含這些更新的歷史記錄。

您仍可在 /responses 請求中加入 compaction_trigger 項目，明確觸發歷史記錄壓縮。壓縮完成後，請在下一則使用者訊息之前加入新的 configuration_update，並指定所需的推理強度。

一般的提示詞快取要求仍然適用。若要在回應仍在執行時傳送使用者指示，請使用回合中調整方向。

推理摘要

我們不會公開模型產生的原始推理 Token，但您可以使用 summary 參數查看模型的推理摘要。請參閱模型文件，確認哪些推理模型支援摘要。

不同模型支援的推理摘要設定各不相同。例如，我們的電腦操作模型支援 concise 摘要產生器，而 o4-mini 則支援 detailed。若要使用模型所提供最詳細的摘要產生器，請將此參數設為 auto。對目前大多數推理模型而言，auto 等同於 detailed，但未來可能會提供更細緻的設定。

推理摘要輸出是 reasoning 輸出項目中 summary 陣列的一部分。只有在您明確選擇包含推理摘要時，回應才會包含這項輸出。

以下範例示範如何發出 API 請求，讓回應包含推理摘要。

在 API 回應中包含推理摘要
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    reasoning={"effort": "low", "summary": "auto"},
)

print(response.output)

這個 API 請求會傳回一個輸出陣列，其中包含助理訊息，以及模型產生該回應時的推理摘要。

[
  {
    "id": "rs_6876cf02e0bc8192b74af0fb64b715ff06fa2fcced15a5ac",
    "type": "reasoning",
    "summary": [
      {
        "type": "summary_text",
        "text": "**Answering a simple question**\n\nI\u2019m looking at a straightforward question: the capital of France is Paris. It\u2019s a well-known fact, and I want to keep it brief and to the point. Paris is known for its history, art, and culture, so it might be nice to add just a hint of that charm. But mostly, I\u2019ll aim to focus on delivering a clear and direct answer, ensuring the user gets what they\u2019re looking for without any extra fluff."
      }
    ]
  },
  {
    "id": "msg_6876cf054f58819284ecc1058131305506fa2fcced15a5ac",
    "type": "message",
    "status": "completed",
    "content": [
      {
        "type": "output_text",
        "annotations": [],
        "logprobs": [],
        "text": "The capital of France is Paris."
      }
    ],
    "role": "assistant"
  }
]

在搭配我們最新的推理模型使用摘要產生器之前，您可能需要 完成組織 驗證， 以確保安全部署。請前往平台 設定頁面開始驗證。

phase 參數

在 Responses API 中使用 GPT-5.5 和 GPT-5.4 執行長時間或大量使用工具的流程時，請使用助理訊息的 phase 欄位，避免提早停止及其他異常行為。 phase 在 API 層級是選用欄位，但 OpenAI 建議使用。助理的中途更新（例如工具呼叫前的簡短說明）請使用 phase: "commentary"，完成的答案則使用 phase: "final_answer"。請勿在使用者訊息中加入 phase。 使用 previous_response_id 通常是最簡單的做法，因為它會保留先前的助理狀態。如果您手動重新傳入助理歷史記錄，請保留每個原始的 phase 值。 若缺少或遺漏 phase，這類工作流程可能會將開場說明視為最終答案。如需特定模型的提示詞指引，請參閱GPT-5.5 提示詞指南。

將助理的 phase 值原樣傳回

將助理的 phase 值原樣傳回
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input=[
        {
            "role": "assistant",
            "phase": "commentary",
            "content": "I’ll inspect the logs and then summarize root cause and remediation.",
        },
        {
            "role": "assistant",
            "phase": "final_answer",
            "content": "Root cause: cache invalidation race.",
        },
        {
            "role": "user",
            "content": "Great—now give me a rollout-safe fix plan.",
        },
    ],
)

print(response.output_text)

提示詞撰寫建議

為推理模型撰寫提示詞時，請留意以下差異。具備推理能力的 GPT-5 模型通常在收到清楚的目標、嚴謹的限制條件及明確的輸出規範，且未被要求遵循每個中間步驟時，表現最佳。

  • 向模型提供任務、限制條件及所需的輸出格式。
  • 將 reasoning.effort 視為調整設定，而非改善品質的主要手段。
  • 對於智慧體式或需要大量研究的工作流程，請定義完成標準，以及模型應如何驗證自己的工作成果。

如需進一步瞭解使用推理模型的最佳實務，請參閱這份指南。

提示詞範例

OpenAI o 系列模型能實作複雜的演算法並產生程式碼。這個提示詞要求 o1 根據特定條件重構 React 元件。

重構程式碼
import OpenAI from "openai";

const openai = new OpenAI();

const prompt = `
Instructions:
- Given the React component below, change it so that nonfiction books have red
  text.
- Return only the code in your reply
- Do not include any additional formatting, such as markdown code blocks
- For formatting, use four space tabs, and do not allow any lines of code to
  exceed 80 columns

const books = [
  { title: 'Dune', category: 'fiction', id: 1 },
  { title: 'Frankenstein', category: 'fiction', id: 2 },
  { title: 'Moneyball', category: 'nonfiction', id: 3 },
];

export default function BookList() {
  const listItems = books.map(book =>
    <li>
      {book.title}
    </li>
  );

  return (
    <ul>{listItems}</ul>
  );
}
`.trim();

const response = await openai.responses.create({
  model: "gpt-6-astra",
  input: [
    {
      role: "user",
      content: prompt,
    },
  ],
});

console.log(response.output_text);

使用案例範例

你可以在 Cookbook 中找到一些將推理模型應用於實際情境的範例。

運用推理驗證資料

檢查合成醫療資料集中的不一致之處。
運用推理產生作業流程

使用說明中心文章，產生智慧體可執行的動作。