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

แก้ข้อผิดพลาด thinking block ผูกกับบทสนทนาอื่นใน Claude Fable 5.1

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

ลองใช้ Apidog วันนี้

การตรวจสอบนี้มีเอกสารอ้างอิงในหัวข้อ 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 ไม่สามารถแก้ไขได้

การตรวจสอบนี้ทำงานอย่างไร

thinking block ทุกอันของ Fable 5.1 จะมีลายเซ็นที่บันทึกไว้สองส่วน:

1. โมเดลที่สร้าง block
2. conversation prefix ที่อยู่ก่อนหน้า block แบบตรงกันทุกไบต์

Prefix ประกอบด้วย:

• system prompt ระดับบนสุด
• tools array
• ทุกข้อความก่อนหน้า block
• ความเชื่อมโยงกับ thinking block ก่อนหน้า

เมื่อส่ง transcript กลับไปยัง API ระบบจะตรวจสอบว่า prefix ตรงกับ prefix ตอนสร้าง block แบบ byte-identical หรือไม่

Anthropic ระบุเหตุผลหลักสองข้อ:

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

ใครได้รับผลกระทบ

บังคับใช้โดยค่าเริ่มต้น

บัญชีที่สร้างในหรือหลังวันที่ 31 สิงหาคม 2026 บนแพลตฟอร์มต่อไปนี้:

• Claude API
• Amazon Bedrock
• Google Cloud
• Microsoft Foundry

บันทึกไว้แต่ยังไม่บังคับใช้

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

Anthropic ระบุว่าโมเดลในอนาคตจะบังคับใช้การตรวจสอบนี้กับทุกบัญชี

ไม่ได้รับผลกระทบ

• Claude Code
• claude.ai
• Claude Managed Agents
• Claude Agent SDK

บริการเหล่านี้จะรักษา prefix ให้คงเดิม อย่างไรก็ตาม Claude Mythos 5.1 ไม่มีการตรวจสอบ conversation prefix แม้การแก้ไขประวัติยังทำให้ cache เริ่มต้นใหม่ได้

ได้รับผลกระทบโดยตรง

โค้ดใดก็ตามที่สร้าง messages array เอง เช่น:

• custom agent loop
• chat backend
• framework ที่ครอบ Messages API

หากคุณสร้างเครื่องมือสำหรับผู้ใช้ที่นำ API key ของตัวเองมาใช้ คีย์ของคุณอาจอยู่ในบัญชีเก่า แต่คีย์ของผู้ใช้อาจอยู่ในบัญชีใหม่ ควรเปิดใช้การตรวจสอบระหว่างการทดสอบเพื่อพบปัญหาก่อนผู้ใช้

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

สิ่งที่ทำให้ thinking block ใช้ไม่ได้

การเปลี่ยนแปลงต่อไปนี้จะทำให้ block ที่ตามมาไม่ตรงกับ prefix เดิม:

• แก้ไข จัดลำดับใหม่ หรือลบเทิร์นก่อนหน้า
• ลบผลลัพธ์ของเครื่องมือเก่า
• ตัดเทิร์นออกจากกลาง transcript
• ใช้ client-side compaction ที่เก็บเทิร์นล่าสุดไว้หลัง summary
• แทรกเนื้อหาที่ไม่ได้มีอยู่ในคำขอก่อนหน้า เช่น turn notification, status bar หรือจำนวนโทเค็นคงเหลือที่เปลี่ยนทุกเทิร์น
• สร้างหรือเปลี่ยน system prompt หรือ tools ระหว่างคำขอ
• อัปเดตวันที่ปัจจุบันใน system prompt
• เพิ่มหรือลบเครื่องมือระหว่างเซสชัน
• URL รูปภาพหรือเอกสารให้ไบต์ต่างกันในภายหลัง

ระบบผูกกับ ไบต์ของเนื้อหา ไม่ใช่ URL ดังนั้น signed URL ที่เปลี่ยนไปแต่ส่งไฟล์ไบต์เดิมจึงไม่ใช่ปัญหา

