Claude Fable 5.1 ระบบความคิดที่เก็บรักษา: วิธีแก้ไข บล็อกถูกผูกกับบทสนทนาอื่น

หากคุณย้าย Agent harness ไปยัง Claude Fable 5.1 แล้วเริ่มเห็นข้อผิดพลาด 400 ที่มีข้อความระบุว่า thinking block “ผูกกับบทสนทนาอื่น” แสดงว่าโค้ดของคุณมีการแก้ไขประวัติการสนทนาระหว่างคำขอ และ Fable 5.1 เป็นโมเดล Claude แรกที่คัดค้านเรื่องนี้ คู่มือนี้จะอธิบายว่าการตรวจสอบนี้คืออะไร มีผลกับใคร อะไรเป็นสาเหตุให้เกิดข้อผิดพลาดนี้ วิธีแก้ไขชั่วคราว และรูปแบบ "append-only" ที่ทำให้ข้อผิดพลาดหายไปพร้อมกับช่วยรักษา prompt cache ของคุณให้ทำงานได้อย่างมีประสิทธิภาพ

การตรวจสอบนี้มีเอกสารอ้างอิงภายใต้หัวข้อ preserved thinking และใน มีอะไรใหม่ใน Claude Fable 5.1 เป็นการเปลี่ยนแปลงที่ส่งผลกระทบในสามข้อของ Fable 5.1 และเป็นเพียงข้อเดียวที่สามารถลดประสิทธิภาพของ harness ได้โดยไม่แจ้งให้ทราบ สำหรับอีกสองข้อ ดูได้ที่ คู่มือการย้ายระบบ

ข้อผิดพลาด

messages.5.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". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

นี่คือข้อผิดพลาด 400 invalid_request_error ซึ่งถูกตัดสินก่อนที่จะมีผลลัพธ์ใดๆ การลองส่งคำขอเดิมซ้ำจะล้มเหลวด้วยวิธีเดียวกัน. Path (messages.5.content.0) ชี้ไปที่ thinking block แรกที่ไม่ตรงกันอีกต่อไป และข้อความอาจมีประโยคเพิ่มเติมที่ระบุข้อความแรกที่มีการเปลี่ยนแปลง ซึ่งเป็นข้อมูลที่คุณต้องการใช้ในการวินิจฉัย Endpoint สำหรับการนับโทเค็นจะทำการตรวจสอบเดียวกันนี้

ความล้มเหลวแบบอื่นที่ดูคล้ายกันแต่ไม่ใช่กรณีนี้: ข้อความนำหน้าแบบเดียวกันแต่ไม่มีประโยคว่า “ผูกกับบทสนทนาอื่น” หมายความว่าตัวลายเซ็นถูกแก้ไขหรือถอดรหัสไม่ได้ และ prefix_mismatch_behavior จะไม่สามารถใช้ได้

การตรวจสอบนี้ทำอะไร

ทุก Fable 5.1 thinking block จะมีลายเซ็นที่บันทึกสองสิ่ง: โมเดลใดที่สร้างมันขึ้นมา และ conversation prefix ที่แน่นอนที่อยู่ข้างหน้ามัน ซึ่งหมายถึง system prompt ระดับบนสุด, tools array, และทุกข้อความก่อนหน้า block แต่ละ block ยังเชื่อมโยงกับ thinking block ก่อนหน้าด้วย เมื่อคุณส่งข้อความถอดเสียงกลับไป API จะตรวจสอบว่า prefix นั้นตรงกันแบบ byte-identical กับสิ่งที่สร้าง block นั้นขึ้นมา

Anthropic ให้เหตุผลสองประการ ประการแรกคือเพื่อป้องกันการบิดเบือนข้อมูล (anti-distillation): โพสต์เปิดตัวระบุว่าบัญชี API ใหม่จะไม่สามารถแก้ไขบริบทก่อนหน้าของ Claude ด้วยตนเองในการสนทนาแบบหลายเทิร์นได้อีกต่อไป ในขณะที่ยังคงรักษา transcript ของความคิดก่อนหน้า ซึ่งปิดช่องโหว่เทคนิคการบิดเบือนข้อมูลที่เคยมี การใช้งานจริงคือการแก้ไขที่ทำให้การตรวจสอบล้มเหลวยังทำให้ prompt cache เริ่มต้นใหม่ด้วย ดังนั้นโค้ดที่ผ่านการตรวจสอบยังเป็นโค้ดที่ได้รับการอ่าน cache ในราคา $0.25 ต่อล้านครั้งในทุกๆ เทิร์น

