อัปเกรด Claude Opus 4.8 ไป 5: ทุกการเปลี่ยนแปลงที่ต้องแก้ไขโค้ด

การเปลี่ยน claude-opus-4-8 เป็น claude-opus-5 ดูเหมือนเป็นการแก้ไขเพียงบรรทัดเดียว และส่วนใหญ่ก็เป็นเช่นนั้น แต่ค่าเริ่มต้นบางอย่างเปลี่ยนไปโดยที่ JSON เดิมของคุณไม่เปลี่ยน คำขอที่เคยถูกต้องบางชุดจะกลายเป็น HTTP 400 และฟีเจอร์ที่ทีมองค์กรใช้งานอยู่ไม่รองรับในโมเดลใหม่

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

Anthropic เปิดตัว Claude Opus 5 เมื่อวันที่ 24 กรกฎาคม 2026 ด้วยราคาเดียวกับ Opus 4.8: 5 ดอลลาร์ต่อล้านโทเค็นอินพุต และ 25 ดอลลาร์ต่อล้านโทเค็นเอาต์พุต ดังนั้นการย้ายครั้งนี้ไม่ใช่การตัดสินใจเรื่องงบประมาณ แต่เป็นเรื่องความถูกต้องของ integration บทความนี้สรุปความแตกต่างที่อาจทำให้ระบบพัง พร้อมตัวอย่างคำขอที่คัดลอกไปทดสอบได้ทันที อ้างอิง API surface จาก คู่มือการย้ายจาก Opus 4.8 ไป Opus 5 ของ Anthropic และควรบันทึกคำขอจริงใน Apidog เพื่อโคลนเปรียบเทียบแต่ละเวอร์ชันก่อน deploy

เวอร์ชันย่อ

การเปลี่ยนแปลง	ผลกระทบ	การดำเนินการ
Thinking เปิดใช้งานโดยค่าเริ่มต้น	เอาต์พุตอาจถูกตัดทอน	เพิ่ม max_tokens
thinking: disabled + effort xhigh / max	HTTP 400	เลือกอย่างใดอย่างหนึ่ง
ระดับ effort ถูกปรับเทียบใหม่	ต้นทุน/คุณภาพเปลี่ยน	ทดสอบใหม่ทั้งหมด
บริบท 1M ไม่ต้องใช้ beta header	Header ซ้ำซ้อน	ลบออก
แคชขั้นต่ำลดเหลือ 512 โทเค็น	ประหยัดได้เพิ่ม	เพิ่มจุดแคชในพรอมต์
System message กลางบทสนทนา	จากเดิม 400 กลายเป็นใช้ได้	ลด workaround ได้
Priority Tier	ไม่รองรับบน Opus 5	คง Opus 4.8 สำหรับทราฟฟิกนั้น
Fast mode	ใช้ได้บน Opus 5	ใช้สำหรับเส้นทาง interactive
fallbacks: "default"	รองรับ cyber-refusal fallback	เปิดใช้แบบเลือกได้
Sampling params, token counts	ไม่เปลี่ยน	ไม่ต้องแก้

1. Thinking เปิดใช้โดยค่าเริ่มต้น และ max_tokens ยังจำกัดทุกอย่าง

นี่คือการเปลี่ยนแปลงที่ทำให้โค้ดเดิมพังแบบเงียบ ๆ

ใน Opus 4.8 คำขอที่ไม่มีฟิลด์ thinking จะทำงานโดยไม่มีการคิด แต่ใน Opus 5 คำขอเดียวกันจะใช้ adaptive thinking โมเดลอาจใช้โทเค็นเพื่อให้เหตุผลก่อนสร้างคำตอบที่มองเห็นได้

ประเด็นสำคัญคือ max_tokens ยังคงเป็นเพดานรวมของโทเค็น thinking และโทเค็นคำตอบ ดังนั้นคำขอที่เคยพอดีกับงบประมาณ 1,024 โทเค็น อาจใช้เกือบทั้งหมดไปกับ thinking แล้วส่งคำตอบที่ถูกตัดทอนกลับมา

