{
  "id": "rs_...",
  "type": "reasoning",
  "summary": [],
  "encrypted_content": "<long encrypted string>"
}

There isn’t much in it for your code to use. The items are opaque, the API doesn’t return their reasoning text, and summary stays empty unless you opt in to summaries. So it’s easy to write a tool loop that keeps the function call and throws the rest away.

But OpenAI’s docs ask you to send these items back. The function calling guide says they “must also be passed back with tool call outputs”. The reasoning guide says “we highly recommend” it, because that “allows the model to continue its reasoning process to produce better results in the most token-efficient manner.” When the model calls several functions in a row, that covers every reasoning item, function call and function output since the last user message.

You don’t have to work out which items matter, because the simplest option is to send all of them, and the service ignores the ones that aren’t relevant to your functions. If you trim history to save tokens, make sure everything between the last user message and your function output goes into the next request untouched.

Sending them back

How you send them depends on whether OpenAI kept the response. Responses are stored by default, and in that case previous_response_id is enough: you pass the ID along with your function output, and your code never handles the earlier items.

With store: false there is no stored response to continue from, and the same goes for organizations on Zero Data Retention, so the items have to go into input by hand. The function calling guide’s Python sample does it this way:

input_list += response.output

# after running the tool
input_list.append({
    "type": "function_call_output",
    "call_id": item.call_id,
    "output": horoscope,
})

The next request depends on the encrypted_content string in that list. When a request includes it, the migration guide says, “it is decrypted in memory, used for generating the next response, and then securely discarded”, and any new reasoning tokens come back encrypted. So your code has to hold on to those strings between calls.

Earlier turns

Everything so far is about one turn, the run of tool calls after a single user message. Reasoning from earlier turns has its own setting, reasoning.context. With current_turn, reasoning from the active turn is available, but reasoning from earlier turns doesn’t go into the next sample. With all_turns, the available and compatible items from earlier turns go in too. Currently the GPT-5.6 models use all_turns by default and earlier models default to current_turn.

all_turns only has an effect when the request can reach the earlier items, through previous_response_id, a conversation, or replaying the complete history yourself, which also works with store: false. The setting can’t bring back items your loop already threw away.

This note was put together from OpenAI’s current docs, and nothing here was run against the API, so we don’t have a number for what a dropped reasoning item costs. If you’ve measured it, we’d be glad to see the numbers. For now we’d keep the whole output list, and because the reasoning.context default already differs between model generations, look at the model’s page before switching.

這些原始內容不會出現在 API 的回傳裡（有些模型可以另外要求思考內容的摘要），但是它們仍然會佔用 context window 的空間，也會以輸出 token 計費。這有點像寫數學題時用的計算紙，雖然最後交出去的是答案，但是中途卻會用掉很多紙。因此，如果只用畫面上的字數來估算輸出費用，就會少算到這部分。

影響就要看問題的複雜程度，reasoning tokens 可能從幾百個到幾萬個，簡單的任務相對會比較少。

要去哪裡看用量

每次呼叫可以看回應裡的 usage，下面是 OpenAI 指南裡的範例：

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

output_tokens 是模型產生的所有 token，在這個例子裡共有 1186 個，其中 1024 個是 reasoning_tokens。不過要知道這兩個數字相減也不一定就等於畫面上的文字，因為有些模型還會產生格式用的 token，而這部分不一定會另外列出來。

那上限要怎麼設

如果想控制費用，可以用 max_output_tokens 限制模型產生的 token 總數。但是上限設得太低的話，模型可能還在思考就把額度用完了。此時回應的 status 會是 incomplete，原因（incomplete_details.reason）是 max_output_tokens，裡面可能沒有任何看得到的文字，而輸入和 reasoning tokens 還是可能要付費。碰到 context window 的上限也是同樣的結果，所以串接時也要記得檢查 status，並不是只看成功或是敗而已。

OpenAI 建議剛開始試用時，替 reasoning 和輸出預留至少 25,000 個 token，等到比較清楚自己的 prompt 大概需要多少，再來調整，這時就可以回頭參考前面的 reasoning_tokens。

如果想讓模型少想一點，也可以把 reasoning.effort 調低，速度會比較快，用的 token 也會比較少，但是回答可能就沒有那麼完整。我相信大家都是用這樣省token的，畢竟不是那麼的夠用。

其他關於 token 成本的想法，可以參考之前寫的Token 成本的真相：分級，但別分太細。

這篇是照 OpenAI 目前的 reasoning 和 token counting 文件寫的。effort 的選項、預設值和 context window 的大小都會隨模型不同，之後應該也還會再變，所以最終還是看每次呼叫回傳的 usage 比較準。