คู่มือ API ของ Claude Opus 5.5: Model ID, การเปลี่ยนแปลงแบบ Breaking 4 ประการ และประการที่ห้าที่เงียบงัน

เปลี่ยนสตริงโมเดลจาก claude-opus-5 เป็น claude-opus-5-5 แล้วโค้ดของคุณก็ยังคอมไพล์ผ่าน ยังตรวจชนิดผ่าน และยังผ่านอะไรก็ตามที่ถือเป็นชุดทดสอบ จากนั้นมันก็ตอบ 400 ในโปรดักชัน รูปร่างคำขอสี่แบบที่ Claude Opus 5 ยอมรับ กลับถูกปฏิเสธทันทีโดย Claude Opus 5.5 และการเปลี่ยนแปลงที่ห้ากลับไม่ทำให้อะไรพังเลย — ซึ่งนั่นแหละคือเหตุผลว่าทำไมมันถึงจะเป็นข้อที่ไปถึงผู้ใช้ของคุณ นี่คือเอกสารอ้างอิงการผสานรวมสำหรับโมเดลนี้: ตัวระบุ ช่องทางที่ให้บริการมัน สัญญาของคำขอ ข้อผิดพลาดทั้งสี่ ข้อที่ห้าที่เงียบงัน และพารามิเตอร์ effort ทำงานอย่างไรในตอนนี้ ในจุดที่พฤติกรรมตรงกับ Claude Fable 5.1 ทีมที่ย้ายไปที่นั่นแล้วได้ทำงานส่วนหนึ่งไปแล้ว ดังนั้นการเปลี่ยนแปลงแต่ละข้อด้านล่างจะบอกว่ามันใช้กับโมเดลนั้นด้วยหรือไม่

ทุกอย่างที่นี่อ่านมาจากเอกสาร Claude ของ Anthropic เอง เมื่อวันที่ 2026-09-24 ซึ่งเป็นสองวันหลังจากโมเดลนี้เปิดตัว ข้อกล่าวอ้างของผู้ขายถูกระบุว่าเป็นข้อกล่าวอ้างของผู้ขาย ตัวเลขที่เป็นอิสระก็ระบุว่าเป็นอิสระ และทั้งสองอย่างไม่เคยถูกนำเสนอที่การตั้งค่าความพยายามระดับเดียวกันราวกับว่าสามารถเปรียบเทียบกันได้

รหัสโมเดล และตำแหน่งที่ให้บริการ

ตัวระบุคือ claude-opus-5-5 — เป็น model id แบบคงที่ที่ไม่มีคำต่อท้ายวันที่ ใช้รูปแบบเดียวกับ claude-opus-5 ไม่มีรูปแบบ pinned-snapshot แยกต่างหากให้เลือกใช้ และไม่มี alias ที่ไปชี้ยังสิ่งอื่น

ภาพรวมโมเดลของ Anthropic แสดงห้าส่วนติดต่อ โดยมีสตริงเหล่านี้ตรงตามต้นฉบับ:

• Claude API — claude-opus-5-5 พร้อมให้บริการแก่ลูกค้าทุกท่าน

• Amazon Bedrock — anthropic.claude-opus-5-5 (เป็นแพลตฟอร์มเดียวที่ใส่ชื่อผู้ให้บริการไว้ข้างหน้า)

• Claude Platform บน AWS — claude-opus-5-5 โดยใช้ ID ของ Claude API แทน ID แบบ Bedrock

• Google Cloud — claude-opus-5-5.

• Microsoft Foundry — claude-opus-5-5; ชื่อการปรับใช้คือสิ่งที่คุณส่งไป และ Foundry จะดำเนินตามกำหนดวงจรชีวิตของ Claude API

สองในห้ารายการนั้นสำคัญกว่าส่วนที่เหลือของหัวข้อนี้ Amazon Bedrock และ Google Cloud กำหนดวงจรชีวิตและวันที่เลิกใช้ของตัวเอง และ — ดังที่ breaking changes ด้านล่างแสดงให้เห็น — Bedrock ยังเป็นแพลตฟอร์มเดียวที่เครื่องมือ computer-use ตัวเก่ายังทำงานได้ หากคุณใช้ Bedrock คุณไม่ได้อยู่ในการโยกย้ายเดียวกันกับคนอื่น ๆ

สิ่งที่ทุกคำขอต้องเป็นไปตามในตอนนี้

คู่มือการย้ายของ Anthropic ระบุข้อกำหนดไว้เป็นรายการ และรายการนั้นสั้นพอที่คุณจะตรวจสอบไคลเอนต์ของคุณเองกับมันได้ ไม่ว่าคุณจะย้ายมาจากโมเดลใด คำขอที่ส่งไปยัง claude-opus-5-5 ต้อง:

• ส่งโดยไม่ระบุฟิลด์ thinking หรือส่ง thinking: {"type": "adaptive"} — ทั้งสองแบบเทียบเท่ากัน เพราะ adaptive thinking เปิดใช้งานอยู่เสมอ

• ควบคุมความลึกของการคิดด้วย effort ซึ่งเป็นพารามิเตอร์ของคำขอเพียงตัวเดียวที่ทำเช่นนี้ได้ โดยรองรับทั้งห้าระดับ และค่าเริ่มต้นคือ medium

• ใช้ tool_choiceเป็น {"type": "auto"} (ค่าเริ่มต้น) หรือ {"type": "none"} การบังคับใช้เครื่องมือจะถูกปฏิเสธ

• ไม่ต้องระบุ temperature, top_p และ top_k หรือปล่อยไว้ที่ค่าเริ่มต้น ค่าอื่นใดจะถูกปฏิเสธ ทั้งในโมเดลนี้เช่นเดียวกับทุกอย่างตั้งแต่ Claude Opus 4.7 เป็นต้นไป

• ไม่ลงท้ายข้อความด้วยเทิร์นของผู้ช่วยที่เติมไว้ล่วงหน้า ซึ่งสิ่งนี้ถูกปฏิเสธไปแล้วใน Opus 4.6 และรุ่นถัด ๆ ไป