คำขอเดิมที่เคยปลอดภัย:

{
  "model": "claude-opus-4-8",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Summarize this incident report in three bullets."
    }
  ]
}

หากเปลี่ยนเฉพาะ model ID คุณอาจได้เอาต์พุตไม่ครบ ให้เพิ่มงบประมาณก่อน:

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "messages": [
    {
      "role": "user",
      "content": "Summarize this incident report in three bullets."
    }
  ]
}

หลังปรับ max_tokens ให้ตรวจสอบ 2 ค่าใน response:

1. stop_reason
   • max_tokens หมายถึงเอาต์พุตถูกตัด
   • end_turn หมายถึงโมเดลตอบเสร็จสมบูรณ์
2. usage เพื่อวัดว่า thinking ใช้โทเค็นจริงเท่าไรในพรอมต์ของคุณ

กำหนดงบประมาณจากการวัดผลจริง ไม่ใช่การเดา

หากต้องการพฤติกรรมแบบไม่มี thinking ให้ระบุชัดเจน:

"thinking": {
  "type": "disabled"
}

แต่ต้องอ่านหัวข้อถัดไปก่อน เพราะค่านี้มีข้อจำกัดเมื่อใช้ร่วมกับ effort

2. HTTP 400: ปิด thinking ร่วมกับ effort ระดับ xhigh หรือ max

ใน Opus 5 การใช้ค่าต่อไปนี้พร้อมกันจะส่งคืน HTTP 400:

• thinking: {"type": "disabled"}
• output_config.effort: "xhigh" หรือ "max"

คำขอที่ล้มเหลว:

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "thinking": {
    "type": "disabled"
  },
  "output_config": {
    "effort": "xhigh"
  },
  "messages": [
    {
      "role": "user",
      "content": "Refactor this module and explain the tradeoffs."
    }
  ]
}

เหตุผลคือ effort ระดับสูงสุดออกแบบมาเพื่อเพิ่ม thinking การขอ effort สูงสุดพร้อมปิด thinking จึงขัดแย้งกัน

วิธีแก้ A: ต้องการคุณภาพและสมรรถนะ

ลบ thinking ออก แล้วคง effort ระดับสูงไว้ เหมาะกับงานเขียนโค้ดและ agentic workflow:

{
  "model": "claude-opus-5",
  "max_tokens": 32000,
  "output_config": {
    "effort": "xhigh"
  },
  "messages": [
    {
      "role": "user",
      "content": "Refactor this module and explain the tradeoffs."
    }
  ]
}

วิธีแก้ B: ต้องการปิด thinking

สำหรับเส้นทางที่ไวต่อความหน่วงแฝง ให้ปิด thinking และลด effort เป็น high หรือต่ำกว่า:

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "thinking": {
    "type": "disabled"
  },
  "output_config": {
    "effort": "high"
  },
  "messages": [
    {
      "role": "user",
      "content": "Classify this ticket into one of five categories."
    }
  ]
}

อย่างไรก็ตาม Anthropic ระบุว่าการปิด thinking อาจทำให้เกิดผลข้างเคียงเป็นครั้งคราว เช่น

• tool call ถูกพิมพ์เป็นข้อความธรรมดาแทนการถูกเรียกใช้
• แท็กภายในอย่าง <thinking> รั่วออกมาในเอาต์พุต
• เอาต์พุตที่รั่วอาจทำให้เทิร์นถัดไปใน agent loop เสีย

ดังนั้นสำหรับ workflow แบบ agentic ควรเปิด thinking ไว้ แล้วควบคุมต้นทุนด้วย effort ที่ต่ำกว่าแทน

3. ระดับ effort ถูกปรับเทียบใหม่: ทดสอบใหม่ อย่าคัดลอกค่าเดิม

