Pemikiran yang dipertahankan

"Preserved thinking" (pemikiran yang dipertahankan) adalah properti model Claude yang lebih baru yang melindungi dari "distillation" (distilasi). Properti ini menentukan apakah model dapat menggunakan "thinking block" (blok pemikiran) yang Anda kirim kembali dari giliran sebelumnya. Mulai dari Claude Fable 5.1, ketika blok thinking atau redacted_thinking dikirim kembali dalam sebuah permintaan, API memeriksa signature blok tersebut untuk dua hal:

• Model dapat membaca blok tersebut. Setiap model membaca blok pemikirannya sendiri dan blok pemikiran dari sekumpulan model lain yang sudah ditetapkan. Claude Fable 5.1 membaca blok dari Claude Opus 5 dan, di Claude API, dari Claude Opus 5.5; baik Claude Opus 5 maupun Claude Opus 5.5 tidak membaca blok dari Claude Fable 5.1. Jika model saat ini tidak dapat membaca sebuah blok, API membuangnya dari permintaan tersebut tanpa error. Lihat Beralih model di tengah percakapan.
• Tidak ada yang berubah sebelum blok pemikiran. Prompt system tingkat atas, tools, dan messages sebelum blok tersebut adalah "prefix" (prefiks) blok itu. Jika prefiks berbeda dari yang Anda kirim saat blok tersebut dihasilkan, blok itu dan setiap blok pemikiran setelahnya menjadi tidak valid, dan API menolak permintaan dengan error 400 atau membuang blok yang tidak valid, sesuai pilihan Anda. Lihat Menjaga prefiks tetap tidak berubah.

Blok pemikiran dari Claude Sonnet 5.5 dan Claude Haiku 5.5 juga terikat pada akun yang menghasilkannya. Lihat Blok pemikiran tetap berada di akun yang menghasilkannya untuk mengetahui di mana API memberlakukan hal ini.

Pemeriksaan model berlaku untuk setiap akun. API memberlakukan pemeriksaan prefiks secara default untuk akun yang dibuat pada atau setelah 31 Agustus 2026, 00:00 UTC. Pada akun yang lebih lama, API memberlakukan pemeriksaan prefiks hanya pada permintaan yang menetapkan thinking.block_binding.prefix_mismatch_behavior. Buat integrasi Anda bersifat append-only (hanya menambahkan) terlepas dari usia akun Anda, sehingga kode yang sama berfungsi di setiap akun, termasuk akun yang lebih baru tempat pemeriksaan diberlakukan secara default.

Siapa yang perlu mengubah sesuatu

Tidak ada yang berubah bagi Anda jika Claude Code, claude.ai, Claude Managed Agents, atau Claude Agent SDK yang membangun permintaan Anda, atau jika kode Anda menjaga system dan tools tetap selama satu sesi dan hanya menambahkan ke messages. Claude Mythos 5.1 dan model sebelum Claude Fable 5.1 tidak menjalankan pemeriksaan prefiks. Jika Anda tidak pernah mengirim kembali blok pemikiran, pemeriksaan prefiks tidak memiliki apa pun untuk ditolak, dan model tidak mendapatkan penalaran sebelumnya sama sekali.

Periksa integrasi Anda jika, di antara dua permintaan dalam satu percakapan, integrasi tersebut melakukan salah satu hal berikut. Setiap item menautkan ke apa yang harus dilakukan sebagai gantinya:

• Membangun ulang prompt system: tanggal, flag mode, instruksi proyek yang dibaca ulang, atau plugin atau server "Model Context Protocol", atau MCP, yang terhubung setelah giliran pertama
• Merender ulang konteks dalam pesan pengguna pertama
• Menghapus atau memperpendek hasil alat lama, atau meng-encode ulang gambar lama
• Meringkas atau membuang giliran lama di sisi klien dan mempertahankan giliran terbaru beserta pemikirannya
• Menambahkan, menghapus, atau mengedit entri dalam tools
• Menambahkan pengingat ke giliran pengguna lalu menghapus atau menulis ulangnya kemudian
• Membuang beberapa blok thinking dan mempertahankan yang setelahnya, atau menghapusnya lalu memasukkannya kembali nanti
• Membangun ulang sesi tersimpan dari template alih-alih memutar ulang apa yang telah dikirim

Pada akun yang lebih lama, tidak satu pun dari hal ini menghasilkan error kecuali permintaan menetapkan prefix_mismatch_behavior, sehingga proses yang berjalan tanpa error dengan kunci Anda sendiri tidak menunjukkan apakah kode Anda terpengaruh. Jika orang menjalankan alat Anda dengan kunci API mereka sendiri, mereka yang menggunakan akun lebih baru akan mendapatkan error 400 sebelum Anda. Untuk melihat apa yang mereka lihat tanpa mengubah perilaku permintaan Anda, kirim header beta thinking-binding-controls-2026-08-01. Pada akun yang lebih lama, setiap respons kemudian menandai blok yang gagal dalam pemeriksaan, dan model tetap membacanya (lihat Menetapkan perilaku ketidakcocokan dan membaca input_transformations).

Periksa juga integrasi Anda jika integrasi tersebut mengirim blok pemikiran Claude Sonnet 5.5 atau Claude Haiku 5.5 dari satu akun dalam permintaan yang dibuat oleh akun lain. Lihat Blok pemikiran tetap berada di akun yang menghasilkannya.

Beralih model di tengah percakapan

Claude Fable 5.1 dan Claude Mythos 5.1 membaca blok pemikiran yang dihasilkan oleh satu sama lain dan oleh model Claude sebelumnya. Tidak ada model lain yang membaca blok pemikiran dari Claude Fable 5.1 atau Claude Mythos 5.1.

Claude Opus 5.5 membaca blok pemikiran dari Claude Opus 5, dari model Opus, Sonnet, dan Haiku sebelumnya, dan, di Claude API dan Google Cloud, dari Claude Sonnet 5.5 dan Claude Haiku 5.5, tetapi tidak dari model Claude Fable atau Claude Mythos. Di Claude API, Claude Fable 5.1 dan Claude Mythos 5.1 membaca blok pemikiran dari Claude Opus 5.5; tidak ada model lain yang melakukannya. Jadi percakapan yang berpindah dari Claude Opus 5 ke Claude Opus 5.5 mempertahankan penalarannya, begitu pula percakapan yang berpindah dari Claude Opus 5.5 naik ke Claude Fable 5.1 atau Claude Mythos 5.1 di Claude API. Percakapan yang berpindah dari Claude Fable 5.1 atau Claude Mythos 5.1 ke Claude Opus 5.5, atau dari Claude Opus 5.5 ke model apa pun selain kedua model tersebut, menjalankan giliran setelah peralihan tanpa penalaran model sebelumnya. Blok-blok tersebut dibuang, bukan ditolak, seperti yang dijelaskan nanti di bagian ini.