• ประกาศการใช้คอมพิวเตอร์เป็น computer_toolset_20260801ชุดเครื่องมือบน Claude API และ Google Cloud

• ไม่ส่ง beta header สำหรับ context window โดยค่าเริ่มต้น context window ขนาด 1M คือค่าเริ่มต้น และ header ที่เขียนสำหรับโมเดลรุ่นเก่าจะไม่มีผลใด ๆ

ในกรณีที่คู่มือระบุว่าการตั้งค่าถูกปฏิเสธ API จะตอบกลับด้วย HTTP 400 นั่นคือรูปแบบความล้มเหลวทั้งหมดของการย้ายมาสู่โมเดลนี้ ไม่ใช่ผลลัพธ์ที่ด้อยคุณภาพ ไม่ใช่คำเตือนในล็อก — แต่เป็นคำขอที่ไม่ได้ถูกเรียกใช้เลย

การเปลี่ยนแปลงที่สำคัญสี่ประการ

1. ไม่สามารถปิดใช้งานการคิดได้

Adaptive thinking เปิดใช้งานอยู่เสมอ thinking: {"type": "disabled"} จะคืนค่า 400 และการกำหนด budget ด้วยตนเองก็เช่นกัน — thinking: {"type": "enabled", "budget_tokens": N} ข้อความแสดงข้อผิดพลาดจะระบุชื่อ type ที่คุณส่ง แล้วระบุชื่อ type ที่ใช้แทน:

• ไม่รองรับ "thinking.type.disabled" สำหรับโมเดลนี้ ใช้ "thinking.type.adaptive" และ "output_config.effort" เพื่อควบคุมลักษณะการทำงานของ thinking

• ไม่รองรับ "thinking.type.enabled" สำหรับโมเดลนี้ ใช้ "thinking.type.adaptive" และ "output_config.effort" เพื่อควบคุมพฤติกรรมการคิด

ผลลัพธ์ในทางปฏิบัติไม่ใช่ตัวข้อผิดพลาด แต่เป็นสิ่งที่เกิดขึ้นหลังจากคุณแก้ไขมัน บน Claude Opus 4.8 และเวอร์ชันก่อนหน้า คำขอที่ไม่มีฟิลด์ thinking จะทำงานโดยไม่มีการคิด บน Claude Opus 5.5 ทุกคำขอจะคิด และ max_tokensยังคงเป็นขีดจำกัดตายตัวที่ครอบคลุมทั้งการคิดและข้อความตอบกลับ โทเค็นการคิดจะถูกคิดค่าใช้จ่ายเป็นโทเค็นเอาต์พุตแม้ว่าข้อความการคิดจะไม่ถูกส่งกลับมาให้คุณก็ตาม ปลายทางที่ก่อนหน้านี้ทำงานโดยไม่มีการคิดจึงอาจสร้างโทเค็นเอาต์พุตต่อคำขอได้มากขึ้นหลัง "การแก้ไข" กว่าที่เคยเป็น คำแนะนำของ Anthropic คือให้ลด effort ในจุดที่คุณเคยปิดการคิด และ — ที่ xhigh หรือ max effort — ให้เริ่ม max_tokens ที่ 64k แล้วปรับจากตรงนั้น

รูปร่างของการตอบกลับก็เปลี่ยนแปลงเช่นกัน การตอบกลับอาจเริ่มต้นด้วยบล็อก thinking หนึ่งบล็อกหรือมากกว่าก่อนบล็อก text แรก ดังนั้นโค้ดที่อ่านคำตอบตามตำแหน่ง — content[0].text หรือตัวจัดการสตรีมที่ถือว่า content_block_start ตัวแรกเป็น text — จะพังกับการตอบกลับเหล่านี้แม้ว่าคำขอจะสำเร็จก็ตาม ให้เลือกบล็อกตามฟิลด์ typeของมันแทน

2. การบังคับให้ใช้เครื่องมือจะส่งคืนข้อผิดพลาด

tool_choice ชนิด any และ tool จะส่งคืน 400 และการตรวจสอบเดียวกันนี้ใช้กับการเรียกปลายทางการนับโทเค็น ดังนั้นการนับล่วงหน้าจึงล้มเหลวในลักษณะเดียวกับการเรียกจริง:

• tool_choice: ชนิด "tool" และ "any" ไม่ได้รับการสนับสนุนสำหรับโมเดลนี้

auto และ none ไม่ได้รับผลกระทบ สิ่งที่เอกสารระบุให้ใช้แทนคือคงtool_choice: {"type": "auto"} ไว้, ทำเครื่องหมายเครื่องมือด้วยstrict: true เพื่อให้อาร์กิวเมนต์ถูกต้องตามสคีมา หรือย้ายสคีมาไปที่ structured outputs — และระบุในพรอมป์ต์ว่าเครื่องมือนั้นใช้เมื่อใด เนื่องจาก auto ไม่รับประกันว่าจะมีการเรียกใช้ การใช้เครื่องมือแบบ strict รองรับเพียงสับเซตของ JSON Schema โดยทุกออบเจกต์ใน input_schema ของเครื่องมือต้องตั้งค่าadditionalProperties: false ดังนั้นควรตรวจสอบแต่ละสคีมาก่อนจะเปิดแฟล็ก และให้สังเกตช่องว่างที่สิ่งนี้ทิ้งไว้: หากโค้ดของคุณพึ่งพาการบังคับให้เรียกใช้ แทนที่จะเพียงอนุญาตให้เรียกใช้ auto จะคืนสิทธิ์การอนุญาตกลับมา แต่ไม่ได้คืนการรับประกัน ตรวจสอบว่ามีบล็อก tool_use กลับมาจริงหรือไม่

3. บล็อกการคิดผูกอยู่กับโมเดลและกับบทสนทนา