ใช้กับใครบ้าง

บังคับใช้โดยค่าเริ่มต้น: บัญชีที่สร้างขึ้นในหรือหลังวันที่ 31 สิงหาคม 2026 ซึ่งครอบคลุมองค์กรที่ใช้ Claude API, บัญชี Amazon Bedrock, โปรเจกต์ Google Cloud และทรัพยากร Microsoft Foundry

บันทึกไว้แต่ไม่บังคับใช้: บัญชีที่สร้างขึ้นก่อนหน้านี้ API จะบันทึกความไม่ตรงกันแต่จะดำเนินการกับมันก็ต่อเมื่อคำขอตั้งค่า thinking.block_binding.prefix_mismatch_behavior เป็นค่าใดค่าหนึ่ง รวมถึง "error" Anthropic ระบุว่าโมเดลในอนาคตจะบังคับใช้กับทุกคน

ไม่ได้รับผลกระทบ: Claude Code, claude.ai, Claude Managed Agents และ Claude Agent SDK ซึ่งจะรักษาส่วนนำหน้า (prefix) ให้คงอยู่ Claude Mythos 5.1 ไม่มีการตรวจสอบนี้เลย แม้ว่าการแก้ไขประวัติยังคงทำให้แคชของมันเริ่มต้นใหม่ก็ตาม

ได้รับผลกระทบ: โค้ดใดๆ ที่สร้าง messages array ด้วยตัวเอง ซึ่งได้แก่ทุก custom agent loop, ทุก chat backend และทุก framework ที่ครอบ Messages API

กับดักสำหรับผู้เขียนเครื่องมือ: หากคุณจัดส่งบางสิ่งที่ผู้คนใช้งานด้วยคีย์ API ของตนเอง คีย์ของคุณอาจอยู่ในบัญชีเก่ากว่าและของพวกเขาอาจไม่ใช่ ทดสอบโดยตั้งค่าฟิลด์เพื่อให้คุณพบการตรวจสอบก่อนที่ผู้ใช้ของคุณจะพบ เพื่อตรวจสอบว่าบัญชีของคุณถูกบังคับใช้หรือไม่ ให้ส่งคำขอที่แก้ไขประวัติโดยไม่มี beta header; หากมีข้อผิดพลาด 400 ที่ระบุ header นั่นหมายความว่ามีการบังคับใช้

อะไรที่ทำให้ thinking block หลังจากนั้นใช้ไม่ได้

• การแก้ไข, จัดลำดับใหม่, หรือลบเทิร์นก่อนหน้า ซึ่งรวมถึงการลบผลลัพธ์ของเครื่องมือเก่า การตัดเทิร์นจากกลาง transcript และการบีบอัดข้อมูลฝั่งไคลเอ็นต์ที่คงเทิร์นล่าสุดไว้ตามเดิมหลังข้อมูลสรุป
• การแทรกเนื้อหาที่คุณไม่ได้เก็บไว้ การแจ้งเตือนต่อเทิร์นที่ถูกเพิ่มหลังผลลัพธ์ของเครื่องมือและถูกลบออกในการร้องขอครั้งถัดไป แถบสถานะ จำนวนโทเค็นที่เหลือซึ่งเปลี่ยนแปลงในแต่ละเทิร์น
• การสร้าง system หรือ tools ใหม่ระหว่างคำขอ การอัปเดตวันที่ปัจจุบันใน system prompt การเพิ่มหรือลบเครื่องมือระหว่างเซสชัน
• URL รูปภาพหรือเอกสารที่ส่งคืนไบต์ที่แตกต่างกันในภายหลัง ไบต์นั้นถูกผูกไว้ ไม่ใช่สตริง URL ดังนั้น URL ที่มีการลงนามแบบหมุนเวียนสำหรับไฟล์เดียวกันจึงไม่มีปัญหา
• การลบ thinking block จากตำแหน่งอื่นที่ไม่ใช่จุดเริ่มต้นของการรัน block ที่นำหน้าสามารถลบได้ โดยเริ่มจาก block ที่เก่าที่สุด block จากตรงกลางไม่สามารถลบได้

อะไรที่ทำให้มันยังคงใช้ได้