Claude Sonnet 5.5 membaca blok pemikiran dari Claude Sonnet 5, Claude Opus 4.8, Claude Haiku 4.5, dan model sebelumnya, serta, di Claude API dan Google Cloud, dari Claude Haiku 5.5, tetapi tidak dari Claude Opus 5, Claude Opus 5.5, atau model Claude Fable atau Claude Mythos mana pun. Di Claude API dan Google Cloud, Claude Opus 5.5 membaca blok pemikiran dari Claude Sonnet 5.5; tidak ada model lain yang melakukannya. Jadi percakapan yang berpindah dari Claude Sonnet 5 ke Claude Sonnet 5.5 mempertahankan penalarannya, begitu pula percakapan yang berpindah dari Claude Sonnet 5.5 naik ke Claude Opus 5.5 di Claude API dan Google Cloud. Percakapan yang berpindah ke Claude Sonnet 5.5 dari Claude Opus 5, Claude Opus 5.5, atau model Claude Fable atau Claude Mythos menjalankan giliran setelah peralihan tanpa penalaran model sebelumnya. Begitu pula perpindahan lain apa pun dari Claude Sonnet 5.5, misalnya fallback sisi server ke Claude Sonnet 5.

Claude Haiku 5.5 membaca blok pemikiran dari Claude Sonnet 5, Claude Opus 4.8, Claude Haiku 4.5, dan model sebelumnya, tetapi tidak dari Claude Opus 5, Claude Opus 5.5, Claude Sonnet 5.5, atau model Claude Fable atau Claude Mythos mana pun. Di Claude API dan Google Cloud, Claude Opus 5.5 dan Claude Sonnet 5.5 membaca blok pemikiran dari Claude Haiku 5.5; tidak ada model lain yang melakukannya. Jadi percakapan yang berpindah dari Claude Haiku 4.5 ke Claude Haiku 5.5 mempertahankan penalarannya, begitu pula percakapan yang berpindah dari Claude Haiku 5.5 naik ke Claude Opus 5.5 atau Claude Sonnet 5.5 di Claude API dan Google Cloud. Percakapan yang berpindah ke Claude Haiku 5.5 dari Claude Opus 5, Claude Opus 5.5, Claude Sonnet 5.5, atau model Claude Fable atau Claude Mythos menjalankan giliran setelah peralihan tanpa penalaran model sebelumnya, begitu pula perpindahan lain apa pun dari Claude Haiku 5.5.

• Percakapan yang berpindah ke Claude Fable 5.1 dari model sebelumnya, atau dari Claude Opus 5.5 di Claude API, mempertahankan penalarannya. Blok pemikiran model sebelumnya tetap dapat dibaca, sehingga model berpikir seperti biasa sejak giliran pertama setelah peralihan.
• Percakapan yang berpindah dari Claude Fable 5.1 ke model apa pun selain Claude Mythos 5.1 kehilangan penalaran Claude Fable 5.1 untuk permintaan tersebut. Hal ini terjadi ketika router mengirim giliran ke model yang lebih murah, setelah fallback penolakan classifier, atau selama fallback sisi server. API menghapus blok yang tidak dapat dibaca sebelum prompt mencapai model. Blok tersebut tidak ditagih dan tidak dihitung dalam input_tokens.

Tetap kirim riwayat lengkap pada setiap permintaan, termasuk blok pemikiran, dan biarkan API membuang apa yang tidak dapat dibaca oleh model saat ini. API tidak pernah mengedit array messages Anda, sehingga blok yang dibuang tetap ada dalam riwayat Anda. Ketika riwayat yang sama kembali ke Claude Fable 5.1, bloknya dapat dibaca lagi, bersama dengan pemikiran model sebelumnya. Penalaran hilang secara permanen hanya jika klien Anda sendiri yang menghapus blok tersebut, misalnya harness yang menghapus pemikiran saat peralihan model atau membangun ulang riwayat dari apa yang digunakan setiap model.

Dengan header beta thinking-binding-controls-2026-08-01, respons mencantumkan setiap blok yang dibuang dalam array input_transformations tingkat atas dengan reason: "model_binding_mismatch":

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.3.content.0",
      "reason": "model_binding_mismatch"
    }
  ]
}

Tanpa header tersebut, pembuangan terjadi secara diam-diam. Entri ini bukan bug dalam integrasi Anda, dan prefix_mismatch_behavior tidak berpengaruh padanya: blok yang tidak dapat dibaca oleh model saat ini selalu dibuang.

Blok pemikiran tetap berada di akun yang menghasilkannya

Blok pemikiran yang dihasilkan Claude Sonnet 5.5 atau Claude Haiku 5.5 hanya berfungsi di akun yang menghasilkannya, atau di akun yang terhubung dengannya. Ketika akun lain mengirim salah satu blok ini, API membuang blok tersebut sebelum model melihatnya, dan permintaan berhasil. Model menjawab tanpa penalaran dalam blok yang dibuang. Blok dari model sebelumnya tidak terpengaruh.

Di Claude API dan Google Cloud, dengan header beta thinking-binding-controls-2026-08-01, respons mencantumkan setiap blok yang dibuang dalam input_transformations sebagai entri thinking_dropped dengan reason: "organization_binding_mismatch". Tanpa header tersebut, pembuangan terjadi secara diam-diam.

Menjaga prefiks tetap tidak berubah

Pada Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, dan Claude Haiku 5.5, blok pemikiran tetap valid hanya selama semua yang Anda kirim sebelumnya tidak berubah pada permintaan berikutnya. Prefiks yang diperiksa memiliki tiga bagian:

• Prompt system tingkat atas
• Kumpulan tools
• Setiap message sebelum blok tersebut

Catatan: Dengan compaction (pemadatan) sisi server, prefiks yang diperiksa dimulai dari blok compaction terbaru.

Parameter permintaan di luar ketiga field tersebut, seperti effort, max_tokens, output_config, tool_choice, dan metadata, bukan bagian dari pemeriksaan prefiks, begitu pula penanda cache_control. Apa yang dihitung sebagai edit memiliki daftar lengkapnya.

Blok pemikiran sebelumnya tidak termasuk dalam prefiks, tetapi setiap blok pemikiran mencatat blok pemikiran mana yang datang sebelumnya, lintas giliran. Anda dapat menghapus blok pemikiran dari awal riwayat (yang terlama terlebih dahulu), dari akhir, atau semuanya. Yang gagal adalah celah: blok pemikiran yang Anda pertahankan harus merupakan rangkaian tak terputus dari urutan aslinya, sehingga menghapus satu blok dari tengah membuat blok pemikiran setelahnya tidak valid. Setelah Anda menghapus sebuah blok, biarkan tetap dihapus. Memasukkannya kembali membuat blok pemikiran yang dihasilkan selama blok itu tidak ada menjadi tidak valid.