ทุกบล็อกความคิดจะบันทึกว่าโมเดลใดสร้างขึ้น และแต่ละโมเดลจะอ่านบล็อกของตนเองรวมถึงชุดบล็อกที่กำหนดไว้ของโมเดลอื่น กฎนี้ใช้ได้ทั้งสองทิศทาง:

• Claude Opus 5.5 อ่านบล็อกการคิดจาก Claude Opus 5 และโมเดล Opus, Sonnet และ Haiku รุ่นก่อนหน้า — แต่ไม่อ่านจากโมเดล Claude Fable หรือ Claude Mythos

• บน Claude API นั้น Claude Fable 5.1 และ Claude Mythos 5.1 อ่านบล็อกของ Claude Opus 5.5 ได้ ไม่มีโมเดลอื่นที่ทำได้

• การสนทนาที่ย้ายจาก Claude Opus 5.5 ไปเป็นสิ่งอื่นใดนอกเหนือจากสองตัวนั้น จะดำเนินเทิร์นหลังจากนั้นโดยไม่มีเหตุผลประกอบจากช่วงก่อนหน้า

เราเตอร์หรือกลไกสำรองที่ย้ายบทสนทนาเป็นวิธีที่ชัดเจนในการทำให้เกิดปัญหานี้ ส่วนที่ละเอียดอ่อนกว่าคือบล็อกนั้นผูกกับคำนำหน้าของบทสนทนาด้วย — พร้อมต์ระบบ เครื่องมือ และทุกข้อความก่อนหน้านั้น Anthropic บังคับใช้การตรวจสอบคำนำหน้าเป็นค่าเริ่มต้นสำหรับบัญชีที่สร้างตั้งแต่วันที่ 2026-08-31 00:00 UTC เป็นต้นไป บน Claude API และบนแพลตฟอร์มคลาวด์: หากส่งบล็อกซ้ำหลังจากแก้ไขพร้อมต์ระบบ รายการเครื่องมือ หรือข้อความก่อนหน้า คำขอจะคืนค่า 400 มีช่องทางหลบเลี่ยงสองทาง ส่ง thinking-binding-controls-2026-08-01 เฮดเดอร์เบต้าและตั้งค่า thinking.block_binding.prefix_mismatch_behavior เป็น "drop_block" เพื่อทิ้งบล็อกที่ได้รับผลกระทบแทนที่จะทำให้คำขอล้มเหลว หรือทำให้บทสนทนาเป็นแบบต่อท้ายเท่านั้น และเปลี่ยนคำสั่งด้วยข้อความระบบกลางบทสนทนาแทนการแก้ไข — ซึ่งเป็นสิ่งที่ Claude Code, claude.ai, Claude Managed Agents และ Claude Agent SDK ทำอยู่แล้ว

มีข่าวดีเรื่องหนึ่งที่มองข้ามได้ง่าย: เมื่อคำขอมีบล็อกที่โมเดลเป้าหมายอ่านไม่ได้ API จะตัดบล็อกนั้นออกก่อนที่โมเดลจะเห็นมัน คำขอจะสำเร็จ และบล็อกที่ถูกตัดออกจะไม่ถูกคิดค่าบริการ

4. เครื่องมือ computer-use รุ่นเก่าจะถูกปฏิเสธบน Claude API และ Google Cloud

รายการ tools ที่มีชนิดเป็น computer_20251124 จะส่งคืนข้อผิดพลาด 400 บน Claude API และ Google Cloud ข้อความดังกล่าวจะระบุชนิดที่ถูกปฏิเสธ จากนั้นจึงแสดงรายการชนิดที่โมเดลยอมรับ:

• 'claude-opus-5-5' ไม่รองรับประเภทเครื่องมือ: computer_20251124

สิ่งที่ใช้แทนคือ computer_toolset_20260801 ทูลเซ็ต: ให้ลบ computer-use-2025-11-24 เฮดเดอร์เบต้าออก และส่งรายการ tools โดยไม่ระบุ name และไม่ระบุขนาดการแสดงผล นี่ไม่ใช่แค่การเปลี่ยนคำขอ — ลูปของเอเจนต์ก็เปลี่ยนตามไปด้วย แอ็กชันจะมาในรูปแบบบล็อก tool_use แบบ member แทนที่จะเป็นเครื่องมือ computer เดียว อาจมีได้หลายรายการในหนึ่งเทิร์น แอ็กชันคือ name ของบล็อก แทนที่จะเป็น input.action และทุกลัพธ์ต้องสะท้อน toolset_name กลับไปด้วย บน Amazon Bedrock นั้น computer_20251124 ยังคงทำงานเหมือนกับบน Claude Opus 5 ทุกประการ และไม่จำเป็นต้องเปลี่ยนแปลงอะไร

ข้อใดในสี่ข้อนี้ที่ใช้กับ Claude Fable 5.1 ได้ด้วยเช่นกัน

Anthropic ระบุว่าสามข้อแรกมีผลกับ Claude Fable 5.1 เช่นกัน — การคิดแบบเปิดตลอดเวลา ไม่มีการบังคับเลือกเครื่องมือ และบล็อกการคิดที่ผูกกับโมเดลและบทสนทนา ส่วนการเปลี่ยนแปลงด้าน computer-use ไม่เป็นเช่นนั้น: อันนั้นเฉพาะกับโมเดลนี้บน Claude API และ Google Cloud ดังนั้นทีมที่ย้ายไปใช้ Claude Fable 5.1 แล้วได้เลิกใช้เส้นทางโค้ดที่ปิดการคิดและตัวเลือกเครื่องมือแบบบังคับไปแล้ว และมีรูปแบบบทสนทนาแบบต่อท้ายเท่านั้น สิ่งที่เหลืออยู่คือ model id และชุดเครื่องมือ computer-use ทีมที่มาจาก Claude Opus 5ต้องเผชิญกับทั้งสี่ข้อพร้อมกัน นั่นคือการย้ายระบบที่คุ้มค่ากับการวางแผน และปริมาณงานจะแตกต่างกันไปขึ้นอยู่กับว่าคุณเริ่มจากจุดไหน