การลบ thinking block ทำได้เฉพาะจากด้านหน้า โดยเริ่มจาก block ที่เก่าที่สุด หากลบ block จากตรงกลาง block หลังจากนั้นจะไม่ถูกต้อง

สิ่งที่ยังทำได้โดยไม่ทำให้ prefix เสีย

• ใช้ประวัติแบบ append-only
• เพิ่มข้อความ role: "system" โดยไม่แก้ไขข้อความเดิม
• ลบ thinking block ที่อยู่ด้านหน้า โดยเริ่มจาก block ที่เก่าที่สุด
• เปลี่ยนพารามิเตอร์อื่นนอกเหนือจาก system, tools และ messages เช่น:
  • max_tokens
  • output_config
  • effort
  • tool_choice
  • metadata
• เพิ่ม ย้าย หรือลบ cache_control markers
• ใช้ server-side compaction และ server-side context editing

การบีบอัดข้อมูลฝั่งเซิร์ฟเวอร์เกิดขึ้นหลังการตรวจสอบ โดย API จะเปรียบเทียบ transcript ที่คุณส่งเข้ามา ไม่ใช่สำเนาที่เซิร์ฟเวอร์แก้ไข หลัง compaction แล้ว prefix ที่ตรวจสอบจะเริ่มจาก compaction block

วิธีแก้ฉุกเฉินด้วย drop_block

ส่ง 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 ที่ตามมา จากนั้นดำเนินการตามคำขอต่อ และรายงานแต่ละ block ใน input_transformations ระดับบนสุด:

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

ข้อควรระวัง:

1. ค่านี้มีผลเฉพาะคำขอปัจจุบัน ควรส่งต่อเนื่องตลอดเซสชัน
2. บัญชีที่ถูกบังคับใช้จะเกิดข้อผิดพลาดหากไม่มี header ส่วนการส่ง header เพียงอย่างเดียวจะใช้ค่าเริ่มต้นของ beta ซึ่งคือ drop_block
3. ควรกำหนดค่าอย่างชัดเจน อย่าพึ่งพาค่าเริ่มต้น
4. การส่ง block_binding โดยไม่มี header จะทำให้เกิดข้อผิดพลาด:

block_binding: Extra inputs are not permitted

ค่า reason แยกได้สองกรณี:

• prefix_binding_mismatch: ประวัติการสนทนาถูกเปลี่ยน
• model_binding_mismatch: โมเดลเปลี่ยน เช่น router, retry หรือ fallback ทำให้โมเดลเป้าหมายอ่าน Fable 5.1 block ไม่ได้ กรณีนี้ไม่ใช่ข้อบกพร่องของการจัดการประวัติ

เมื่อส่ง header ทุก response จะมี input_transformations array ซึ่งจะเป็น array ว่างหากไม่มี block ถูกละทิ้ง

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

การกู้คืนบนแพลตฟอร์มที่ไม่มี beta control

Microsoft Foundry ยังไม่มีตัวควบคุมนี้เมื่อเปิดตัว ส่วน Bedrock และ Google Cloud กำลังเพิ่มการรองรับตามโมเดล

วิธีกู้คืนคือ:

1. ลบ thinking และ redacted_thinking blocks ทั้งหมดออกจาก history
2. เก็บเฉพาะ text และ tool_use blocks ของแต่ละเทิร์น
3. ส่งคำขอเดิมอีกครั้งหนึ่งครั้ง

โมเดลจะตอบโดยไม่มี reasoning ที่อยู่ใน block เหล่านั้น วิธีนี้เป็นการกู้คืนเฉพาะกิจ ไม่ใช่รูปแบบการใช้งานปกติ

ขั้นตอนตรวจสอบก่อนเปลี่ยนทราฟฟิก

ทำการตรวจสอบก่อนนำ Fable 5.1 ไปใช้จริง:

1. บันทึกคำขอจริง

บันทึก request payload ที่ harness ส่งในเซสชันปกติหลายเทิร์น รวมถึง compaction และการเปลี่ยนเครื่องมือ หากผลิตภัณฑ์รองรับ

เปรียบเทียบคำขอที่ต่อเนื่องกันในส่วนต่อไปนี้:

• system prompt
• tools array
• prefix ที่ใช้ร่วมกันของ messages

