การย้ายจาก Claude Opus 5 ไปยัง Opus 5.5: สิ่งที่เปลี่ยนแปลงสำหรับผู้เรียกใช้ API

Anthropic เปิดตัว Claude Opus 5.5 เมื่อวันที่ 22 กันยายน 2026 สำหรับใครก็ตามที่เรียกใช้ Claude API การอัปเกรดคือสตริงเดียว: claude-opus-5 กลายเป็น claude-opus-5-5

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

สิ่งที่อยู่เบื้องหลังสตริงนั้นคือราคาถูกลง 20% ต่อโทเคนในทั้งสองทิศทาง จำกัดการตอบกลับเดียวไว้ที่ 128,000 เอาต์พุตโทเคน อ้างว่าผลิตเอาต์พุตเร็วขึ้น 30% และถูกสร้างมาให้ทำงานเดียวต่อเนื่องได้ 18 ชั่วโมงหรือมากกว่า ไม่มีสิ่งใดในนั้นที่ไม่มีผลตามมาสำหรับโค้ดที่คุณปรับแต่งให้เข้ากับ Opus 5

นี่คือการโยกย้ายครั้งที่สองบนสายโมเดลนี้ และอ่านไม่เหมือนครั้งแรกเลย Opus 4.8 ถึง Opus 5 เป็นการโยกย้ายเพื่อความถูกต้อง: ค่าเริ่มต้นเลื่อนไปข้างใต้โค้ดที่ทำงานอยู่ และชุดคำขอที่เคยถูกต้องชุดหนึ่งเริ่มส่งคืน 400 แบบแข็ง การโยกย้ายครั้งนี้เป็นการโยกย้ายด้านงบประมาณและขอบเขตการดำเนินงาน งานอยู่ที่การวัดตัวเลขที่คุณเคยวัดไปแล้วครั้งหนึ่งใหม่ เพราะทุกตัวเลขขยับหมด Opus 5.5 ยังเปิดตัววันเดียวกับโมเดล OpenAI ใหม่สองรุ่น ซึ่งเป็น เรื่องของมันเอง

ส่วนต่าง ในเฉพาะเซลล์ที่เราหาแหล่งอ้างอิงได้

รายการ	Opus 5	Opus 5.5	การเปลี่ยนแปลง
รหัสโมเดล	claude-opus-5	claude-opus-5-5	หนึ่งสตริง
อินพุต ต่อล้านโทเคน	$5.00	$4.00	ลดลง 20%
เอาต์พุต ต่อล้านโทเคน	$25.00	$20.00	ลดลง 20%
การเขียนแคช ต่อล้าน	ตรวจสอบหน้าผู้ให้บริการ	$5.00	ไม่ทราบ
การอ่านแคช ต่อล้าน	ตรวจสอบหน้าผู้ให้บริการ	$0.20	ไม่ทราบ
โหมดเร็ว ต่อล้าน	ตรวจสอบหน้าผู้ให้บริการ	$8.00 อินพุต, $40.00 เอาต์พุต	ไม่ทราบ
จำนวนเอาต์พุตโทเคนสูงสุด	ตรวจสอบหน้าผู้ให้บริการ	128,000	ไม่ทราบ
หน้าต่างบริบท	ตรวจสอบหน้าผู้ให้บริการ	1,000,000	ไม่ทราบ

ช่องว่างเหล่านั้นตั้งใจเว้นไว้ Anthropic เผยแพร่ฝั่ง Opus 5.5 บนหน้ารุ่นโมเดลของตน และเราจะไม่สร้างฝั่ง Opus 5 ขึ้นใหม่จากความจำ เพราะตัวเลขที่ผิดในโมเดลต้นทุนแย่กว่าตัวเลขที่หายไป ดึงห้าแถวนั้นจากหน้าค่าบริการของ Anthropic ก่อนที่คุณจะสร้างประมาณการประหยัดจากมัน

1. การเปลี่ยน id เป็นเรื่องจริง 20% เป็นเรื่องจริง 40% ต้องอ่านให้ดี

สลับสตริงแล้วคุณจ่ายถูกลง 20% ต่อโทเคนในทั้งสองทิศทาง ส่วนนั้นเป็นเลขคณิต: $5 เป็น $4 สำหรับอินพุต, $25 เป็น $20 สำหรับเอาต์พุต, ลดลงเท่ากันทั้งสองด้าน