การเปลี่ยนแปลงครั้งที่ห้า: ไม่มีข้อผิดพลาดใด ๆ และฟีดความคืบหน้าของคุณก็เงียบลง

บน Claude Opus 5 บันทึกสั้น ๆ ที่โมเดลเขียนระหว่างการเรียกใช้เครื่องมือจะถูกส่งกลับมาเป็นบล็อกข้อความธรรมดา บน Claude Opus 5.5 — เช่นเดียวกับ Claude Fable 5.1 — คำบรรยายนั้นจะถูกส่งกลับมาเป็นบล็อก thinking แบบอัปเดตความคืบหน้า อย่างมากหนึ่งบล็อกก่อนการเรียกใช้เครื่องมือแต่ละครั้ง และ thinking.display มีค่าเริ่มต้นเป็น "omitted" ดังนั้นบล็อกเหล่านั้นจะมาพร้อมกับฟิลด์ thinking ที่ว่างเปล่าควบคู่กับ signature ของมัน

ไม่มีคำขอใดล้มเหลว ไม่มีข้อผิดพลาดใดถูกบันทึก แอปพลิเคชันที่สตรีมข้อความระหว่างเครื่องมือให้ผู้ใช้เป็นตัวบ่งชี้ความคืบหน้า ก็เพียงหยุดแสดงความคืบหน้าระหว่างการเรียกใช้เครื่องมือ และเริ่มไม่แสดงอะไรเลย อาการที่มองเห็นได้คือ UI ที่ดูเหมือนค้างในช่วงของการทำงานที่ผู้ใช้ต้องการความมั่นใจมากที่สุดพอดี และมันจะถูกรายงานว่าเป็นปัญหาด้านประสิทธิภาพ ปัญหาเครือข่าย หรืออาการค้าง — ไม่ใช่บั๊กจากการย้ายระบบ นี่คือการเปลี่ยนแปลงที่จะถูกนำขึ้นโปรดักชัน

วิธีแก้คือการตั้งค่าการแสดงผล บวกกับการอ่านที่สอดคล้องกับการตั้งค่านั้น:

• ตั้งค่า thinking.display เป็น "updates" — เบต้า อยู่หลัง thinking-display-updates-2026-08-18 ซึ่งเป็นเฮดเดอร์ — เพื่อให้ได้การอัปเดตความคืบหน้ากลับมา ในขณะที่การให้เหตุผลเองยังคงถูกซ่อนอยู่ นี่คือการตั้งค่าที่ฟีดความคืบหน้าต้องการ

• หรือตั้งค่าเป็น "summarized" เพื่อรับการอัปเดตความคืบหน้าและบทสรุปการให้เหตุผลที่ผสมรวมกันอยู่ในบล็อกเดียวกัน

• จากนั้นอ่านข้อความจากบล็อก thinking แทนบล็อก text, เรนเดอร์บล็อก thinking ที่ไม่ว่างแต่ละบล็อกไว้ก่อนบล็อก tool_use ที่มันนำหน้า และส่งบล็อกเหล่านั้นกลับไปโดยไม่เปลี่ยนแปลงพร้อมกับส่วนที่เหลือของเทิร์นผู้ช่วย

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

ความพยายามคือพื้นผิว API

เมื่อไม่สามารถปิดการคิดได้ output_config.effort จึงกลายเป็นตัวปรับเพียงตัวเดียวที่กำหนดว่าโมเดลใช้เหตุผลมากเพียงใด และด้วยเหตุนี้จึงเป็นตัวปรับเพียงตัวเดียวที่กำหนดต้นทุนและความหน่วงในงานหนึ่งๆ มีสี่สิ่งที่ควรรู้เกี่ยวกับเรื่องนี้ก่อนที่คุณจะคัดลอกการตั้งค่าจากโมเดลเดิม

ค่าเริ่มต้นเปลี่ยนไปแล้ว Claude Opus 5.5 ใช้ effort ระดับ medium เป็นค่าเริ่มต้น ในขณะที่ Claude Opus 5 และโมเดล Opus รุ่นก่อนหน้าใช้ค่าเริ่มต้นที่ high คำขอที่ไม่ระบุ effort ตอนนี้จะทำงานต่ำลงหนึ่งระดับจากที่เคยเป็นก่อนการสลับรุ่น Anthropic ยังระบุด้วยว่าโมเดลนี้มีแนวโน้มที่จะคิดมากขึ้นต่อเทิร์น ณ การตั้งค่า effort ระดับหนึ่ง เมื่อเทียบกับ Claude Opus 5 โดยเฉพาะอย่างยิ่งที่ระดับ xhigh และ max ผลกระทบทั้งสองนี้ผลักไปในทิศทางตรงข้ามกัน ซึ่งเป็นเหตุผลที่คำแนะนำของผู้ให้บริการคือให้ทำการกวาดหาค่า effort ใหม่บนชุดประเมินของคุณเอง แทนที่จะแปลงค่าการตั้งค่าข้ามรุ่นไปเลย

สเกลคือ low / medium / high / xhigh / max โดยทั้งห้าระดับรองรับที่นี่ ชื่อระดับไม่ใช่การกำหนดงบโทเคนแบบตายตัวตั้งแต่แรก — Anthropic อธิบายว่า effort เป็นสัญญาณเชิงพฤติกรรม ไม่ใช่การจำกัดงบแบบเข้มงวด — และการจัดสรรโทเคนเบื้องหลังแต่ละระดับก็เปลี่ยนไปตามโมเดล ดังนั้น "high" บน Claude Opus 5.5 จึงไม่ใช่ "high" บน Claude Opus 5 การตั้งค่า effort ให้เป็นค่าเริ่มต้นของโมเดลก็เหมือนกับการไม่ระบุเลย