Jaga system dan tools tetap selama sesi dan perlakukan messages sebagai append-only. Disiplin yang sama menjaga prefiks tetap stabil untuk "prompt caching" (caching prompt): edit yang membuat pemikiran tidak valid adalah edit yang memulai ulang cache.

Apa yang dilakukan API dengan blok yang tidak valid

Anda memilihnya dengan thinking.block_binding.prefix_mismatch_behavior:

• "error" (default): API menolak permintaan dengan 400 invalid_request_error yang menyebutkan blok pertama yang gagal.
• "drop_block": API membuang setiap blok yang gagal dan setiap blok pemikiran setelahnya, dan permintaan berhasil. Blok yang dibuang tidak ditagih. Model menjawab giliran tersebut tanpa menggunakan penalaran dari blok yang dibuang, dan cache prompt dimulai ulang pada titik edit. Respons mencantumkan setiap blok yang dibuang dalam input_transformations (pada event message_start saat streaming) dengan reason: "prefix_binding_mismatch".

Hitung respons dalam setiap sesi yang input_transformations-nya memiliki entri prefix_binding_mismatch, buat peringatan untuk respons tersebut, dan ganti setiap edit dengan pola yang sesuai di Melakukan perubahan tanpa mengedit prefiks. Di Message Batches API, item yang tidak menetapkan field tersebut tidak gagal. Jika API memberlakukan pemeriksaan secara default, API akan membuang blok yang gagal sebagai gantinya. Tetapkan "error" secara eksplisit jika Anda ingin item batch gagal dalam kasus tersebut.

Field tersebut dan array input_transformations sama-sama memerlukan header beta thinking-binding-controls-2026-08-01. Menetapkan perilaku ketidakcocokan dan membaca input_transformations menunjukkan permintaan tersebut di setiap "software development kit" (kit pengembangan perangkat lunak), atau SDK.

Pesan 400 dimulai dengan:

messages.1.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block".

Jika permintaan tidak mengirim header beta, pesan berlanjut:

That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Pesan tersebut biasanya diakhiri dengan kalimat yang menyebutkan apa yang berubah, misalnya bahwa prompt system atau daftar tools berbeda dari saat blok dibuat. Pemecahan masalah pemikiran menjelaskan apa saja yang dapat disebutkan oleh kalimat tersebut.

Signature yang dirusak atau tidak dapat didekripsi adalah kegagalan yang berbeda. Kegagalan ini selalu mengembalikan 400 (Invalid `signature` in `thinking` block tanpa kalimat tentang percakapan), dan prefix_mismatch_behavior tidak berlaku untuknya.

Biaya token output dari "drop_block"

Dalam pengujian Anthropic pada benchmark coding multi-giliran, membuang blok pemikiran sekali per sesi meningkatkan token output sebesar 2,5% pada effort rendah, 3,9% pada sedang, 4,5% pada tinggi, dan 20,1% pada maksimum. Membuangnya pada setiap giliran setelah yang pertama meningkatkan token output sebesar 4,6% pada effort rendah, 9,7% pada sedang, 10,3% pada tinggi, dan 67,1% pada maksimum. Angka-angka ini adalah perkiraan dengan rentang error yang lebar, dan dampaknya pada beban kerja Anda bergantung pada harness Anda.

Ketika Claude tidak dapat lagi membaca penalaran dari giliran sebelumnya, Claude membuat ulang penalaran tersebut, sehingga permintaan yang membuang blok pemikiran menghasilkan lebih banyak token output dan dapat membutuhkan waktu lebih lama untuk merespons. Pembuangan pada setiap giliran lebih mahal daripada pembuangan sesekali, dan seberapa besar selisihnya bergantung pada harness Anda: seberapa sering harness mengedit prefiks dan seberapa banyak setiap giliran dibangun di atas penalaran sebelumnya.

Sebelum Anda mengandalkan "drop_block", jalankan eval pada beban kerja Anda sendiri untuk mengukur peningkatannya. Jika kecil, "drop_block" dapat membuat permintaan tetap berhasil selagi Anda memperbaiki edit. Bagaimanapun juga, memperbaiki edit dengan pola dari Melakukan perubahan tanpa mengedit prefiks adalah solusi jangka panjang yang lebih baik.

Menangani error dalam kode

Ini adalah 400 invalid_request_error yang ditunjukkan sebelumnya di bagian ini. Jangan mengirim ulang body yang sama: body tersebut akan gagal dengan cara yang sama setiap kali. Coba ulang sekali dengan header beta dan prefix_mismatch_behavior: "drop_block", sebagai solusi sementara ("drop_block" dapat meningkatkan token output), dan simpan pilihan tersebut bersama sesi sehingga setiap permintaan berikutnya juga mengirimkannya, termasuk setelah restart. Pada Claude Sonnet 5.5 dan Claude Haiku 5.5, block_binding hanya berfungsi dengan thinking: {"type": "adaptive"}. Dengan between_tools pada Claude Sonnet 5.5, atau thinking: {"type": "disabled"} pada Claude Haiku 5.5, jaga riwayat tetap append-only, atau hapus blok pemikiran mulai dari giliran yang diedit. Jika Anda tidak dapat mengirim header beta, hapus setiap blok thinking dan redacted_thinking dari riwayat sekali, biarkan tetap dihapus, dan lanjutkan. Kemudian perbaiki edit yang menyebabkan ketidakcocokan.

Menetapkan perilaku ketidakcocokan dan membaca input_transformations

Header beta thinking-binding-controls-2026-08-01 menambahkan:

• Array input_transformations tingkat atas pada setiap respons
• Objek block_binding pada konfigurasi thinking, yang satu-satunya field-nya adalah prefix_mismatch_behavior

block_binding diterima bersama thinking.type: "adaptive" dan thinking.type: "enabled". Pada Claude Sonnet 5.5 dan Claude Haiku 5.5, block_binding hanya berfungsi dengan thinking: {"type": "adaptive"}. Mengirimkannya dengan between_tools pada Claude Sonnet 5.5, atau dengan thinking: {"type": "disabled"} pada Claude Haiku 5.5, mengembalikan error 400. Mengirimkannya tanpa header beta mengembalikan error 400 yang pesannya diakhiri dengan block_binding: Extra inputs are not permitted. Model yang tidak menjalankan pemeriksaan prefiks menerima objek tersebut dan hanya melaporkan pembuangan dari pemeriksaan model, sehingga satu body permintaan berfungsi di berbagai model. Referensi API menyebut pemeriksaan prefiks sebagai pemeriksaan percakapan.

Permintaan berikut memilih untuk membuang alih-alih menolak. Pada giliran pertama tidak ada yang perlu diputar ulang, sehingga input_transformations kembali kosong:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
    betas=["thinking-binding-controls-2026-08-01"],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

print(f"Input transformations: {len(response.input_transformations or [])}")

The greatest common divisor of 1071 and 462 is 21.
Input transformations: 0