Anthropic ยังกล่าวว่า Opus 5.5 มีต้นทุนการรันต่ำกว่า Opus 5 40% ตัวเลขสองตัวนั้นไม่ได้ขัดแย้งกัน แต่ก็ไม่ใช่ข้ออ้างเดียวกัน การลด 20% ต่อโทเคนไม่สามารถสร้างการลดบิล 40% ได้ด้วยตัวมันเอง อีกครึ่งหนึ่งต้องมาจากโมเดลที่ใช้โทเคนน้อยลงเพื่อทำงานเดียวกันให้เสร็จ และประสิทธิภาพโทเคนนั้นขึ้นอยู่กับภาระงานโดยเฉพาะ ในแบบที่แผ่นราคาไม่ใช่

ดังนั้นจงมอง 40% เป็นเหตุผลให้วัดใหม่ มากกว่าจะเป็นตัวเลขสำหรับใส่ลงในพยากรณ์ เล่นซ้ำส่วนตัวแทนของทราฟฟิกจริงเมื่อสัปดาห์ที่แล้วกับทั้งสอง model id ด้วยพรอมป์และการตั้งค่าเดียวกัน เปรียบเทียบบล็อก usage แทนความประทับใจของคุณเกี่ยวกับมัน แล้วคูณจำนวนโทเคนจริงด้วยอัตราใหม่ คำตอบของคุณจะตกอยู่ระหว่าง 20% ถึง 40% และตำแหน่งที่มันตกจะบอกสิ่งที่มีประโยชน์เกี่ยวกับว่าพรอมป์ของคุณส่วนไหนที่ไม่จำเป็นตั้งแต่แรก

2. รายการแคชคือการเปลี่ยนแปลงราคาที่ใหญ่ที่สุดในตาราง

การอ่านแคชบน Opus 5.5 มีราคา $0.20 ต่อล้านโทเคน เทียบกับ $4.00 สำหรับอินพุตใหม่ ซึ่งเป็นส่วนลด 95% การเขียนแคชมีราคา $5.00 ต่อล้าน แพงกว่า $1.00 เมื่อเทียบกับ $4.00 ที่คุณจะจ่ายเพื่อส่งโทเคนเหล่านั้นโดยไม่แคช

ส่วนต่างที่แพงขึ้นนั้นคืนทุนตั้งแต่การเข้าถึงแคชครั้งแรก และยังเหลือทอน การเขียนคำนำหน้ามีต้นทุนมากกว่าการไม่แคชมัน $1.00 ต่อล้าน การอ่านคำนำหน้านั้นในภายหลังแต่ละครั้งประหยัด $3.80 ต่อล้าน คุณคุ้มทุนที่ประมาณหนึ่งในสี่ของการอ่านซ้ำหนึ่งครั้ง ซึ่งในทางปฏิบัติหมายความว่า: ถ้าคำนำหน้านั้นถูกใช้ซ้ำแม้เพียงครั้งเดียว การแคชมันก็ถูกต้องแล้ว

นี่คือหน้าตาบน system prompt ขนาด 200,000 โทเคน ซึ่งเป็นขนาดปกติเมื่อคุณวางชุดสเปก OpenAPI ลงไป:

รูปแบบ	ต้นทุนสำหรับ 10 การเรียก
อินพุตใหม่ทุกครั้ง, $4.00/M	$8.00
เขียนครั้งเดียวที่ $5.00/M จากนั้นอ่าน 9 ครั้งที่ $0.20/M	$1.36

พรอมป์เดียวกัน โมเดลเดียวกัน ลดลง 83% คำขอที่ทำให้คุณได้แถวที่สองจะทำเครื่องหมายคำนำหน้าอย่างชัดเจน:

{
  "model": "claude-opus-5-5",
  "max_tokens": 4096,
  "system": [
    {
      "type": "text",
      "text": "<your 200k-token spec bundle>",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "Which endpoints changed between v2 and v3?"}
  ]
}

จากนั้นอ่านการตอบกลับเพื่อยืนยันว่าคุณได้ hit เพราะแคชที่คุณคิดว่ามีแต่กลับไม่มีคือชนิดที่แพงที่สุด:

"usage": {
  "input_tokens": 41,
  "cache_creation_input_tokens": 204800,
  "cache_read_input_tokens": 0,
  "output_tokens": 612
}

ในการเรียกครั้งแรก cache_creation_input_tokens เป็นตัวรับภาระ ในการเรียกทุกครั้งหลังจากนั้น ตัวเลขนั้นควรลดลงเหลือศูนย์ และ cache_read_input_tokens ควรรับช่วงต่อ ถ้ามันไม่เป็นเช่นนั้น แสดงว่ามีบางอย่างต้นทางกำลังเปลี่ยนแปลงคำนำหน้าของคุณ โดยปกติคือ timestamp, request id หรือรายการเครื่องมือที่ถูกจัดลำดับใหม่ การบันทึกหนึ่งการเรียกใน Apidog แล้วยิงสองครั้งเป็นวิธีที่เร็วที่สุดในการดูว่าสองฟิลด์ใดขยับ เลขคณิตเต็มรูปแบบ รวมถึงว่าเมื่อใดที่บริบท 1M คุ้มค่าที่จะแคชเลย อยู่ใน คณิตศาสตร์ต้นทุนแคชของ Opus 5.5

3. การตอบกลับ 128,000 โทเคนเป็นปัญหาฝั่งไคลเอนต์ก่อนที่จะเป็นปัญหาของโมเดล

Opus 5.5 จะส่งคืนเอาต์พุตโทเคนได้สูงสุด 128,000 ในการตอบกลับหนึ่งครั้ง ที่ $20 ต่อล้าน นั่นคือ $2.56 สำหรับการเรียกครั้งเดียวที่เต็มเพดาน ซึ่งคุ้มค่าที่จะรู้ก่อนที่ใครบางคนจะตั้ง max_tokens ไว้ที่เพดานในลูป retry

ปัญหาที่ใหญ่กว่านั้นคือทุกสิ่งระหว่างโมเดลกับโค้ดของคุณ:

• HTTP read timeouts. การตอบกลับที่ยาวขนาดนั้นใช้เวลาหลายนาที ไม่ใช่ไม่กี่วินาที ค่า timeout เริ่มต้นของไคลเอนต์ใน SDK และ reverse proxy ส่วนใหญ่สั้นกว่านั้น
• บัฟเฟอร์ของพร็อกซีและเกตเวย์ เกตเวย์ที่บัฟเฟอร์ทั้ง body ก่อนส่งต่อจะถือข้อมูลหลายเมกะไบต์ต่อคำขอที่กำลังดำเนินอยู่ และบางตัวจะตัดการเชื่อมต่อทิ้งเลย
• การเรียกแบบไม่สตรีม หากไม่สตรีม คุณจะรอตลอดเวลาโดยไม่มีอะไรให้ดูและไม่มีจุดให้บันทึกความคืบหน้า
• JSON ที่ถูกตัดทอน การชน max_tokens กลางออบเจ็กต์จะสร้าง JSON ที่ไม่ถูกต้อง ไม่ใช่ออบเจ็กต์บางส่วนที่คุณกอบกู้ได้ ตรวจสอบ stop_reason ก่อนที่คุณจะ parse

การเพิ่ม max_tokens เพราะเพดานสูงขึ้นเป็นครึ่งที่ง่าย การทำให้ห่วงโซ่ timeout, บัฟเฟอร์ และ parser ของคุณสอดคล้องกับเพดานใหม่คือครึ่งที่ก่อให้เกิดเหตุการณ์

4. เอาต์พุตที่เร็วขึ้นไม่ได้หมายความว่ารอสั้นลง

Anthropic ระบุว่า Opus 5.5 ผลิตเอาต์พุตเร็วขึ้น 30% เมื่อเทียบกับ Opus 5 ความเร็วเอาต์พุตเป็นเพียงหนึ่งพจน์ในเวลาแฝงที่คุณให้บริการจริง เวลาถึงโทเคนแรก การ retry และการเข้าคิวก็อยู่ร่วมด้วย และโมเดลที่สตรีมเร็วขึ้นอาจยังรู้สึกช้ากว่าได้ถ้ามันคิดนานขึ้นก่อนที่โทเคนแรกจะมาถึง