Opus 5 มีค่าเริ่มต้นเป็น effort ระดับ high และแต่ละระดับได้รับการปรับเทียบใหม่ โดยเฉพาะ low และ medium ซึ่งมีความสามารถมากขึ้นเมื่อเทียบกับ Opus รุ่นก่อน

อย่านำค่าจาก Opus 4.8 มาใช้ทันที เพราะจุดต้นทุน/คุณภาพเดิมอาจไม่เท่ากัน:

• งานที่เคยต้องใช้ high หรือ xhigh บน Opus 4.8 อาจทำงานได้ดีที่ medium บน Opus 5
• งานที่ใช้ low เพื่อลดต้นทุน อาจคุ้มค่าที่จะเพิ่ม effort เพราะคุณภาพต่อโทเค็นดีขึ้น

สำหรับงานเขียนโค้ดและ agentic task ที่มีขอบเขตยาว xhigh ยังเป็นจุดเริ่มต้นที่แนะนำ โดยควรจับคู่กับ max_tokens ที่มากพอ เช่น 64k สำหรับการทดสอบระดับสูงสุด

ทดสอบกับ evaluation set ของคุณเอง โดยคงพรอมต์เดิม เปลี่ยนเฉพาะ effort แล้วบันทึก:

• คุณภาพเอาต์พุต
• latency
• ค่าใน usage
• อัตราการตัดทอนจาก stop_reason

อ่านรายละเอียดเพิ่มเติมได้ที่ การเจาะลึกพารามิเตอร์ effort และ รายละเอียดราคา Opus 5

4. ลบ Long-context beta header ออก

Opus 5 มี context window 1M โทเค็นเป็นทั้งค่าเริ่มต้นและค่าสูงสุด จึงไม่ต้องใช้ beta header เพื่อเปิด long context และไม่มีค่าพรีเมียมสำหรับการใช้บริบทยาว

หาก HTTP client ของคุณยังส่ง extended-context beta ใน anthropic-beta จากการตั้งค่า Opus 4.8 ให้ลบออก เพราะเป็น header ที่ไม่จำเป็นและอาจสร้างปัญหาในการ debug ภายหลัง

ข้อจำกัดเอาต์พุต:

• Messages API: สูงสุด 128k โทเค็น
• Batch API: สูงสุด 300k โทเค็น โดยใช้ beta header output-300k-2026-03-24

header สำหรับ 300k output เป็นคนละเรื่องกับ context window 1M

5. แคชขั้นต่ำสำหรับพรอมต์ลดเหลือ 512 โทเค็น

ใน Opus 4.8 ส่วนของพรอมต์ต้องมีอย่างน้อย 1,024 โทเค็นจึงจะแคชได้ แต่ Opus 5 ลดขั้นต่ำเหลือ 512 โทเค็น

โค้ดเดิมไม่จำเป็นต้องเปลี่ยน และ cache read มีราคา 0.50 ดอลลาร์ต่อล้านโทเค็น เทียบกับอินพุตปกติ 5 ดอลลาร์ต่อล้านโทเค็น

ให้ตรวจสอบส่วนต่อไปนี้ที่มีขนาดระหว่าง 512–1,024 โทเค็น:

• system prompt
• tool definitions
• few-shot examples
• policy หรือ instruction block ที่ใช้ซ้ำ

หากส่วนเหล่านี้ใช้ซ้ำ ให้พิจารณาเพิ่ม cache_control และตรวจผลจาก response:

{
  "usage": {
    "cache_read_input_tokens": 0
  }
}

สำหรับคำขอครั้งที่สองที่ใช้พรอมต์เดิม cache_read_input_tokens ควรมีค่ามากกว่า 0

ดูแนวทางเพิ่มเติมได้ที่ คู่มือการลดค่า API ของ Claude

6. System messages ระหว่างการสนทนาใช้ได้แล้ว