Dengan header beta, setiap respons dari model yang mampu berpikir membawa input_transformations. Setiap entri menyebutkan satu blok pemikiran berdasarkan path-nya (misalnya messages.1.content.0) dan memberikan reason. Ada dua jenis entri:

• thinking_dropped: API membuang blok sebelum model membacanya, dan blok tersebut tidak ditagih. reason-nya adalah prefix_binding_mismatch atau model_binding_mismatch (lihat Beralih model di tengah percakapan). reason juga dapat berupa organization_binding_mismatch, yang berarti blok tersebut berasal dari akun lain (lihat Blok pemikiran tetap berada di akun yang menghasilkannya).
• thinking_mismatch_allowed: blok gagal dalam pemeriksaan prefiks, tetapi API tidak memberlakukan pemeriksaan tersebut untuk permintaan ini, sehingga blok mencapai model tanpa perubahan dan ditagih. reason-nya selalu prefix_binding_mismatch. Entri ini hanya muncul pada permintaan di mana API tidak memberlakukan pemeriksaan secara default, seperti permintaan dari akun yang lebih lama (lihat Kapan API memberlakukan pemeriksaan). Menetapkan prefix_mismatch_behavior ke salah satu nilai membuat permintaan ikut dalam pemberlakuan, sehingga permintaan yang menetapkannya tidak pernah mendapatkan entri ini.

Array kosong ketika tidak ada blok yang dibuang dan tidak ada yang gagal dalam pemeriksaan prefiks. Abaikan entri yang type atau reason-nya tidak Anda kenali, karena pemeriksaan di masa mendatang akan menambahkan nilai.

Saat streaming, array tiba pada objek message dalam event message_start. Setelah fallback sisi server di tengah stream, event message_delta terakhir membawanya lagi dengan entri dari model yang melayani. Dalam message batch, item yang bloknya gagal dalam pemeriksaan prefiks dengan "error" eksplisit diselesaikan sebagai errored. Item yang tidak menetapkan field tersebut tidak gagal. Di mana API memberlakukan pemeriksaan secara default, API membuang blok yang gagal sebagai gantinya. Endpoint penghitungan token menjalankan pemeriksaan prefiks yang sama dan mengembalikan 400 yang sama.

Kapan API memberlakukan pemeriksaan

API memberlakukan pemeriksaan prefiks pada Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, dan Claude Haiku 5.5 untuk akun baru.

• Akun yang dibuat pada atau setelah 31 Agustus 2026, 00:00 UTC: API memeriksa permintaan Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, dan Claude Haiku 5.5 dan menerapkan "error" kecuali Anda menetapkan "drop_block". Definisi akun baru yang sama berlaku untuk Claude API dan platform cloud.
• Akun yang lebih lama: API memberlakukan pemeriksaan hanya pada permintaan yang menetapkan prefix_mismatch_behavior. Menetapkan field tersebut membuat permintaan ikut serta, sehingga Anda dapat melihat apa yang dilihat akun baru tanpa membuatnya. Pada permintaan yang tidak menetapkannya, API tetap menjalankan pemeriksaan tetapi membiarkan blok yang gagal diteruskan ke model. Dengan header beta, respons mencantumkan masing-masing blok tersebut dalam input_transformations sebagai thinking_mismatch_allowed, sehingga Anda dapat menemukan edit prefiks tanpa mengubah apa yang diterima model.

Untuk mengetahui grup mana akun Anda berada, ambil percakapan Claude Fable 5.1 yang berisi blok pemikiran, ubah sesuatu sebelum blok tersebut, dan kirimkan ke Claude Fable 5.1 tanpa header beta atau field block_binding. Respons 400 yang menyebutkan header berarti pemeriksaan diberlakukan secara default pada akun Anda. Respons 200 berarti tidak. Untuk memastikan, kirim permintaan yang sama lagi dengan header beta, tetap tanpa block_binding: respons mencantumkan setiap blok pemikiran setelah edit Anda dalam input_transformations sebagai thinking_mismatch_allowed.

Apa yang dihitung sebagai edit

Setiap baris membandingkan dua permintaan yang berurutan:

Periksa apakah kode Anda mengedit prefiks

Pertama, bandingkan apa yang Anda kirim. Rekam body permintaan yang dikirim integrasi Anda selama beberapa giliran normal, termasuk compaction atau perubahan alat. Untuk setiap pasangan permintaan berturut-turut, bandingkan system, tools, dan messages yang sama-sama dimiliki keduanya. Semuanya harus identik hingga giliran yang baru ditambahkan.

Kemudian konfirmasikan dengan API. Tambahkan header beta thinking-binding-controls-2026-08-01, tetapkan prefix_mismatch_behavior ke "drop_block", dan jalankan sesi multi-giliran normal melalui integrasi Anda pada claude-fable-5-1. Contoh berikut menjalankan dua giliran sebagaimana seharusnya integrasi Anda: messages hanya bertambah, setiap giliran asisten dikirim kembali persis seperti yang dikembalikan API, termasuk blok thinking, dan block_binding ditetapkan pada setiap permintaan. Setelah setiap giliran, contoh ini mencetak jumlah blok thinking dalam respons dan jumlah blok yang dibuang:

client = anthropic.Anthropic()

user_turns = [
    "How many positive integers below 500 have exactly 6 positive divisors?",
    "How many of those are odd?",
]

# messages bertambah di setiap giliran: tiap giliran assistant dikirim kembali persis seperti yang dikembalikan
messages = []
for user_turn in user_turns:
    messages.append({"role": "user", "content": user_turn})
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        thinking={
            "type": "adaptive",
            "block_binding": {"prefix_mismatch_behavior": "drop_block"},
        },
        messages=messages,
        betas=["thinking-binding-controls-2026-08-01"],
    )
    messages.append({"role": "assistant", "content": response.content})
    thinking_blocks = sum(block.type == "thinking" for block in response.content)
    dropped = len(response.input_transformations or [])
    print(f"thinking blocks: {thinking_blocks}, dropped: {dropped}")

thinking blocks: 1, dropped: 0
thinking blocks: 1, dropped: 0

Tidak ada giliran yang membuang blok karena tidak ada yang berubah sebelumnya. Periksa bahwa respons pertama berisi blok thinking. Dengan "adaptive thinking" (pemikiran adaptif), beberapa respons tidak memilikinya. Jika tidak ada respons dalam sesi yang memilikinya, tidak ada yang perlu diperiksa dan jumlah yang dibuang adalah 0 apa pun yang Anda ubah, jadi jalankan contoh tersebut lagi.

Catat input_transformations pada setiap giliran integrasi Anda sendiri. Ketika API membuang sebuah blok, entrinya terlihat seperti berikut:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