รายละเอียดด้านการดำเนินงานสองข้อ เพราะทั้งสองข้อทำให้ต้องเสียค่าใช้จ่ายเมื่อมองข้าม ข้อแรก การเปลี่ยนค่าระดับความพยายาม (effort) ระดับบนสุดระหว่างคำขอจะทำให้ prompt cache ใช้ไม่ได้: ให้เลือกระดับหนึ่งและคงค่าไว้ให้คงที่ภายในบทสนทนาที่อาศัยการแคชฮิต และให้ปรับค่านั้นตามเวิร์กโหลดแทน ข้อที่สอง โมเดลนี้รองรับ ความพยายามต่อข้อความ (ส่วนหัว beta mid-conversation-output-config-2026-07-01) ซึ่งเปลี่ยนระดับได้จากเทิร์นหลังจากนั้นโดยไม่ต้องรีสตาร์ตแคช ขั้นต่ำของ prompt cache ที่นี่คือ 512 โทเค็น ลดลงจาก 1,024 ในรุ่นก่อนหน้า ดังนั้นพรอมป์ตที่แต่ก่อนสั้นเกินกว่าจะแคชได้ ตอนนี้สามารถสร้างรายการแคชได้โดยไม่ต้องแก้โค้ด

เพดานเอาต์พุต: 128K แบบซิงโครนัส, 300K บน Batch

Messages API แบบซิงโครนัสจำกัดเอาต์พุตไว้ที่ 128K โทเคน ส่วน Message Batches API ไปได้ถึง 300K โทเคนเอาต์พุต เมื่อใช้output-300k-2026-03-24 beta header — ซึ่งเป็นสตริงนั้นแบบเป๊ะ ๆ อินพุตเป็นหน้าต่างบริบทขนาด 1M โทเคนเต็มจำนวนโดยค่าเริ่มต้น โดยไม่ต้องมีเฮดเดอร์

การตีความเชิงปฏิบัติ: เพดาน 128K ไม่เปลี่ยนแปลงจาก Claude Opus 5 ดังนั้นจึงไม่มีส่วนใดของการผสานรวมแบบซิงโครนัสที่ต้องจัดงบใหม่เฉพาะแกนนั้นเพียงอย่างเดียว สิ่งที่ต้องจัดงบใหม่คือการคิดภายในนั้น เนื่องจากตอนนี้ max_tokens ครอบคลุมทั้งการคิดและข้อความในทุกคำขอ ค่าที่เคยพอดีสำหรับข้อความตอบกลับบน Claude Opus 5 จึงแน่นกว่าเดิมที่นี่ — และที่ความพยายามระดับ xhigh หรือ max ผู้ให้บริการแนะนำให้เริ่มที่ 64k แล้วปรับจูน หากงานที่รันเป็นเวลานานถูกกำหนดขนาดโดยอิงกับเพดานซิงโครนัส 128K และตอนนี้ถูกตัดทอน สิ่งที่เปลี่ยนไปไม่ใช่เพดาน

การกำหนดเส้นทาง Safeguard เป็นส่วนหนึ่งของข้อกำหนด

นี่เป็นข้อเท็จจริงด้านการผสานรวม ไม่ใช่เชิงอรรถของนโยบาย: ในบางพรอมต์ สตริงโมเดลที่คุณส่งไปไม่ได้บ่งบอกว่าอะไรเป็นตัวตอบ

Claude Opus 5.5 มาพร้อมกับตัวจำแนกความปลอดภัย และคำขอที่ถูกปฏิเสธจะถูกส่งกลับมาเป็น HTTP 200 พร้อมกับ stop_reason: "refusal" และออบเจกต์ stop_detailsที่ระบุพื้นที่นโยบาย โมเดลนี้ครอบคลุมหมวดหมู่ต่าง ๆ มากกว่า Claude Opus 5 — คาดว่าจะมี bio, frontier_llm และ reasoning_extraction ควบคู่ไปกับ cyber ที่คุ้นเคย การปฏิเสธ reasoning_extraction จะถูกบล็อกไปเลยแทนที่จะลองใหม่ ระบบสำรองฝั่งเซิร์ฟเวอร์ของ Anthropic จะไม่ลองใหม่ และการปฏิเสธจะถูกส่งกลับมาที่คุณ

สำหรับหมวดหมู่ที่ลองใหม่อีกครั้ง กลไกนี้คือพารามิเตอร์ ตั้งค่า fallbacks เป็น "default"พร้อมกับserver-side-fallback-2026-07-01 ส่วนหัวเบต้า แล้ว API จะรันคำขอที่ถูกปฏิเสธอีกครั้งบนโมเดลที่ Anthropic แนะนำสำหรับหมวดหมู่นั้น ภายในคำสั่งเรียกเดียว โดยคืนค่าตอบกลับมาเพียงหนึ่งรายการ ศูนย์ช่วยเหลือของ Anthropic ระบุเส้นทางการส่งต่อสำหรับโมเดลนี้ไว้อย่างชัดเจนว่า คำขอด้านความปลอดภัยไซเบอร์ที่ถูกตั้งสัญญาณจะส่งต่อไปยัง Claude Opus 4.8 และตัวจำแนกทางชีววิทยาของมัน — ชุดสไตล์ Fable-5 — ทำให้เกิดการส่งต่อไปยัง Claude Opus 5 สำหรับงานด้านวิทยาศาสตร์ชีวภาพที่ใช้ประโยชน์ได้สองทาง ขีดความสามารถเฉพาะกลุ่มแคบ ๆ ด้านการพัฒนาหน่วย LLM ชั้นแนวหน้าก็ถูกส่งต่อไปยัง Claude Opus 5 เช่นกัน Anthropic ยังระบุด้วยว่าการตรวจสอบเหล่านี้ตรวจดูทุกอย่างที่โมเดลอ่าน ไม่ใช่แค่ข้อความล่าสุดของคุณ ดังนั้นหน่วยความจำ เนื้อหาจากคอนเนกเตอร์ ผลการค้นหา และไฟล์ต่าง ๆ จึงอาจกระตุ้นให้เกิดการสลับได้