ดังนั้นจงวัดมัน ยิงชุดพรอมป์ตัวแทนที่กำหนดตายตัวไปยังทั้งสอง model id จากตำแหน่งเครือข่ายเดียวกัน แล้วบันทึก p50 และ p95 แยกกันสำหรับเวลาถึงโทเคนแรกและเวลารวม เวลาแฝงเฉลี่ยซ่อนกรณีที่ทำให้คุณถูกเรียกตัว

ถ้าคุณเก็บสถานการณ์ทดสอบ API ไว้ใน Apidog นี่เป็นงานเล็ก: โคลนคำขอที่บันทึกไว้หนึ่งอัน เปลี่ยน model id รันทั้งสองตามกำหนดเวลา และอ่านอนุกรมเวลาของเวลาตอบกลับ แทนที่จะใช้นาฬิกาจับเวลา ประเด็นคือการเข้าสู่การโยกย้ายด้วยตัวเลขก่อนเปลี่ยน เพราะหลังจากคุณสลับไปใช้แล้ว จะไม่มีทางได้มันมา

5. โหมดเร็วคือสองเท่าของราคาปกติพอดี

โหมดเร็วบน Opus 5.5 มีราคา $8.00 ต่อล้านอินพุตและ $40.00 ต่อล้านเอาต์พุต เมื่อวางเทียบกับราคามาตรฐาน $4.00 และ $20.00 กฎการตั้งราคานี้ง่ายพอจะจำได้: โหมดเร็วคือ 2x ตรง ๆ ทั้งสองด้าน

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

6. มองตาราง benchmark เป็นเหตุผลให้ทดสอบ ไม่ใช่เป็นผลลัพธ์

ตัวเลขที่ Anthropic เผยแพร่สำหรับ Opus 5.5 นั้นแข็งแกร่ง: Terminal-Bench 4.0 อยู่ที่ 66.4%, FrontierCode v1.1 อยู่ที่ 54.4%, CursorBench 4.0 อยู่ที่ 57.8%, GDPval-AA v2.1 อยู่ที่ 1846 Elo, AutomationBench อยู่ที่ 40.0%, Humanity’s Last Exam อยู่ที่ 67.7% เมื่อใช้เครื่องมือ, OSWorld 2.0 อยู่ที่ 81.8% และ Chartography อยู่ที่ 89.0% Artificial Analysis ซึ่งเป็นบุคคลที่สามไม่ใช่ผู้ขายรายใดรายหนึ่ง จัดให้มันเป็นอันดับหนึ่งจาก 212 โมเดลบนดัชนีของตนด้วยคะแนน 58

ข้ออ้างจากผู้ขายอีกสองข้อมีความสำคัญในเชิงปฏิบัติมากกว่าเชิงแข่งขัน Opus 5.5 ถูกสร้างมาให้อยู่กับงานเดียวได้ 18 ชั่วโมงหรือมากกว่า ซึ่งทำลายสมมติฐานทั่วไปหลายอย่างเกี่ยวกับ timeout, retry และความสามารถในการทำงานต่อจากเดิม และ Anthropic รายงานว่าความพยายามหลบเลี่ยงขอบเขตที่สำเร็จลดลง 85% ซึ่งเป็น คุณสมบัติที่ทดสอบได้ของ endpoint ของคุณเอง มากกว่าจะเป็นคุณสมบัติที่คุณได้รับมาพร้อมกัน

ไม่มีสิ่งใดในนี้บอกคุณว่า Opus 5.5 ดีกว่าบนพรอมป์ของคุณหรือไม่ จงรันชุด eval ของคุณเองกับทั้งสอง id ก่อนจะสลับโปรดักชันไปใช้ ด้วยเหตุผลเดียวกับที่คุณจะไม่ปล่อยอัปเกรดฐานข้อมูลโดยอาศัยตัวเลข benchmark ของผู้ขาย

รายการตรวจสอบการโยกย้าย