• Kosong pada setiap giliran sesi yang berisi blok thinking: integrasi Anda menjaga prefiks tetap utuh.
• reason: "prefix_binding_mismatch": sesuatu sebelum blok di path berubah sejak permintaan sebelumnya. Bandingkan system, tools, dan messages hingga giliran tersebut untuk menemukannya, atau kirim ulang permintaan dengan "error": 400 biasanya diakhiri dengan kalimat yang menyebutkan apa yang berubah. Kemudian temukan pengganti yang sesuai di Melakukan perubahan tanpa mengedit prefiks.
• reason: "model_binding_mismatch": percakapan berpindah ke model yang tidak dapat membaca blok model sebelumnya. Ini bukan edit prefiks. Lihat Beralih model di tengah percakapan.
• reason: "organization_binding_mismatch": blok berasal dari akun lain. Lihat Blok pemikiran tetap berada di akun yang menghasilkannya.

Untuk melihat kegagalan secara sengaja, kirim giliran ketiga dari contoh sebelumnya dan tambahkan prompt system hanya ke permintaan tersebut, sehingga berbeda dari dua permintaan pertama, yang tidak memilikinya. Dengan "drop_block", jumlah yang dibuang tidak lagi 0: respons memiliki satu entri untuk setiap blok pemikiran dalam riwayat, masing-masing dengan reason: "prefix_binding_mismatch". Dengan "error", permintaan mengembalikan 400 yang dijelaskan di Apa yang dilakukan API dengan blok yang tidak valid, dan kalimat terakhirnya menyebutkan prompt system. Di tab cURL dan "command-line interface" (antarmuka baris perintah), atau CLI, hapus filter jq untuk melihat body error. Jika jumlahnya masih 0, tidak ada yang perlu diperiksa: pastikan bahwa modelnya adalah claude-fable-5-1, bahwa permintaan menetapkan block_binding, bahwa riwayat yang Anda kirim berisi blok thinking, dan bahwa dua permintaan pertama tidak memiliki prompt system.

Dua giliran biasa jarang menunjukkan masalah. Jalankan sesi melalui masing-masing hal berikut, dengan "error" ditetapkan sehingga regresi menggagalkan "continuous integration" (integrasi berkelanjutan), atau CI, Anda:

• Compaction atau pemangkasan sisi klien pertama
• Alat, plugin, atau server MCP yang terhubung setelah giliran pertama
• Perubahan mode atau instruksi
• Loop alat yang panjang, jika Anda menambahkan pengingat atau memperpendek hasil alat lama
• Peralihan ke model lain dan kembali
• Penyimpanan, restart, dan melanjutkan pada tanggal berikutnya

Pada akun yang lebih lama, Anda juga dapat memantau lalu lintas produksi tanpa ikut serta dalam pemberlakuan: kirim header beta, jangan sertakan block_binding, dan catat input_transformations. Mengirim header saja tidak mengubah apa yang diterima model. Setiap blok pemikiran yang datang setelah konten yang Anda edit gagal dalam pemeriksaan dan mendapatkan entri thinking_mismatch_allowed sendiri, dengan field path dan reason yang sama seperti entri thinking_dropped. Blok sebelum edit tetap lolos. Edit pada system atau tools datang sebelum setiap blok, sehingga menggagalkan setiap blok pemikiran dalam permintaan. Satu entri terlihat seperti ini:

{
  "input_transformations": [
    {
      "type": "thinking_mismatch_allowed",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

Jalankan contoh berikut dari akun yang lebih lama, karena akun yang lebih baru menolak permintaan ketiganya dengan 400. Contoh ini mengirim header tanpa block_binding dan memperluas sesi sebelumnya dengan permintaan ketiga yang menambahkan prompt sistem, yang mengubah prefiks secara sengaja. Setelah setiap giliran, contoh ini mencetak jumlah blok thinking dan blok yang ditandai:

client = anthropic.Anthropic()

user_turns = [
    "How many positive integers below 500 have exactly 6 positive divisors?",
    "How many of those are odd?",
    "And how many of the odd ones are below 100?",
]

# messages bertambah di setiap giliran: tiap giliran assistant dikirim kembali persis seperti yang dikembalikan
messages = []
for turn, user_turn in enumerate(user_turns, start=1):
    messages.append({"role": "user", "content": user_turn})
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        thinking={"type": "adaptive"},
        # Hanya permintaan terakhir yang menambahkan prompt sistem, yang sengaja mengubah prefiks
        system="Answer briefly." if turn == len(user_turns) else anthropic.omit,
        messages=messages,
        betas=["thinking-binding-controls-2026-08-01"],
    )
    messages.append({"role": "assistant", "content": response.content})
    thinking_blocks = sum(block.type == "thinking" for block in response.content)
    flagged = sum(
        transformation.type == "thinking_mismatch_allowed"
        for transformation in response.input_transformations or []
    )
    print(f"thinking blocks: {thinking_blocks}, flagged: {flagged}")

thinking blocks: 1, flagged: 0
thinking blocks: 1, flagged: 0
thinking blocks: 1, flagged: 2

Respons ketiga menandai setiap blok pemikiran dari giliran sebelumnya, satu per giliran dalam proses ini, karena prompt sistem baru datang sebelum semuanya. Model tetap membacanya.

Tangani entri ini seperti Anda menangani pembuangan prefix_binding_mismatch. Edit berada sebelum blok pertama yang tercantum: bandingkan system, tools, dan messages hingga path blok tersebut dengan permintaan sebelumnya untuk menemukannya, lalu ganti dengan pola yang sesuai di Melakukan perubahan tanpa mengedit prefiks. Pada akun baru, atau pada permintaan apa pun yang menetapkan prefix_mismatch_behavior, API sebaliknya menolak permintaan atau membuang blok yang gagal. Entri-entri tersebut adalah batas bawah dari apa yang akan dihapus oleh pemberlakuan: dengan "drop_block", blok yang gagal juga ikut membuang sisa blok pemikiran pada giliran tersebut, dan menghapus satu blok dapat membuat blok berikutnya juga gagal. Ketika API hanya mencatat pemeriksaan, API menilai setiap blok secara terpisah dan mencantumkan sebuah blok hanya jika blok tersebut gagal.

Melakukan perubahan tanpa mengedit prefiks

Setiap edit prefiks yang umum memiliki pengganti yang memberikan informasi yang sama kepada model dan membiarkan byte sebelumnya tidak berubah, sehingga pemikiran berikutnya tetap valid. Temukan edit yang dilakukan kode Anda saat ini di kolom pertama:

Semua ini mengasumsikan Anda mengirim kembali giliran asisten persis seperti yang dikembalikan. Pesan sistem di tengah percakapan, pesan sistem berlingkup giliran, dan perubahan alat tidak tersedia di setiap model: Pesan sistem dan perubahan alat di tengah percakapan mencantumkan model yang menerimanya. Jika kode Anda melayani beberapa model, tetap edit prompt system tingkat atas untuk model yang tidak menerimanya.

Untuk menggunakan beberapa beta dalam satu permintaan di Claude API, gabungkan namanya dalam satu header anthropic-beta:

anthropic-beta: thinking-binding-controls-2026-08-01,mid-conversation-system-clear-at-2026-08-21,inline-tools-2026-09-15

Platform lain yang menawarkan beta ini menggunakan nama yang sama. Untuk mengirimkannya di sana, lihat Fitur beta di platform lain.

Kirim kembali giliran asisten persis seperti yang dikembalikan

Simpan array content dari setiap respons dan kirim kembali tanpa perubahan sebagai giliran asisten: setiap jenis blok, dalam urutan yang diterima, termasuk blok thinking yang field thinking-nya kosong. Serializer yang membuang jenis blok yang tidak dikenal, membuang field kosong, atau mengurutkan ulang blok akan mengedit prefiks untuk setiap giliran berikutnya.

Pada Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5, dan Claude Haiku 5.5, field thinking kosong secara default dan signature membawa penalaran, sehingga serializer yang melewati blok kosong akan menghapus pemikiran. Jika serializer menghapus semuanya, tidak ada yang gagal dan model kehilangan penalaran sebelumnya pada setiap giliran. Jika Anda mem-parsing stream sendiri, pertahankan blok tersebut bahkan ketika tidak ada teks pemikiran yang tiba: blok terbuka, menerima signature-nya dalam event signature_delta, dan tertutup. Blok yang dikirim kembali dengan signature kosong akan gagal.

Menambahkan instruksi dengan pesan sistem di tengah percakapan

Beberapa harness menyusun ulang prompt system tingkat atas pada setiap permintaan untuk membawa waktu saat ini, anggaran token, flag mode, atau konteks proyek yang baru ditemukan. Hal itu membuat setiap blok pemikiran dalam percakapan menjadi tidak valid. Sebagai gantinya, bekukan system di awal sesi. Ketika sesuatu berubah, tambahkan pesan role: "system" pada titik di messages tempat perubahan tersebut mulai berlaku:

{
  "role": "system",
  "content": "The user switched the workspace to read-only mode. Do not write files until told otherwise."
}

Model memperlakukan pesan ini dengan otoritas prompt sistem, dan semua yang ada sebelumnya tetap tidak berubah. Dalam loop alat, tempatkan pesan setelah pesan pengguna tool_result, jangan pernah di antara tool_use asisten dan tool_result-nya (lihat Batasan). Setelah dikirim, pesan tersebut menjadi bagian dari prefiks untuk pemikiran berikutnya: biarkan di tempatnya pada permintaan berikutnya.

Menaruh konteks yang berubah di giliran terbaru

Beberapa harness menaruh blok lingkungan di pesan pengguna pertama (direktori kerja, branch, tanggal, memori, instruksi proyek) dan merendernya lagi pada setiap permintaan. Ketika nilai apa pun berubah, messages[0] berubah, dan setiap blok pemikiran dalam percakapan menjadi tidak valid. Render blok tersebut sekali dan kirim ulang apa adanya. Ketika sebuah nilai berubah, sampaikan di giliran terbaru: tambahkan blok teks ke pesan pengguna yang akan Anda kirim, atau tambahkan pesan sistem di tengah percakapan jika perubahan tersebut berasal dari Anda sebagai operator.

{
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "Environment update: the current branch is now release-2."
    },
    { "type": "text", "text": "Run the tests again." }
  ]
}