มีสามสิ่งที่ตามมาสำหรับการผสานรวมของคุณ อ่านฟิลด์model ระดับบนสุดในทุกคำตอบ เพราะมันรายงานโมเดลที่สร้างข้อความนั้นจริง ๆ และบล็อกเนื้อหาfallback จะทำเครื่องหมายจุดส่งต่อแต่ละจุด ตรวจสอบขีดจำกัดอัตราของ fallback เอง เพราะ fallback ที่ติดขีดจำกัดอัตราจะไม่ถูกเรียกใช้และจะคืนการปฏิเสธแทน — fallback จะเสื่อมลงเป็นการปฏิเสธภายใต้ภาวะโหลดสูง และให้ถือว่าการรัน benchmark ที่เผยแพร่ใด ๆ ที่เปิดใช้มาตรการป้องกันเป็นการวัดระบบที่ถูกจัดเส้นทาง ไม่ใช่ของ Claude Opus 5.5 เพียงลำพัง ซึ่งก็คือสิ่งที่ Anthropic กล่าวไว้เกี่ยวกับตัวเลขของตนเองด้านล่างนี้อย่างตรงไปตรงมา

การทำงานแบบสำรองฝั่งเซิร์ฟเวอร์ยังอยู่ในช่วงเบต้าและรองรับเฉพาะ Claude API เท่านั้น: ไม่รองรับบน Message Batches API และไม่พร้อมใช้งานบน Amazon Bedrock, Google Cloud หรือ Microsoft Foundry ซึ่งในกรณีเหล่านั้น SDK middleware คือแนวทางที่ระบุไว้ในเอกสารแทน ในส่วนของการตรวจสอบยืนยันนั้น มีเส้นทางการขอสิทธิ์เข้าถึงสำหรับทั้งสองหมวดหมู่ ได้แก่ Cyber Verification Program และ Life Sciences Verification Program แต่ขอให้สังเกตความไม่สมมาตรที่ศูนย์ช่วยเหลือของ Anthropic ระบุไว้ ณ เวลาที่เขียนนี้: ปัจจุบัน Claude Opus 5.5 ยังไม่ได้รับการระบุอยู่ใน Cyber Verification Program ขณะที่โครงการด้านวิทยาศาสตร์ชีวภาพนั้นถูกอธิบายว่ามอบสิทธิ์ให้องค์กรที่ผ่านการตรวจสอบยืนยันเข้าถึงโมเดลที่มีความสามารถสูงสุดได้

บริบท จุดตัด การปลดระวาง และโหมดเร็ว

ส่วนที่เหลือของซองข้อมูล จากหน้าโมเดลและตารางการเลิกใช้งาน:

• หน้าต่างบริบท — 1M โทเค็น, ค่าเริ่มต้น, ไม่มี beta header

• ขีดจำกัดความรู้ — มิถุนายน 2026 ซึ่งเป็นขีดจำกัดข้อมูลการฝึกอบรมด้วยเช่นกัน

• การปลดระวาง — ไม่เร็วกว่า 2027-09-22 บนแพลตฟอร์มที่ดำเนินการโดย Anthropic โดยมีระยะเวลาแจ้งล่วงหน้าอย่างน้อย 60 วัน Amazon Bedrock และ Google Cloud กำหนดวันที่ของตนเอง Claude Opus 5 อยู่ในสถานะ Active จนถึงอย่างน้อย 2027-07-24 จึงไม่มีการบังคับเปลี่ยนผ่าน

• ตารางราคา — $4.00 ต่อล้านอินพุต, $20.00 ต่อล้านเอาต์พุต, $5.00 ต่อล้านการเขียนแคช 5 นาที, $8.00 ต่อล้านการเขียนแคช 1 ชั่วโมง, $0.20 ต่อล้านการอ่านแคช Batch คิดราคาครึ่งหนึ่งทั้งสองทิศทางที่ $2.00 / $10.00

การอ่านแคชเป็นค่าผิดปกติที่น่าสังเกต: $0.20 คิดเป็น 5% ของอินพุตฐาน ขณะที่โมเดล Claude ส่วนใหญ่อยู่ที่ 10% และ Claude Fable 5.1 อยู่ที่ 2.5% เวิร์กโหลดแบบผสมที่มีการใช้แคชซ้ำจำนวนมากจะรู้สึกได้ว่านั่นคือส่วนลดจริง ๆ

• โหมด Fast — ยังคงมีเอกสารระบุว่าเป็น Research Preview ใช้ได้เฉพาะกับ Claude API เท่านั้น คิดราคาแยกต่างหากที่ 8.00 ดอลลาร์ต่ออินพุต / 40.00 ดอลลาร์ต่อเอาต์พุตต่อล้าน เปิดใช้งานด้วย speed: "fast" และ fast-mode-2026-02-01 เฮดเดอร์เบต้า โดยไม่สามารถใช้ได้บน Bedrock, Claude Platform บน AWS, Google Cloud หรือ Microsoft Foundry ไม่สามารถใช้กับ Batch API และไม่สามารถใช้กับการผูกมัด Priority Tier ได้ โปรดทราบว่า Claude Opus 5.5 ไม่รองรับ Priority Tier เลย

สิ่งที่ benchmarks ระบุ และที่การตั้งค่าใด

การตั้งค่าความพยายามคือเหตุผลที่ตารางของผู้ขายและตารางอิสระไม่สามารถเปรียบเทียบทีละแถวได้ และเป็นเหตุผลว่าทำไมตัวเลขทุกตัวด้านล่างจึงระบุการตั้งค่าของตนมาด้วย