Opus 4.8 ปฏิเสธ {"role": "system"} ที่อยู่ภายในอาร์เรย์ messages ด้วย HTTP 400 แต่ Opus 5 รองรับ

หากเดิมคุณรวมคำสั่งใหม่เข้าไปในข้อความ user แบบสังเคราะห์ ตอนนี้สามารถใส่ system message ในตำแหน่งที่ถูกต้องได้:

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "messages": [
    {
      "role": "user",
      "content": "Draft the release note."
    },
    {
      "role": "assistant",
      "content": "Here is a first draft..."
    },
    {
      "role": "system",
      "content": "From here on, keep responses under 150 words."
    },
    {
      "role": "user",
      "content": "Tighten it."
    }
  ]
}

ความสามารถนี้ขึ้นกับโมเดล หากส่ง conversation history เดียวกันไปยัง Opus 4.8 โมเดลเก่ายังคงส่ง HTTP 400

7. Priority Tier ไม่รองรับบน Opus 5

Opus 4.8 รองรับ Priority Tier แต่ Opus 5 ไม่รองรับ

หากระบบของคุณใช้ปริมาณงานที่รับประกันเพื่อควบคุม latency บนเส้นทาง production การย้ายเส้นทางนั้นไป Opus 5 จะทำให้กลับไปใช้ standard capacity

แนวทางที่ใช้งานได้มี 2 ทาง:

1. คง workload ที่ไวต่อ latency ไว้บน claude-opus-4-8
2. ย้ายไป Opus 5 แล้ววัด tail latency จริงของระบบ

ควรแบ่งการย้ายตาม workload แทนการเปลี่ยนทั้งระบบในครั้งเดียว

8. Fast mode ใช้ได้แล้ว และมี Cyber-refusal fallback ใหม่

Fast mode บน Opus 5

Fast mode ใช้งานได้กับ Opus 5 และให้ความเร็วเอาต์พุตประมาณ 2.5 เท่า โดยมีราคา:

• อินพุต: 10 ดอลลาร์ต่อล้านโทเค็น
• เอาต์พุต: 50 ดอลลาร์ต่อล้านโทเค็น

ข้อจำกัด:

• เป็นพรีวิวสำหรับการวิจัย
• ใช้ได้เฉพาะ first-party API
• ใช้ไม่ได้บน Amazon Bedrock, Google Cloud และ Microsoft Foundry
• ใช้ร่วมกับ Batch API ไม่ได้

เหมาะกับเส้นทาง interactive มากกว่างาน background

Server-side fallback สำหรับ cyber refusals

ส่งค่าต่อไปนี้เพื่อให้คำขอที่ Opus 5 ปฏิเสธด้วยเหตุผลด้านไซเบอร์เปลี่ยนไปใช้ Opus 4.8 โดยอัตโนมัติ:

{
  "fallbacks": "default"
}

พร้อม beta header:

anthropic-beta: server-side-fallback-2026-07-01

นอกจากนี้ beta header ต่อไปนี้ช่วยให้เพิ่มหรือลบ tool definition ระหว่างเทิร์น โดยไม่ทำให้ prompt cache ใช้ไม่ได้:

anthropic-beta: mid-conversation-tool-changes-2026-07-01

เหมาะกับ agent session ที่ยาวและมีชุดเครื่องมือเปลี่ยนตลอดเวลา

9. สิ่งที่ไม่เปลี่ยนแปลง

สิ่งต่อไปนี้ปล่อยไว้ได้:

• Sampling parameters ยังส่ง 400
  
  temperature, top_p และ top_k ที่ไม่ใช่ค่าเริ่มต้นยังถูกปฏิเสธเช่นเดียวกับ Opus 4.8 ให้ควบคุมพฤติกรรมผ่าน system prompt

• จำนวนโทเค็นโดยประมาณยังเท่าเดิม
  
  Opus 5 ใช้ tokenizer family เดียวกับ Opus 4.8 งบประมาณโทเค็นและโมเดลต้นทุนเดิมจึงยังใช้ได้