Setelah dikirim, blok teks tersebut menjadi bagian dari prefiks untuk pemikiran berikutnya: biarkan di tempatnya pada permintaan berikutnya.

Kirim pengingat per giliran sebagai pesan sistem bercakupan giliran

Edit prefiks yang umum adalah dorongan per giliran: baris seperti "request independent reads together" atau "you haven't updated the user in a while" yang ditambahkan kode Anda setelah setiap batch hasil alat. Agar pengingat tidak menumpuk, kirim setiap dorongan sebagai pesan sistem di tengah percakapan dengan clear_at: "next_user_message", yang ditempatkan setelah pesan pengguna tool_result. clear_at memerlukan header beta mid-conversation-system-clear-at-2026-08-21. Array messages berikut adalah permintaan setelah dua panggilan alat beserta hasilnya. messages[3] adalah dorongan dari permintaan sebelumnya, yang dibiarkan di tempatnya, dan messages[6] adalah salinan untuk permintaan ini:

[
  { "role": "user", "content": "Fix the failing test." },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_01",
        "name": "read_file",
        "input": { "path": "tests/test_auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_01", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_02",
        "name": "read_file",
        "input": { "path": "src/auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_02", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  }
]

Pesan pengguna yang hanya berisi blok tool_result dihitung sebagai "next user message", sehingga messages[3] sudah dibersihkan. Pesan tersebut tidak menambahkan apa pun pada apa yang dilihat model dan tidak memakan token input, tetapi karena masih ada dalam array, pemikiran di messages[4] tetap valid. messages[6] adalah salinan yang dilihat model pada giliran ini. Pada permintaan berikutnya, pertahankan keduanya di tempatnya dan tambahkan salinan baru setelah pesan tool_result berikutnya.

Menambahkan atau menghapus alat dengan tool_addition dan tool_removal

Mengedit array tools di tengah sesi membuat blok pemikiran yang dipertahankan menjadi tidak valid. Biarkan array tersebut seperti saat pertama kali Anda mengirimkannya. Untuk mengubah alat yang dapat digunakan model, tambahkan pesan role: "system" yang membawa blok tool_addition atau tool_removal. Ini adalah perubahan alat di tengah percakapan dan memerlukan header beta inline-tools-2026-09-15, yang tersedia di Claude API. Header lama mid-conversation-tool-changes-2026-07-01 masih berfungsi untuk perubahan yang menyebut alat berdasarkan referensi, di Claude API, Amazon Bedrock, dan Google Cloud.

Anda memiliki dua cara untuk menggunakan blok-blok ini:

• Deklarasikan setiap alat di awal. Taruh setiap alat yang mungkin dibutuhkan sesi di tools pada permintaan pertama, dengan defer_loading: true pada alat yang belum boleh dilihat model. Kemudian aktifkan dan nonaktifkan alat dengan blok tool_addition dan tool_removal yang menyebutkan namanya.
• Mulai dengan snapshot dan tambahkan alat seiring berjalannya sesi. Taruh alat yang Anda ketahui di tools pada permintaan pertama. Ketika alat baru muncul, definisikan alat tersebut di dalam blok tool_addition alih-alih mengedit tools.

Dengan cara mana pun, tools tidak pernah berubah, sehingga pemikiran sebelumnya tetap valid dan cache prompt tetap hit, dengan satu pengecualian yang dijelaskan nanti di bagian ini.

Misalnya, untuk menarik alat berbahaya setelah peralihan mode:

{
  "role": "system",
  "content": [
    { "type": "tool_removal", "tool": { "type": "tool_reference", "name": "delete_branch" } },
    { "type": "text", "text": "Branch deletion is disabled for the rest of this session." }
  ]
}

Untuk mengaktifkan alat yang Anda deklarasikan dengan defer_loading: true, tambahkan blok tool_addition yang menyebutkan namanya:

{
  "role": "system",
  "content": [
    { "type": "tool_addition", "tool": { "type": "tool_reference", "name": "deploy" } },
    { "type": "text", "text": "Authentication succeeded. Deployment is now available." }
  ]
}

Terkadang Anda tidak dapat mendeklarasikan alat di awal karena Anda belum mengetahui skemanya: alat yang ditemukan aplikasi Anda saat runtime, atau server MCP yang terhubung setelah giliran pertama. Definisikan alat tersebut di dalam blok tool_addition alih-alih menyentuh tools. Dengan inline-tools-2026-09-15, tool pada blok dapat berupa {"type": "tool_definition", "definition": {...}}, yang membawa entri yang sama dengan yang akan Anda taruh di tools:

{
  "role": "system",
  "content": [
    {
      "type": "tool_addition",
      "tool": {
        "type": "tool_definition",
        "definition": {
          "name": "db_query",
          "description": "Run a read-only SQL query against the analytics database.",
          "input_schema": {
            "type": "object",
            "properties": { "sql": { "type": "string" } },
            "required": ["sql"]
          }
        }
      }
    }
  ]
}

Alat baru tiba di messages, tools tidak pernah berubah, dan pemikiran sebelumnya tetap valid. Pertahankan setidaknya satu alat tanpa defer_loading: true di tools: jika setiap alat di sana ditangguhkan, alat pertama yang Anda definisikan dengan cara ini akan menyebabkan satu cache miss prompt penuh.

Jika API terhubung ke server MCP untuk Anda melalui konektor MCP, kirim juga mcp-client-2026-09-15. Header ini mencakup semua yang dilakukan mcp-client-2025-11-20, jadi kirimkan header ini sebagai pengganti header tersebut. definition pada blok kemudian dapat berupa mcp_toolset untuk server yang tercantum di mcp_servers. Ketika API harus mengambil daftar alat sebuah server, respons dimulai dengan blok mcp_tool_listing untuk server tersebut. Kirim kembali blok itu tanpa perubahan bersama sisa giliran asisten, dan tetap kirim mcp-client-2026-09-15 pada setiap permintaan berikutnya yang membawanya. Blok tersebut mengunci toolset ke daftar itu, sehingga API tidak menghubungi server lagi untuk toolset tersebut. Fitur konektor MCP ini tersedia di Claude API.

Dengan hanya header yang lebih lama, Anda masih dapat menambahkan alat yang Anda ketahui di tengah sesi ke tools dengan defer_loading: true, lalu menawarkannya dengan blok tool_addition. Itu aman karena pemeriksaan prefiks mengabaikan alat yang ditangguhkan hingga blok tool_addition mereferensikannya. Menambahkan alat tanpa defer_loading: true mengubah prefiks dan membuat pemikiran sebelumnya tidak valid.

Pesan role: "system" yang membawa blok-blok ini menjadi bagian dari prefiks untuk pemikiran berikutnya. Biarkan pesan tersebut di tempatnya pada permintaan berikutnya.

Ubah effort dengan output_config per pesan

Mengubah output_config.effort tingkat atas di antara permintaan tidak membuat pemikiran menjadi tidak valid, karena effort bukan bagian dari prefiks. Namun, mengubah effort tingkat atas memang memulai ulang cache prompt. Jika model dan platform mendukung effort per pesan, gunakan itu sebagai gantinya: tambahkan pesan role: "system" dengan content kosong dan level yang baru. Ini memerlukan header beta mid-conversation-output-config-2026-07-01. Pada Claude Haiku 5.5, effort per pesan tersedia di Claude API dan Google Cloud serta memerlukan pemikiran adaptif.

{ "role": "system", "content": [], "output_config": { "effort": "low" } }

Kapan level baru mulai berlaku bergantung pada tempat Anda meletakkan pesan tersebut. Tepat setelah pesan user dengan input baru, level baru dimulai dengan balasan Claude terhadap pesan itu. Di tempat lain, seperti setelah pesan assistant atau setelah pesan user yang hanya berisi blok tool_result, level baru dimulai dengan pesan user berikutnya yang berisi input baru, sehingga loop alat yang sedang berjalan tetap menggunakan level saat ini sampai saat itu. Setelah dikirim, pesan tersebut menjadi bagian dari messages dan karenanya bagian dari prefiks untuk pemikiran berikutnya: biarkan tetap di tempatnya pada permintaan-permintaan selanjutnya, dan tambahkan pesan lain untuk mengubah effort lagi.

Memangkas konteks di server

Edit prefiks umum lainnya adalah pemangkasan sisi klien: membuang atau meringkas giliran terlama dan mempertahankan giliran terbaru secara verbatim. Blok pemikiran dari giliran yang dipertahankan dihasilkan saat riwayat yang dihapus masih ada, sehingga blok tersebut gagal dalam pemeriksaan. Padanan sisi server tidak dihitung sebagai edit, karena pemeriksaan membandingkan percakapan sebagaimana yang Anda kirim:

• Compaction sesuai permintaan (beta) mengembalikan ringkasan dari permintaan terpisah, yang dapat berjalan di latar belakang. Anda lalu mengirim blok yang dikembalikan sebagai pengganti pesan-pesan yang diringkasnya. Pemeriksaan menerima penggantian tersebut, sehingga giliran yang Anda pertahankan dapat tetap valid beserta pemikirannya, selama memenuhi syarat agar pemikiran yang disimpan tetap valid. Meminta ringkasan menunjukkan permintaannya dan menyebutkan header beta yang diperlukan.
• Compaction pada ambang batas token meringkas giliran lama menjadi blok compaction saat konteks mendekati ambang yang Anda tetapkan. Prefiks yang diperiksa kemudian dimulai ulang dari blok tersebut. Parameter instructions miliknya menerima prompt peringkasan Anda sendiri, seperti "pertahankan setiap ticker, ukuran posisi, dan asumsi yang dinyatakan".
• Pengeditan konteks menghapus hasil alat lama atau blok pemikiran lama berdasarkan aturan, dimulai dari yang paling lama. Strateginya adalah clear_tool_uses_20250919 dan clear_thinking_20251015.

Lakukan compaction di sisi klien

Anda tetap dapat melakukan compaction di klien. Jika Anda menulis ringkasannya sendiri, jangan kirim kembali blok thinking yang dihasilkan sebelum penulisan ulang. Jika API yang menulisnya dengan compaction sesuai permintaan, Syarat agar pemikiran yang disimpan tetap valid menjelaskan kapan thinking yang dipertahankan tetap valid.

Compaction sederhana (direkomendasikan)

Ketika percakapan menjadi terlalu panjang, ringkas seluruh sesi menjadi satu pesan pengguna dan kirim hanya pesan tersebut ditambah instruksi berikutnya. Tidak ada yang diputar ulang dari sebelumnya, sehingga tidak ada thinking yang tersisa untuk gagal dalam pemeriksaan, dan model bernalar dari awal berdasarkan ringkasan.

[
  {
    "role": "user",
    "content": "<summary of the session so far>\n\n<the next instruction>"
  }
]

Model Claude dilatih pada tugas jangka panjang dengan skema ini dan untuk sebagian besar beban kerja, skema ini berkinerja baik.

Compaction keep-tail

Compaction keep-tail meringkas giliran-giliran lama dan mempertahankan giliran terbaru apa adanya, sehingga model tetap melihat beberapa pertukaran terakhir kata demi kata. Jika Anda menulis ringkasannya sendiri, hal ini melanggar aturan: giliran asisten yang dipertahankan masih membawa blok thinking yang dihasilkan ketika giliran aslinya, bukan ringkasannya, berada sebelum giliran tersebut. Blok-blok itu gagal.

Untuk mempertahankan thinking tersebut, minta API menulis ringkasannya dengan compaction sesuai permintaan. Compaction yang mempertahankan giliran terbaru menunjukkan caranya, dan Syarat agar thinking yang dipertahankan tetap valid mencantumkan kapan thinking yang dipertahankan tetap valid.

Sisa bagian ini membahas ringkasan yang Anda tulis sendiri.

Perbaikan: pertahankan giliran-giliran tersebut persis seperti adanya dan kirim prefix_mismatch_behavior: "drop_block". API membuang blok thinking yang usang, model membaca blok text dan tool_use dari giliran yang dipertahankan, dan permintaan berhasil.

Teruskan riwayat yang telah di-compact sebagai messages dan atur block_binding pada konfigurasi thinking. Dalam contoh berikut, compacted_messages adalah array yang dihasilkan oleh langkah compaction Anda: pesan ringkasan diikuti giliran yang dipertahankan persis seperti yang dikembalikan API, termasuk blok thinking:

client = anthropic.Anthropic()

# compacted_messages: pesan ringkasan, lalu giliran yang dipertahankan sesuai yang dikembalikan
response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=compacted_messages,
    betas=["thinking-binding-controls-2026-08-01"],
)