รายงานโดยผู้จำหน่าย โดยใช้ฮาร์ดแฮนเนสของ Anthropic เองบันทึกการเปิดตัวของ Anthropic ระบุว่า เว้นแต่จะระบุไว้เป็นอย่างอื่น ผลลัพธ์ทั้งหมดของ Claude Opus 5.5 ใช้การคิดแบบปรับได้ที่ความพยายามสูงสุด ข้อยกเว้นคือ Terminal-Bench 4.0 ซึ่งรายงานที่ระดับ xhigh สำหรับ Claude Opus 5.5 และ high สำหรับ GPT-6 Astra เนื่องจากเป็นคะแนนสูงสุดของแต่ละโมเดล บนพื้นฐานนั้น ผู้จำหน่ายรายงาน Terminal-Bench 4.0 ที่ 66.4%, FrontierCode v1.1 Main ที่ 54.4%, CursorBench 4.0 ที่ 57.8%, GDPval-AA v2.1 ที่ 1,846 Elo, AutomationBench ที่ 40.0%, Humanity's Last Exam with tools ที่ 67.7%, Terminal-Bench-Science 0.1 ที่ 58.7%, OSWorld 2.0 ที่ 81.8% แบบบางส่วน และ Chartography with tools ที่ 89.0% ที่ความพยายามระดับปานกลางซึ่งเป็นค่าเริ่มต้นของโมเดล ผู้จำหน่ายให้ FrontierCode ที่ 54.6% และ CursorBench ที่ 52.5% สังเกตสิ่งที่บันทึกเดียวกันนี้เปิดเผยว่า การประเมินเหล่านี้รันโดยเปิดใช้มาตรการป้องกันสำหรับการใช้งานจริง และเมื่อมาตรการเหล่านั้นทำงาน งานด้านความปลอดภัยไซเบอร์ก็ดำเนินการเสร็จโดย Claude Opus 4.8 ส่วนงานด้านชีววิทยาและการพัฒนาหน่วย LLM ชั้นแนวหน้านั้นดำเนินการโดย Claude Opus 5 — Anthropic กล่าวว่าสิ่งนี้น่าจะลดประสิทธิภาพของ Claude Opus 5.5 ในเกณฑ์มาตรฐานเหล่านั้น ดังนั้นคะแนนที่เผยแพร่ในการประเมินที่ได้รับผลกระทบจึงไม่ใช่การวัดที่บริสุทธิ์ของโมเดลนี้

บทวิเคราะห์อิสระจาก Artificial Analysis บน Intelligence Index v4.3.2 Claude Opus 5.5 ได้คะแนน 58 ในคอนฟิกูเรชันที่ Artificial Analysis เรียกว่า "Adaptive Reasoning, Max Effort, Default Fallback" — เป็นคะแนนที่วัดได้สูงสุดของมัน โดยนำอยู่หลายพอยต์ และครองอันดับหนึ่งในหกจากสิบของการประเมินองค์ประกอบทั้งสิบ บนดัชนีเดียวกันและฮาร์เนสเดียวกัน Claude Fable 5.1 ได้ 53 และ Claude Opus 5 ได้ 51 Artificial Analysis เผยแพร่บันไดระดับความพยายามทั้งหมด ซึ่งเป็นชิ้นงานอิสระที่มีประโยชน์ที่สุดในที่นี้: max 58, xhigh 56, high 54, medium 51, low 42 การวัดของมันเองระบุว่า Claude Opus 5.5 ใช้เอาต์พุตโทเคนราว 119,000 โทเคนต่องานในดัชนีที่ระดับความพยายามสูงสุด เทียบกับราว 73,000 สำหรับ Claude Opus 5, 78,000 สำหรับ Claude Fable 5.1 และ 27,000 สำหรับ GPT-6 Astra — โทเคนที่ถูกคิดเงินในฐานะเอาต์พุตโทเคน — และหน้าของมันรายงานค่าใช้จ่าย $5.98 ต่องานในดัชนี นอกจากนี้ยังวัด Terminal-Bench 4.0 ได้ 59.6% และ Humanity's Last Exam ได้ 61.4% เทียบกับ 66.4% และ 67.7% ของผู้จำหน่ายที่ระดับความพยายามสูงสุดบนฮาร์เนสที่แตกต่างกัน

อ่านสองย่อหน้านั้นเทียบกันแล้ว ข้อสรุปที่ตรงไปตรงมาก็แคบ ผล Terminal-Bench 66.4% จากผู้ขายกับ 59.6% จากแหล่งอิสระคือ benchmark เดียวกันที่รันโดยคนละกลุ่ม ด้วยการตั้งค่าที่ไม่การันตีว่าจะตรงกัน และไม่มีอันใดเป็นหลักฐานเกี่ยวกับเวิร์กโหลดของคุณ บันไดระดับความพยายาม (effort ladder) ต่างหากคือข้อค้นพบที่ถ่ายโอนได้ บนดัชนีอิสระ การตั้งค่าของโมเดลนี้เองมีช่วงกว้างถึงสิบหกจุด ซึ่งกว้างกว่าช่องว่างระหว่างโมเดลนี้กับรุ่นก่อน การเลือกระดับความพยายามสำคัญกว่าการเลือกระหว่างโมเดลเหล่านี้ และข้อ "Default Fallback" ในป้ายกำกับนั้นคือการจัดเส้นทางแบบ safeguard ที่อธิบายไว้ข้างต้น ไม่ใช่ปรากฏการณ์เทียมที่เกิดจาก benchmark