1. เปลี่ยน claude-opus-5 เป็น claude-opus-5-5 ในบริการเดียว ไม่ใช่ทั้งหมด
2. อ่านคู่มือการโยกย้ายของ Anthropic สำหรับการขยับครั้งนี้ ก่อนสันนิษฐานว่าพื้นผิวพารามิเตอร์ไม่เปลี่ยนแปลง การกระโดดจาก 4.8 ไป 5 ย้ายค่าเริ่มต้นอย่างเงียบ ๆ ดังนั้นจงตรวจสอบแทนการอนุมาน
3. เล่นซ้ำทราฟฟิกจริงส่วนหนึ่งกับทั้งสอง id และ diff บล็อก usage
4. คำนวณค่าใช้จ่ายรายเดือนใหม่ที่ $4 และ $20 และแยกที่การเขียนแคช $5 กับการอ่านแคช $0.20
5. ยืนยัน cache hit ใน cache_read_input_tokens แทนการเชื่อว่าคำนำหน้านั้นเสถียร
6. เพิ่ม HTTP read timeout และตรวจสอบบัฟเฟอร์เกตเวย์ก่อนที่ใครจะตั้ง max_tokens ใกล้ 128,000
7. บันทึกเวลาแฝง p50 และ p95 บนทั้งสอง id ก่อนที่คุณจะสลับไปใช้
8. ตัดสินใจใช้โหมดเร็วเป็นรายเส้นทาง ที่ 2x ของราคาปกติ
9. รันชุด eval ของคุณเองอีกครั้ง benchmark ของผู้ขายเป็นเหตุผลให้ทดสอบ ไม่ใช่ตัวการทดสอบ

Opus 5.5 เป็นเวอร์ชันที่ถูกกว่า เร็วกว่า และรันได้นานกว่าของโมเดลที่คุณเรียกใช้อยู่แล้ว ความเสี่ยงในการโยกย้ายไม่ใช่การเปลี่ยนสตริงจะล้มเหลว แต่คือคุณยกโมเดลต้นทุน, timeout และค่า max_tokens ที่ถูกกำหนดขนาดไว้สำหรับโมเดลอื่นติดมาด้วย

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

claude-opus-5-5 เป็นตัวแทนที่ใส่แทนได้ทันทีสำหรับ claude-opus-5 หรือไม่? จงปฏิบัติกับมันเช่นนั้นเฉพาะหลังจากตรวจสอบคู่มือการโยกย้ายของ Anthropic สำหรับการขยับครั้งนี้แล้ว การเปลี่ยน id เป็นการแก้ไขบรรทัดเดียว แต่การขยับครั้งก่อนบนสายนี้ย้ายค่าเริ่มต้นโดยไม่เปลี่ยนรูปทรงคำขอ ดังนั้นการตรวจสอบจึงเป็นประกันราคาถูก

Opus 5.5 ถูกกว่าแค่ไหน? ถูกลง 20% ต่อโทเคนในทั้งสองทิศทาง, $5 เป็น $4 สำหรับอินพุต และ $25 เป็น $20 สำหรับเอาต์พุต Anthropic ระบุแยกต่างหากว่าลดต้นทุนการรันลง 40% ซึ่งสื่อถึงประสิทธิภาพโทเคนที่ดีขึ้นบนอัตราที่ลดลง จงวัดภาระงานของคุณเองเพื่อดูว่าคุณตกอยู่ตรงไหนระหว่างสองตัวเลขนั้น

prompt caching บน Opus 5.5 มีค่าใช้จ่ายเท่าไร? การเขียนอยู่ที่ $5.00 ต่อล้านโทเคน และการอ่านอยู่ที่ $0.20 ต่อล้าน เทียบกับ $4.00 สำหรับอินพุตที่ไม่แคช การใช้คำนำหน้าที่แคชซ้ำหนึ่งครั้งก็มากกว่าคุ้มกับส่วนต่างราคาการเขียนแล้ว

ขีดจำกัดเอาต์พุต 128,000 โทเคนเปลี่ยนอะไรในไคลเอนต์ของฉันหรือไม่? โดยปกติใช่ ตรวจสอบ HTTP read timeout, การบัฟเฟอร์ของเกตเวย์ และว่าคุณสตรีมหรือไม่ ตรวจสอบ stop_reason ก่อน parse ด้วย เพราะการชนเพดานกลางออบเจ็กต์สร้าง JSON ที่ไม่ถูกต้อง ไม่ใช่ออบเจ็กต์ที่ถูกตัดทอน