ข้อมูลเหล่านี้ควรตรงกันทุกไบต์จนถึงเทิร์นใหม่ที่ถูกเพิ่มเข้ามา

2. ทดสอบด้วย drop_block

รัน multi-turn session ด้วย claude-fable-5-1 และตั้งค่า:

• beta header: thinking-binding-controls-2026-08-01
• prefix_mismatch_behavior: "drop_block"

บันทึก input_transformations จากทุก response:

• array ว่างทุกเทิร์น: history ยังคงสมบูรณ์
• มี prefix_binding_mismatch: เนื้อหาก่อน block ที่ระบุใน path เปลี่ยนแปลง

วิธีนี้ใช้ได้กับทุกบัญชี เพราะการกำหนด field จะเปิดใช้การบังคับตรวจสอบ สำหรับ CI ให้ใช้ "error" เพื่อให้การแก้ไขประวัติทำให้การทดสอบล้มเหลวทันที

ใน Apidog ให้สร้างการทดสอบสองคำขอ:

1. ส่งหนึ่งเทิร์น
2. แก้ไข system prompt
3. ส่งเทิร์นถัดไปพร้อม header
4. ตรวจสอบ input_transformations

เก็บการทดสอบไว้ใน collection เพื่อให้รันซ้ำได้ทุกครั้งที่แก้ไข harness สามารถ ดาวน์โหลด Apidog เพื่อสร้างชุดทดสอบนี้

3. เลือก policy สำหรับ production

กำหนดค่าอย่างชัดเจนภายใต้ header:

• "error" เมื่อ prefix mismatch ถือเป็นข้อบกพร่องที่ต้องหยุดการทำงาน
• "drop_block" เมื่อต้องการให้ระบบทำงานต่อ แม้ประสิทธิภาพการใช้เหตุผลลดลง

ไม่ว่าจะเลือกค่าใด ให้ตรวจสอบทั้ง 400 errors และ input_transformations entries อย่าปล่อย field นี้ว่างในบัญชีเก่า เพราะระบบจะบันทึกความไม่ตรงกันไว้ฝั่งเซิร์ฟเวอร์เท่านั้น

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

สิ่งที่ควรหลีกเลี่ยง	วิธีทำแบบ append-only
แก้ system prompt กลางเซสชัน เช่น วันที่หรือโหมดใหม่	ตรึง system prompt ไว้ตอนเริ่มต้น แล้วเพิ่ม {"role": "system", "content": "The current date is 2026-09-14."} ณ จุดที่การเปลี่ยนแปลงมีผล ข้อความนี้จะกลายเป็นส่วนหนึ่งของ prefix หลังจากนั้น
แก้ tools array กลางเซสชัน	ประกาศเครื่องมือทั้งหมดตั้งแต่เริ่มต้น และใช้ defer_loading: true สำหรับเครื่องมือที่โหลดภายหลัง หรือส่ง tool_addition และ tool_removal blocks ใน system message ด้วย beta mid-conversation-tool-changes-2026-07-01
แทรก turn notification แล้วลบในคำขอถัดไป	ใช้ turn-scoped system message: {"role": "system", "clear_at": "next_user_message", "content": "..."} พร้อม beta mid-conversation-system-clear-at-2026-08-21 หลัง tool result และเก็บสำเนาเดิมไว้ในตำแหน่งเดิม
ลบ tool result เก่าฝั่งไคลเอ็นต์	ใช้ server-side context editing พร้อมล้าง tool result
ใช้ client-side compaction	ใช้ server-side compaction ด้วย beta compact-2026-01-12 และกำหนด instructions สำหรับ summary เอง หากจำเป็นต้องทำฝั่งไคลเอ็นต์ ให้แทนที่ history ทั้งหมดด้วย summary หนึ่งข้อความและ user message ใหม่เท่านั้น
อ้างอิงรูปภาพหรือเอกสารด้วย URL ข้ามเทิร์น	อัปโหลดผ่าน Files API ครั้งเดียว แล้วใช้ file_id หรือส่งข้อมูลแบบ base64