• ประวัติแบบ "append-only" ซึ่งรวมถึงข้อความ role: "system" ที่ถูกเพิ่มเข้าไป และข้อความแบบ turn-scoped ที่ถูกล้างแต่ยังคงอยู่ในตำแหน่งเดิม
• การลบ thinking blocks ที่นำหน้า โดยเริ่มจากบล็อกที่เก่าที่สุด
• การเปลี่ยนพารามิเตอร์ใดๆ นอกเหนือจาก system, tools และ messages: เช่น max_tokens, output_config รวมถึง effort, tool_choice, metadata
• การเพิ่ม, ย้าย, หรือลบ cache_control markers
• การบีบอัดข้อมูลฝั่งเซิร์ฟเวอร์และการแก้ไขบริบท รวมถึงการล้าง thinking-block สิ่งเหล่านี้ไม่ถือเป็นการแก้ไขเนื่องจากการตรวจสอบจะเปรียบเทียบการสนทนาตามที่คุณส่ง ไม่ใช่สำเนาที่เซิร์ฟเวอร์แก้ไข หลังจากบีบอัดแล้ว prefix ที่ตรวจสอบจะเริ่มจาก compaction block

ช่องทางฉุกเฉิน: drop_block

ส่ง thinking-binding-controls-2026-08-01 beta header และตั้งค่าฟิลด์อย่างชัดเจน:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

เมื่อใช้ "drop_block", API จะละทิ้ง block ที่ไม่ตรงกันแรกสุดและทุก thinking block ที่ตามมา ดำเนินการตามคำขอ และรายงานการละทิ้งแต่ละครั้งใน input_transformations array ระดับบนสุด:

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

สามสิ่งที่คุณควรรู้เกี่ยวกับฟิลด์นี้: มันมีผลเฉพาะกับคำขอนั้นๆ เท่านั้น ดังนั้นให้ส่งมันต่อไปตลอดเซสชัน ค่าเริ่มต้นจะแตกต่างกันไปตามพื้นผิวการใช้งาน: หากไม่มี header บัญชีที่มีการบังคับใช้จะเกิดข้อผิดพลาด; การส่ง header เพียงอย่างเดียวจะเปลี่ยนไปใช้ค่าเริ่มต้นของเบต้า ซึ่งคือ drop_block; ดังนั้นควรกำหนดค่าอย่างชัดเจนและอย่าพึ่งพาค่าเริ่มต้นใดๆ และการส่ง block_binding โดยไม่มี header จะทำให้เกิดข้อผิดพลาด 400 ที่ระบุว่า block_binding: Extra inputs are not permitted

ฟิลด์ reason แยกความแตกต่างได้สองกรณี: prefix_binding_mismatch หมายความว่าประวัติของคุณมีการเปลี่ยนแปลง ส่วน model_binding_mismatch หมายความว่าการสนทนาเปลี่ยนโมเดล (เช่น router, การลองใหม่, การปฏิเสธสำรอง) และเป้าหมายไม่สามารถอ่าน Fable 5.1 block ได้ กรณีที่สองไม่ใช่ข้อบกพร่องในโค้ดของคุณ เมื่อมี header ทุกคำตอบจะมีการส่ง array นี้ไปด้วย ซึ่งจะว่างเปล่าหากไม่มีการละทิ้งสิ่งใด

การละทิ้ง blocks เพียงครั้งเดียวที่ขอบเขตการบีบอัดข้อมูลมีค่าใช้จ่ายน้อย แต่ harness ที่ทำให้ประวัติของตัวเองไม่ถูกต้องในทุกคำขอจะทำให้สูญเสียการใช้เหตุผลของโมเดลในทุกเทิร์นและเริ่มต้น prompt cache ใหม่ในทุกเทิร์น ซึ่ง Anthropic เตือนว่าสิ่งนี้จะเพิ่มค่าใช้จ่ายต่อภารกิจ พิจารณา drop_block เป็นเครื่องมือวินิจฉัยและตาข่ายนิรภัย ไม่ใช่สถานะคงที่

การกู้คืนโดยไม่มีเบต้า

บนแพลตฟอร์มที่ไม่มีตัวควบคุม (Microsoft Foundry ไม่ได้เสนอตัวควบคุมเหล่านี้เมื่อเปิดตัว; Bedrock และ Google Cloud กำลังเพิ่มตามโมเดล) ให้ลบ thinking และ redacted_thinking block ทั้งหมดออกจากประวัติ เก็บเฉพาะ text และ tool_use block ของแต่ละเทิร์นไว้ แล้วลองใหม่หนึ่งครั้ง โมเดลจะตอบกลับเทิร์นนั้นโดยไม่มีการใช้เหตุผลที่ block เหล่านั้นมีอยู่ นี่เป็นการกู้คืนแบบครั้งเดียว ไม่ใช่รูปแบบการใช้งานปกติ

การตรวจสอบสามขั้นตอน