ประสิทธิภาพตามที่ผู้ขายรายงาน โดยระบุแหล่งที่มา Anthropic ระบุว่า Claude Opus 5.5 ทำงานได้ในระดับเดียวกับ Claude Fable 5.1 ในงานส่วนใหญ่ โดยมีต้นทุนการใช้งานต่ำลงราว 40% และภาระงานทั่วไปมีต้นทุนต่ำกว่าเมื่อเทียบกับ Claude Opus 5 ประมาณ 40% เทียบกับราคาป้ายที่ลดลง 20% ส่วนผลลัพธ์ก็เร็วกว่าเดิมกว่า 30% ทั้งหมดนี้เป็นคำอธิบายลักษณะค่าเฉลี่ยจากภาระงานที่ผู้ขายเป็นผู้เลือกเอง คำกล่าวอ้างจากลูกค้าในช่วงเปิดตัวก็เป็นหลักฐานประเภทเดียวกัน: Box รายงานว่าใช้โทเคนเพียงหนึ่งในสาม และคำตอบกระชับน้อยลงราว 40% Kiro ใช้โทเคนราวครึ่งหนึ่ง และเรียกใช้งานน้อยลงราว 40% Factory ใช้โทเคนเอาต์พุตน้อยลง 20–25% ส่วน GitHub อยู่ในกลุ่มที่ใช้โทเคนและจำนวนขั้นตอนน้อยที่สุดเท่าที่เคยวัดมา Anthropic ยังรายงานการทดสอบตรวจสอบข้อเท็จจริงภายใน ซึ่งรายงาน 16 จาก 18 ฉบับผ่านเกณฑ์คุณภาพที่ทั้ง Claude Fable 5.1 และ Claude Opus 5 ไม่เคยผ่านได้แม้แต่ครั้งเดียว ทั้งหมดนี้เป็นข้อมูลที่ผู้ขายรายงานเอง และไม่มีส่วนใดผ่านการตรวจสอบ ข้อจำกัดที่เปิดเผยไว้นั้นตรงไปตรงมาอย่างผิดปกติและน่าจดจำ: Anthropic กล่าวว่า Claude Opus 5.5 "มักสงสัยว่าตนกำลังถูกประเมินอยู่"

สุดท้ายนี้ รุ่นพี่น้อง: Anthropic กล่าวว่า Claude Sonnet 5.5 และ Claude Haiku 5.5 จะมาถึง "ในอีกไม่กี่สัปดาห์ข้างหน้า" ทั้งคู่ยังไม่เปิดให้ใช้งาน ยังไม่มีการกำหนดราคา และยังไม่ปรากฏบนแพลตฟอร์มใด ๆ ในวันนี้

ทดสอบการเปลี่ยนแปลงทั้งสี่รายการโดยไม่ต้องทำการตัดเปลี่ยนระบบแบบเต็มรูปแบบ

ความเสี่ยงของการโยกย้ายในที่นี้ไม่ใช่เรื่องคุณภาพ — แต่เป็นเรื่องที่ว่าเส้นทางโค้ดที่คุณไม่เคยทดสอบในสภาพแวดล้อม staging คือเส้นทางที่ส่งคืน 400 ในโปรดักชัน การเปลี่ยนแปลงที่ทำให้ระบบเดิมใช้งานไม่ได้ทั้งสี่รายการล้วนเป็นการเปลี่ยนแปลงรูปร่างของคำขอ ซึ่งหมายความว่ามันจะล้มเหลวอย่างแน่นอนและทันที และวิธีเดียวที่จะค้นหาเส้นทางที่คุณมองข้ามไปคือการปล่อยทราฟฟิกจริงให้ไหลผ่านเส้นทางเหล่านั้น

Claude Opus 5.5 พร้อมใช้งานบน OrcaRouter ในชื่อ anthropic/claude-opus-5.5 ในราคาตามที่ Anthropic ประกาศเอง โดยบวกเพิ่ม 0% — ราคาที่ผู้ให้บริการประกาศไว้ถูกส่งต่อโดยตรง ดังนั้นหากผู้ให้บริการเปลี่ยนราคา ที่นี่จะอัปเดตให้ทันทีภายในวันเดียวกัน

สิ่งนี้ช่วยให้คุณกำหนดเปอร์เซ็นต์ของทราฟฟิกโปรดักชันให้ชี้ไปที่โมเดลนั้น ขณะที่ส่วนที่เหลือยังคงทำงานบน Claude Opus 5 ดูว่าคำขอใดล้มเหลวและเพราะเหตุใด แล้วแก้ไขทีละรายการ ข้อผิดพลาดทั้งสี่อธิบายตัวเองได้: แต่ละข้อระบุชื่อพารามิเตอร์ที่มันปฏิเสธ และในสามจากสี่กรณี ยังระบุสิ่งที่ใช้แทนด้วย การสลับไปใช้ระบบสำรองอัตโนมัติช่วยอุดช่องว่างในระหว่างที่เส้นทางยังเสียอยู่ — คำขอที่ล้มเหลวกับโมเดลที่คุณยังไม่ได้ระบุคุณลักษณะอย่างครบถ้วนจะสลับไปใช้โมเดลที่คุณมีข้อมูลอยู่แล้ว แทนที่จะแสดงข้อผิดพลาด 400 ให้ผู้ใช้เห็น

ลำดับการทำงานที่ใช้ได้จริง: เริ่มจากสลับ model id และกำหนด effort อย่างชัดเจนก่อน เนื่องจากค่าเริ่มต้นเปลี่ยนไปเป็น medium แล้ว; จากนั้นตัดพาธ thinking-disabled และ forced-tool-choice ออก; แล้วจึงแก้ streaming reader — การเลือกบล็อกตามประเภท และการตั้งค่า thinking.display — เพราะนั่นคือส่วนที่ล้มเหลวแบบเงียบ ๆ มากกว่าแบบส่งเสียงดัง; และเก็บการย้ายชุดเครื่องมือ computer-use ไว้เป็นลำดับสุดท้าย หากคุณอยู่บน Bedrock เนื่องจากนั่นคือสิ่งเดียวที่ไม่ใช้กับที่นั่น ส่วนอื่น ๆ ทั้งหมด — ราคา, context window, อัตราแคช และค่าเริ่มต้น 1M โทเคน — ยังอยู่ที่เดิมที่คุณวางไว้แล้ว

กำหนดเส้นทางส่วนหนึ่งของทราฟฟิกจริงไปยังโมเดลใหม่โดยไม่ต้องสลับทั้งหมด: Claude Opus 5.5 บน OrcaRouter ให้บริการในราคาตามประกาศของ Anthropic พร้อมการสลับไปยังโมเดลสำรองที่คุณได้ประเมินคุณลักษณะไว้แล้วโดยอัตโนมัติ