feat(ai-anthropic): support native on-demand compaction

オープン
  • 何か問題がありますか？
#2,081 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@tombeckenham がすでに取り組んでいます。

2026年11月7日 から。

評価

この issue はまだ評価されていません。

説明

waiting-on: maintainer

Request

Implement explicit, on-demand native compaction in @tanstack/ai-anthropic, exposed through the existing optional TextAdapter.compact() capability and consumed by withCompaction({ native: adapter }).

Current behavior

Checked @tanstack/ai-anthropic 1.1.1 and current main. The Anthropic text adapter has no compact() implementation. Passing it as native therefore uses the configured strategy. createAnthropicSummarize is ordinary chat-based summarization, not Anthropic's native compaction operation.

The existing abstraction appears suitable: #1729 added provider-native compaction, with an OpenAI Responses implementation and strategy fallback. I found no existing issue or PR requesting the Anthropic equivalent.

Why this is useful

Claude applications using TanStack's compaction middleware currently need their own provider bridge to call native compaction. That duplicates provider request mapping, capability checks, cancellation, error handling, and usage parsing. Keeping those responsibilities in the adapter would make this capability reusable across applications while retaining the existing portable strategy fallback and full-transcript/provider-context split.

This is an additional provider strategy, not a claim that native summaries are lossless or always preferable to application-defined summaries.

Provider requirements and interface gap

Anthropic documents on-demand compaction as a separate Messages request with compaction: { type: "summarize" } and the compact-2026-09-04 beta. Models expose support through capabilities.compaction.

Unlike the initial OpenAI implementation, it needs the conversation's system prompt and tool definitions, plus an explicit output allowance. TextCompactOptions currently carries system prompts but neither tools nor model options. A supported way to provide the relevant chat configuration would be needed rather than silently dropping tools or asking applications to rebuild provider serialization.

Other important behavior:

  • Propagate cancellation and wrapFetch.
  • Keep the compaction call outside ordinary tool execution.
  • Validate stop_reason === "compaction" and a nonempty compaction block. HTTP 200 can otherwise contain no usable summary.
  • Preserve provider data in the returned result, including the signature.
  • Let unsupported models or unusable results enter the existing strategy fallback.
  • Account for compaction usage, which Anthropic reports in usage.iterations.

Scope

This request concerns explicit native compaction through the existing adapter/middleware model. Provider-managed threshold compaction, new persistence infrastructure, and a general signed-block replay or retained-thinking redesign are outside this request. The detailed replay contract can be discussed separately, while ensuring the native result is not reduced to unsigned text.

#1959 and #2040 address signed thinking blocks after history rewriting. They do not implement the native compaction operation requested here.

Is extending TextCompactOptions with the required chat configuration the preferred direction, or would maintainers prefer adapter-specific compaction options?

主要言語
TypeScript
スター
3.3k
フォーク
378
平均マージ
1日 3時間
マージ済み PR（30日）
253

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/ai のほかの issue

TanStack/ai の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。