ดำเนินการนี้ก่อนที่คุณจะเปลี่ยนทราฟฟิก ไม่ใช่หลังจากนั้น

1. บันทึกเนื้อหาคำขอที่แน่นอน ที่ harness ของคุณส่งไปในการสนทนาปกติไม่กี่เทิร์น รวมถึงการบีบอัดหรือการเปลี่ยนเครื่องมือ หากผลิตภัณฑ์ของคุณมี สำหรับแต่ละคู่ของคำขอที่ต่อเนื่องกัน ให้เปรียบเทียบ system prompt, tools array และ prefix ที่ใช้ร่วมกันของ messages สิ่งเหล่านี้ควรเป็น byte-identical จนถึงเทิร์นที่ถูกเพิ่มเข้ามาใหม่
2. รันเซสชันแบบ multi-turn ปกติ กับ claude-fable-5-1 โดยมี beta header และ prefix_mismatch_behavior: "drop_block" พร้อมบันทึก input_transformations ในทุกการตอบกลับ หาก array ว่างเปล่าในทุกเทิร์นหมายความว่าประวัติยังคงสมบูรณ์อยู่ หากมี prefix_binding_mismatch entry หมายความว่ามีบางสิ่งก่อนหน้า block ที่ path มีการเปลี่ยนแปลง วิธีนี้ใช้ได้กับบัญชีใดก็ได้ เพราะการตั้งค่าฟิลด์นี้จะทำให้คำขอถูกบังคับใช้ ใน CI ให้ตั้งค่าเป็น "error" แทนเพื่อให้การแก้ไขทำให้การรันล้มเหลว
3. เลือกการตั้งค่าการผลิตและกำหนดค่าอย่างชัดเจน ภายใต้ header: "error" หากความไม่ตรงกันหมายถึงข้อบกพร่องเท่านั้น หรือ "drop_block" เพื่อให้ประสิทธิภาพลดลงแทนที่จะล้มเหลว ตรวจสอบ 400s หรือ input_transformations entries ไม่ว่ากรณีใดๆ อย่าปล่อยฟิลด์ว่างไว้ในบัญชีเก่า เพราะการตรวจสอบจะบันทึกเฉพาะฝั่งเซิร์ฟเวอร์เท่านั้น และคุณจะไม่มีอะไรให้ตรวจสอบเลย

ใน Apidog ขั้นตอนที่ 2 คือการทดสอบแบบสองคำขอ: ส่งหนึ่งเทิร์น, แก้ไข system prompt, ส่งเทิร์นถัดไปโดยตั้งค่า header แล้วยืนยันจาก input_transformations เก็บสิ่งนี้ไว้ในคอลเลกชันเพื่อให้ทุกการเปลี่ยนแปลงของ harness สามารถรันซ้ำได้ ดาวน์โหลด Apidog เพื่อสร้างสิ่งนี้

การทำให้ harness เป็นแบบ append-only

แต่ละแถวจะแทนที่การแก้ไขประวัติด้วยสิ่งที่ช่วยรักษาส่วนนำหน้าให้สมบูรณ์และรักษาแคชให้พร้อมใช้งาน

การบีบอัดข้อมูลฝั่งไคลเอ็นต์สองรูปแบบจะทำให้การตรวจสอบล้มเหลวและต้องใช้ drop_block หรือ stripped thinking blocks บนเทิร์นที่เก็บไว้ Keep-tail compaction (สรุปเทิร์นเก่าๆ แต่เก็บเทิร์นล่าสุดไว้ตามเดิม) จะล้มเหลวกับเทิร์นที่เก็บไว้ เนื่องจากความคิดของเทิร์นเหล่านั้นถูกสร้างขึ้นจากประวัติทั้งหมด Background compaction (สร้างสรุปนอกเส้นทางวิกฤตและสลับเข้ามาใช้ในภายหลัง) จะล้มเหลวกับทุกเทิร์นที่สร้างขึ้นระหว่างจุดเริ่มต้นของการสรุปและการสลับ การตัดเทิร์นแต่ละรายการออกจากกลาง transcript จะทำให้ block หลังจากนั้นทั้งหมดไม่ถูกต้อง และไม่มีรูปแบบฝั่งไคลเอ็นต์ใดที่หลีกเลี่ยงได้ ใช้ mid-conversation system message สำหรับการเปลี่ยนแปลงคำสั่งที่คุณกำลังทำ หรือใช้ server-side context editing สำหรับการลบแบบเลือก