• ราคาพื้นฐานเท่าเดิม
  
  อินพุต 5 ดอลลาร์ และเอาต์พุต 25 ดอลลาร์ต่อล้านโทเค็น ดูข้อมูลอ้างอิงได้ที่ หน้าเว็บราคา Opus 4.8

• รูปแบบ request/response เดิม
  
  Streaming, tool use, vision, structured outputs และ batch ยังทำงานด้วยรูปแบบเดิม

แม้ API surface จะคล้ายเดิม แต่พฤติกรรมของโมเดลเปลี่ยนไป:

• Opus 5 ตรวจสอบงานของตัวเองมากขึ้น จึงไม่จำเป็นต้องใส่คำสั่งอย่าง double-check your answer ซ้ำ ๆ
• คำตอบเริ่มต้นอาจยาวกว่า Opus 4.8
• การลด effort ลด thinking ไม่ได้ลดความยาวของคำตอบที่มองเห็นได้โดยตรง

หากต้องการเอาต์พุตสั้น ให้ระบุข้อจำกัดความยาวในพรอมต์อย่างชัดเจน อ่านเพิ่มได้ที่ การเขียนพรอมต์ Claude Opus 5

ตรวจสอบการย้ายก่อนนำไปใช้งานจริง

ทุกประเด็นข้างต้นเป็นความแตกต่างระดับ HTTP จึงทดสอบแยกจากแอปพลิเคชันได้ วงจรทดสอบใน Apidog ที่แนะนำ:

1. บันทึกคำขอไปยัง Messages endpoint และเก็บ API key เป็น environment variable
2. โคลนคำขอเป็นหลายเวอร์ชัน:
   • claude-opus-4-8
   • claude-opus-5 ด้วยค่าเริ่มต้น
   • claude-opus-5 หนึ่งชุดต่อ effort level
3. ทดสอบ thinking: disabled ร่วมกับ xhigh โดยตั้งใจ และเก็บ response 400 ไว้เป็นตัวอย่าง
4. ตรวจ stop_reason และทำให้ max_tokens เป็น test failure เพื่อจับเอาต์พุตที่ถูกตัด
5. ส่งคำขอที่ใช้ cache เดิม 2 ครั้ง แล้วตรวจ usage.cache_read_input_tokens ในครั้งที่สอง
6. ทดสอบ streaming อย่างน้อย 1 ครั้ง และยืนยันว่า SSE parser รองรับ thinking block ที่มาถึงโดยค่าเริ่มต้น

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

ข้อควรระวังก่อนย้ายทุกอย่าง

Opus 5 ไม่ใช่จุดสูงสุดของ Claude stack: Fable 5 ยังคงเป็นโมเดลความสามารถสูงสุดที่ Anthropic ปล่อยสู่สาธารณะ และ Opus 5 ยังตามหลัง Mythos 5 ในงาน cyber exploitation และการวิจัยชีววิทยาแบบอัตโนมัติ ตามที่ Anthropic ระบุในโพสต์เปิดตัว

ตัวเลข benchmark ในประกาศเปิดตัว เช่น Frontier-Bench, ARC-AGI 3, OSWorld 2.0 และ CursorBench 3.2 เป็นผลที่ผู้ขายรายงาน และยังไม่ได้รับการทำซ้ำอย่างอิสระ ณ วันที่ 25 กรกฎาคม 2026

ก่อนย้าย production workload ให้รัน evaluation ของคุณเอง สรุปที่เหมาะสมคือ: ความสามารถระดับแนวหน้าในราคาครึ่งหนึ่งของระดับแนวหน้า พร้อมข้อจำกัดที่ระบุไว้ข้างต้น

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

ดำเนินการตามลำดับนี้:

1. เปลี่ยน model ID เป็น claude-opus-5 โดยไม่มีวันที่ต่อท้าย
2. เพิ่ม max_tokens ในทุกคำขอที่ก่อนหน้านี้ละเว้น thinking
3. ค้นหา "disabled" ใน codebase และตรวจว่าไม่มีคำขอใดจับคู่กับ effort xhigh หรือ max
4. ลบ long-context beta value ออกจาก anthropic-beta
5. ทดสอบ effort ใหม่ทั้งหมดบน evaluation set ของคุณเอง
6. เพิ่ม cache_control ให้ส่วนพรอมต์ที่มีขนาด 512–1,024 โทเค็น
7. ระบุทราฟฟิกที่ใช้ Priority Tier และตัดสินใจว่าจะคงไว้บน claude-opus-4-8 หรือไม่
8. ลบคำสั่งตรวจสอบซ้ำออกจากพรอมต์ และเพิ่มคำสั่งเรื่องความกระชับเมื่อจำเป็น
9. เปิดใช้ fallbacks: "default" หาก workload ถูกปฏิเสธในหมวดหมู่ไซเบอร์
10. ตรวจ stop_reason ใน test suite เพื่อให้ truncation ปรากฏเป็น failure

สำหรับตัวอย่างคำขอฉบับเต็ม ดู คู่มือ Claude Opus 5 API หรือเริ่มจาก Claude Opus 5 คืออะไร สำหรับข้อมูลจำเพาะและความพร้อมใช้งาน

หากยังใช้โมเดลเก่าในบางเส้นทาง ดู คำอธิบาย Opus 4.8 และ คำแนะนำ API ของ Opus 4.8 ได้เช่นกัน ส่วน ภาพรวมโมเดล ของ Anthropic คือแหล่งข้อมูลทางการสำหรับ model ID, context window และวันตัดการรองรับ

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

การย้ายจาก Opus 4.8 ไป Opus 5 เป็นแบบ plug-and-play หรือไม่?

ใกล้เคียง แต่ไม่ทั้งหมด การเปลี่ยน model ID ใช้ได้กับคำขอส่วนใหญ่ แต่ต้องระวังว่า thinking เปิดใช้โดยค่าเริ่มต้นและใช้โควตาร่วมกับ max_tokens นอกจากนี้ thinking: {"type": "disabled"} ร่วมกับ effort xhigh หรือ max จะส่ง HTTP 400 และทราฟฟิก Priority Tier ต้องตัดสินใจแยกต่างหากเพราะ Opus 5 ไม่รองรับ

ทำไมจึงได้ HTTP 400 หลังเปลี่ยนเป็น claude-opus-5?

สาเหตุที่พบบ่อยที่สุดคือการปิด thinking พร้อมขอ effort xhigh หรือ max ให้เลือกอย่างใดอย่างหนึ่ง:

• ลบ thinking ออก แล้วคง effort สูงไว้
• ปิด thinking แล้วลด effort เป็น high หรือต่ำกว่า

นอกจากนี้ temperature, top_p และ top_k ที่ไม่ใช่ค่าเริ่มต้นก็ยังส่ง HTTP 400 เช่นเดิม

จำเป็นต้องนับโทเค็นใหม่หลังย้ายหรือไม่?

ไม่จำเป็น Opus 5 ใช้ tokenizer family เดียวกับ Opus 4.8 ดังนั้นจำนวนโทเค็นโดยประมาณและงบประมาณเดิมยังใช้ได้ ราคาพื้นฐานก็เท่าเดิมที่ 5 ดอลลาร์สำหรับอินพุต และ 25 ดอลลาร์สำหรับเอาต์พุตต่อล้านโทเค็น

อย่างไรก็ตาม ค่าใช้จ่ายรวมอาจเพิ่มขึ้นได้ เพราะ thinking ที่เปิดโดยค่าเริ่มต้นอาจใช้โทเค็นเอาต์พุตเพิ่มขึ้น