print(response.input_transformations)

Respons membawa giliran asisten baru seperti biasa, ditambah satu entri input_transformations per blok yang dibuang. Untuk riwayat dalam diagram, itu adalah thinking pada giliran asisten 3 dan 4:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.2.content.0",
      "reason": "prefix_binding_mismatch"
    },
    {
      "type": "thinking_dropped",
      "path": "messages.4.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

Terus kirim "drop_block" pada permintaan-permintaan berikutnya selama kedua giliran tersebut masih ada dalam riwayat. Thinking yang dihasilkan model mulai dari permintaan ini dan seterusnya mengikuti ringkasan dan tetap valid. Jika Anda lebih memilih untuk tidak bergantung pada header beta, alternatifnya adalah menghapus sendiri blok thinking dan redacted_thinking dari giliran asisten yang dipertahankan saat Anda membangun riwayat yang telah di-compact.

Compaction latar belakang (async)

Compaction latar belakang menyusun ringkasan di luar jalur kritis selagi percakapan berlanjut, lalu menggantikannya beberapa permintaan kemudian. Untuk mempertahankan thinking yang dihasilkan selama itu, biarkan API menulis ringkasannya dengan compaction sesuai permintaan. Compaction di latar belakang berisi langkah-langkahnya. Thinking tersebut tetap valid dengan syarat agar pemikiran yang disimpan tetap valid yang sama seperti giliran terbaru yang dipertahankan.

Ringkasan yang Anda bangun sendiri melanggar aturan dengan cara yang sama seperti keep-tail, hanya saja tertunda: setiap giliran asisten yang dihasilkan selama ringkasan sedang dibangun membawa thinking yang mendahului penukaran, dan semuanya gagal begitu ringkasan diterapkan. Jika Anda menggunakannya, perlakukan penukaran seperti keep-tail dan kirim "drop_block" sejak penukaran dan seterusnya, atau lakukan compaction secara sinkron.

Pola yang tidak berfungsi dengan preserved thinking

• Memotong giliran dari bagian tengah. Menghapus giliran individual membuat setiap blok thinking setelahnya menjadi tidak valid, dan tidak ada skema compaction yang dapat menghindarinya. Jika Anda memotong giliran untuk mengubah instruksi, tambahkan pesan sistem di tengah percakapan sebagai gantinya. Untuk menghapus hasil alat lama atau thinking lama secara selektif, gunakan pengeditan konteks di sisi server.
• Melakukan compaction di tengah putaran alat. Jangan lakukan compaction di antara tool_use pada giliran asisten dan tool_result yang menjawabnya. Kirim kembali giliran asisten tersebut dengan thinking-nya utuh agar model menyelesaikan putaran tersebut dengan penalarannya. Lihat Mempertahankan blok thinking.

Referensikan file berdasarkan ID, bukan berdasarkan URL yang kontennya berubah

Untuk blok image atau document dengan sumber url, pemeriksaan mencakup byte yang diambil, bukan string URL. URL yang kontennya berubah membuat thinking berikutnya tidak valid: misalnya endpoint "tangkapan layar terbaru", atau dokumen yang diedit seseorang di antara giliran. URL bertanda tangan yang berganti-ganti untuk file yang sama tidak menimbulkan masalah. Untuk konten yang Anda referensikan di beberapa giliran, unggah sekali dengan Files API dan gunakan file_id, atau kirim dalam base64.

Library, proxy, dan gateway

Library, proxy, atau gateway berada di antara riwayat milik pihak lain dan API, sehingga penulisan ulang yang dilakukannya dihitung sebagai edit, dan penggunanya tidak dapat melihat atau memperbaikinya.

• Teruskan apa yang tidak Anda kenali. Teruskan nilai anthropic-beta dan thinking.block_binding dari pemanggil tanpa perubahan, dan kembalikan input_transformations kepada mereka. Skema opsi yang menolak key yang tidak dikenal akan menghalangi pengguna Anda memilih "drop_block".
• Biarkan pesan role: "system" di tempat pemanggil meletakkannya. Memindahkannya ke field system tingkat atas akan mengubah system pada permintaan tersebut dan membuat setiap blok thinking dalam percakapan menjadi tidak valid.
• Untuk menonaktifkan penggunaan alat pada suatu permintaan, kirim tool_choice: {"type": "none"}. Jangan hapus tools.
• Jangan sembunyikan error 400. Jika kode Anda menangkapnya, menghapus thinking, dan mencoba ulang atas nama pemanggil, catat bahwa hal itu dilakukan: riwayat mereka tetap teredit, dan model kehilangan penalaran sebelumnya pada setiap permintaan berikutnya.

FAQ

Langkah selanjutnya