ข้อควรพิจารณาด้านค่าใช้จ่ายเพิ่มเติม: เนื่องจากการอ่านแคชตอนนี้อยู่ที่ $0.25 ต่อล้านครั้ง การบีบอัดข้อมูลตั้งแต่ต้นเพื่อประหยัดเงินอาจไม่ใช่ทางเลือกที่เหมาะสมอีกต่อไปใน Fable 5.1 Anthropic แนะนำให้ทดลองใช้จุดบีบอัดข้อมูลที่ล่าช้าออกไป

ทำไมเรื่องนี้ถึงเกี่ยวกับแคชด้วย

ทุกสิ่งในตารางด้านบนยังเป็นรายการสิ่งที่ทำให้ prompt cache เริ่มต้นใหม่ Fable 5.1 ทำให้ cache hits มีราคาถูกลงสี่เท่าเมื่อเทียบกับ Fable 5 และทำให้ cache misses เจ็บปวดมากขึ้นตามสัดส่วน ดังนั้น harness แบบ append-only จึงได้รับประโยชน์สองต่อ: การคิดยังคงอยู่ และทุกเทิร์นจะอ่าน prefix ในราคา $0.25 แทนที่จะเขียนใหม่ในราคา $12.50 รายละเอียดราคา มีตัวเลข; API walkthrough แสดงรูปแบบคำขอแบบ turn-scoped และ per-message-effort ในบริบท, คู่มือการ prompt ครอบคลุมว่าคำสั่งต่อเทิร์นใดที่คุ้มค่าที่จะส่งด้วยวิธีนั้น, และ คู่มือ Claude Code อธิบายว่าทำไมผู้ใช้ Claude Code จึงไม่เคยเห็นข้อผิดพลาดนี้

คำถามที่พบบ่อย

“The block is bound to a different conversation” หมายความว่าอย่างไร? หมายความว่า Claude Fable 5.1 thinking block ถูกนำมาใช้ซ้ำหลังจากมีบางสิ่งก่อนหน้านั้นเปลี่ยนแปลงไป: system prompt, tools array หรือข้อความก่อนหน้า API จะปฏิเสธคำขอด้วยข้อผิดพลาด 400 สำหรับบัญชีที่ถูกบังคับใช้

บัญชีใดบ้างที่บังคับใช้การตรวจสอบประวัติ Fable 5.1? บัญชีที่สร้างขึ้นในหรือหลังวันที่ 31 สิงหาคม 2026 บนทุกแพลตฟอร์ม บัญชีเก่าจะบังคับใช้ก็ต่อเมื่อคำขอมีการตั้งค่า thinking.block_binding.prefix_mismatch_behavior เท่านั้น Anthropic วางแผนที่จะบังคับใช้กับทุกคนในโมเดลในอนาคต

จะแก้ไขข้อผิดพลาดนี้อย่างรวดเร็วได้อย่างไร? ส่ง thinking-binding-controls-2026-08-01 beta header พร้อมกับ prefix_mismatch_behavior: "drop_block" API จะละทิ้ง blocks ที่ได้รับผลกระทบและดำเนินการต่อ จากนั้นแก้ไขการแก้ไขประวัติ เพราะการละทิ้ง blocks ในทุกเทิร์นจะทำให้การใช้เหตุผลลดลงและเริ่มต้นแคชของคุณใหม่

การเปลี่ยน effort หรือ max_tokens ทำให้ thinking blocks ใช้ไม่ได้หรือไม่? ไม่ การเปลี่ยนพารามิเตอร์ใดๆ นอกเหนือจาก system, tools และ messages สามารถทำได้อย่างอิสระ รวมถึง cache_control markers

การบีบอัดข้อมูลฝั่งเซิร์ฟเวอร์ทำให้การตรวจสอบล้มเหลวหรือไม่? ไม่ การบีบอัดข้อมูลและการแก้ไขบริบทจะเกิดขึ้นหลังจากการตรวจสอบ ซึ่งจะเปรียบเทียบการสนทนาตามที่คุณส่ง การบีบอัดข้อมูลฝั่งไคลเอ็นต์ที่เก็บเทิร์นล่าสุดไว้ตามเดิมจะทำให้การตรวจสอบล้มเหลว

Claude Mythos 5.1 มีการตรวจสอบเดียวกันนี้หรือไม่? ไม่ Mythos 5.1 ไม่มีการตรวจสอบการสนทนา แม้ว่ามันยังคงผูก thinking blocks กับโมเดลที่สร้างขึ้น และการแก้ไขประวัติยังคงทำให้แคชของมันเริ่มต้นใหม่