หากไม่มี beta สำหรับ system clear-at ให้ใส่ notification เป็น text block หลัง tool_result blocks ใน user message เดียวกัน โดยเก็บสำเนาเก่าไว้

ข้อจำกัดของ client-side compaction

client-side compaction สองรูปแบบต่อไปนี้ทำให้การตรวจสอบล้มเหลว:

• Keep-tail compaction: สรุปเทิร์นเก่าแต่คงเทิร์นล่าสุดไว้ตามเดิม เนื่องจาก thinking ของเทิร์นเหล่านั้นสร้างจาก history ทั้งหมด
• Background compaction: สร้าง summary นอกเส้นทางหลักแล้วสลับมาใช้ภายหลัง เทิร์นที่เกิดขึ้นระหว่างเริ่มสรุปและสลับจะไม่ตรงกัน

การตัดเทิร์นจากกลาง transcript ทำให้ block หลังจากนั้นทั้งหมดใช้ไม่ได้ ไม่มี client-side pattern ที่หลีกเลี่ยงปัญหานี้ได้ ให้ใช้ mid-conversation system message สำหรับการเปลี่ยนคำสั่ง หรือ server-side context editing สำหรับการลบแบบเลือก

ด้านค่าใช้จ่าย การอ่าน cache อยู่ที่ $0.25 ต่อล้านโทเค็น แล้ว การ compaction ตั้งแต่ต้นเพื่อประหยัดค่าใช้จ่ายอาจไม่คุ้มใน Fable 5.1 ควรทดลองเลื่อนจุด compaction ให้ช้าลง

เหตุใดเรื่องนี้จึงเกี่ยวกับ cache

ทุกสิ่งในตารางข้างต้นที่ทำให้ prefix เปลี่ยน ยังทำให้ prompt cache เริ่มต้นใหม่ด้วย

Fable 5.1 ทำให้ cache hit มีราคาถูกกว่า Fable 5 ถึงสี่เท่า แต่ cache miss มีต้นทุนสูงขึ้นตามสัดส่วน ดังนั้น harness แบบ append-only จึงได้ประโยชน์สองด้าน:

• thinking เดิมยังคงใช้งานได้
• ทุกเทิร์นอ่าน 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” หมายความว่าอย่างไร

หมายความว่า thinking block ของ Claude Fable 5.1 ถูกนำกลับมาใช้หลังจากข้อมูลก่อนหน้ามันเปลี่ยน เช่น system prompt, tools array หรือข้อความก่อนหน้า สำหรับบัญชีที่ถูกบังคับใช้ API จะปฏิเสธคำขอด้วยข้อผิดพลาด 400

บัญชีใดบังคับใช้การตรวจสอบนี้

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

แก้ข้อผิดพลาดอย่างรวดเร็วได้อย่างไร

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

การเปลี่ยน effort หรือ max_tokens ทำให้ thinking block ใช้ไม่ได้หรือไม่

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

Server-side compaction ทำให้การตรวจสอบล้มเหลวหรือไม่

ไม่ การ compaction และ context editing ฝั่งเซิร์ฟเวอร์เกิดขึ้นหลังการตรวจสอบ ซึ่งเปรียบเทียบ conversation ตามที่ส่งเข้ามา ส่วน client-side compaction ที่คงเทิร์นล่าสุดไว้ตามเดิมจะทำให้การตรวจสอบล้มเหลว

Claude Mythos 5.1 มีการตรวจสอบเดียวกันหรือไม่

ไม่มี Mythos 5.1 ไม่มี conversation-prefix validation แม้ thinking blocks จะยังผูกกับโมเดลที่สร้างขึ้น และการแก้ไข history ยังทำให้ cache เริ่มต้นใหม่ได้

ลิงก์อ้างอิง

• preserved thinking
• มีอะไรใหม่ใน Claude Fable 5.1
• คู่มือการย้ายระบบ
• Claude.ai
• Apidog
• ดาวน์โหลด Apidog
• mid-conversation system messages
• การบีบอัดข้อมูลฝั่งเซิร์ฟเวอร์
• รายละเอียดราคา
• API walkthrough
• คู่มือการ prompt
• คู่มือ Claude Code