Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Responses API should support native `previous_response_id` chaining

未關閉
  • 哪裡不對？
#2,184 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
35/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
領域
api, backend-api-design, cli

研究方向

先追蹤 Responses API 的請求路徑和 SDK 的通訊協定欄位 PreviousResponseId，然後比較工具延續、後續使用者回合和恢復的工作階段。完成的標準是：受支援的提供者使用保留的回應 ID 搭配增量輸入、保留必要的設定、在鏈結失敗時回退到完整歷史記錄，並確保內容脈絡與工具行為正確。

由索引模型根據 Issue 內容生成。

描述

enhancement
Summary

When using the Copilot SDK/CLI with the Responses API, every model round reconstructs and sends the complete conversation history. The runtime does not send previous_response_id and sets store: false.

This substantially increases request tokens for long-running and resumed sessions.

Versions tested
  • GitHub.Copilot.SDK 1.0.5 with Copilot CLI 1.0.73
  • GitHub.Copilot.SDK 1.0.9-preview.1 with Copilot CLI 1.0.74
  • Azure AI Foundry OpenAI-compatible provider
  • wireApi: responses

The preview SDK references CLI 1.0.76-5, but that package was not available for testing.

Observed behavior

A privacy-safe request probe showed:

  • Initial request: 1 input item
  • Tool continuation: 3 input items
  • Next user turn: 5 input items
  • Resumed session in a new process: 7 input items

No request included previous_response_id. The runtime also emitted store: false.

In a real long-running session, this resulted in approximately 26K–28K reported input tokens per request, including tool continuations.

Expected behavior

After the initial Responses request:

  1. Set store: true, or otherwise use provider-supported response retention.
  2. Capture the terminal response ID.
  3. Send subsequent model rounds with:
    • previous_response_id
    • only newly added input items
  4. Preserve instructions, tools, and request settings as required by the Responses API.
  5. Fall back to full history if the provider rejects or cannot resolve the response ID.

This should apply to both tool-result continuations and subsequent user turns.

Workaround validation

We implemented an experimental request handler that:

  • changes store: false to store: true,
  • captures IDs from terminal SSE response events,
  • adds previous_response_id,
  • replaces reconstructed history with incremental input,
  • falls back to full history when chaining cannot be verified.

Live validation reduced:

  • a tool continuation from 60 input items to 1,
  • a subsequent user turn from 66 input items to 1.

Conversation context and tool behavior remained correct.

The handler also had to account for non-semantic differences when the CLI reconstructed response items:

  • regenerated top-level response item id,
  • omitted assistant-message phase,
  • omitted output-text logprobs.

Semantic content and tool call_id values were still compared exactly.

Request

Could native Responses API chaining be added to the Copilot CLI/runtime and exposed or enabled through the SDK?

It would also be useful to clarify:

  • whether the SDK’s PreviousResponseId protocol field is currently used by any provider path,
  • how response IDs should persist across SDK session resumes or process restarts,
  • whether token telemetry can report the actual rewritten wire input rather than reconstructed local history.
主要語言
TypeScript
星號
10.6k
分支
1.5k
平均合併
10 小時 8 分鐘
30 天內合併 PR
4

環境準備

在 Codespaces 中開啟

在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

github/copilot-sdk 的其他 Issue

查看 github/copilot-sdk 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。