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

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

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

เวอร์ชันย่อ

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

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

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

นี่คือรูปแบบของคำขอที่เคยปลอดภัย:

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

เปลี่ยน ID โมเดลและไม่มีอย่างอื่น และคุณจะมีความเสี่ยงต่อการถูกตัดทอน การแก้ไขคือการเพิ่มงบประมาณ:

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

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

หากคุณต้องการพฤติกรรมแบบไม่คิดแบบเดิมจริงๆ ให้ส่ง thinking: {"type": "disabled"} อย่างชัดเจน อ่านส่วนถัดไปก่อน เพราะตอนนี้ฟิลด์นั้นมีปฏิสัมพันธ์กับ effort ในลักษณะที่ส่งคืนข้อผิดพลาด

2. ข้อผิดพลาด 400: ปิดใช้งาน thinking บวกกับ effort ระดับ xhigh หรือ max

นี่คือกับดักที่น่าจะปรากฏในบันทึกข้อผิดพลาดของคุณมากที่สุด เพราะทั้งสองส่วนของมันเคยถูกต้องแยกกันใน Opus 4.8

ใน Opus 5 การรวม thinking: {"type": "disabled"} เข้ากับ output_config.effort ที่ตั้งค่าเป็น xhigh หรือ max จะส่งคืน HTTP 400 Anthropic บังคับใช้ต่อคำขอ ดังนั้นจึงล้มเหลวทันทีและสอดคล้องกันแทนที่จะลดประสิทธิภาพ ตรรกะตรงไปตรงมา: สองระดับ effort สูงสุดมีไว้เพื่อเพิ่มการคิด ดังนั้นการขอ effort สูงสุดในขณะที่ปิด thinking จึงเป็นความขัดแย้งกัน

คำขอที่ตอนนี้จะล้มเหลว:

{
  "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."}
  ]
}

วิธีแก้ไข A, รักษาสมรรถนะไว้ ลบฟิลด์ thinking ออก คงไว้ซึ่ง effort สูง นี่คือทิศทางที่ Anthropic แนะนำ และเป็นสิ่งที่จะเลือกสำหรับการเขียนโค้ดและการทำงานแบบ agentic:

{
  "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 จริงๆ ให้คง disabled ไว้และลด 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."}
  ]
}

ข้อควรระวังหนึ่งสำหรับวิธีแก้ไข B Anthropic ระบุว่ามีสิ่งประดิษฐ์สองอย่างที่ปรากฏขึ้นเป็นครั้งคราวเมื่อปิดใช้งาน thinking: การเรียกใช้เครื่องมือที่เขียนออกมาเป็นข้อความธรรมดาแทนที่จะถูกดำเนินการ และแท็ก XML ภายในเช่น <thinking> ที่รั่วไหลไปยังเอาต์พุตที่มองเห็นได้ ในวงจร agentic ข้อความที่รั่วไหลยังทำให้เทิร์นถัดไปเสียอีกด้วย การแก้ไขของ Anthropic เองคือการเปิด thinking ไว้และควบคุมค่าใช้จ่ายด้วยระดับ effort ที่ต่ำกว่าแทน พิจารณาวิธีแก้ไข B เป็นทางเลือกที่แคบ ไม่ใช่ค่าเริ่มต้น

3. ระดับ Effort ถูกปรับเทียบใหม่ ดังนั้นให้ทดสอบใหม่แทนการคัดลอกการตั้งค่า

Opus 5 ใช้ค่าเริ่มต้นที่ effort ระดับ high และระดับต่างๆ ได้รับการปรับเทียบใหม่ low และ medium มีความแข็งแกร่งอย่างมีนัยสำคัญมากขึ้นใน Opus 5 เมื่อเทียบกับโมเดล Opus ก่อนหน้า ดังนั้นการตั้งค่าที่คุณปรับแต่งใน 4.8 จึงไม่ให้ผลลัพธ์ในจุดต้นทุนและคุณภาพเดียวกันอีกต่อไป Anthropic กล่าวอย่างชัดเจนให้ทำการทดสอบ effort ใหม่ทั้งหมดแทนที่จะนำการกำหนดค่า 4.8 ของคุณมาใช้ และคำแนะนำนั้นมีผลทั้งสองทาง:

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

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

ทำการทดสอบบนชุดการประเมินของคุณเอง ไม่ใช่บนเกณฑ์มาตรฐาน กำหนดพรอมต์ให้คงที่ เปลี่ยนเฉพาะค่า effort และบันทึกคุณภาพของเอาต์พุต ความหน่วงแฝง และ usage สำหรับแต่ละระดับ การเจาะลึกพารามิเตอร์ effort ครอบคลุมกลไกของแต่ละระดับ; สำหรับด้านค่าใช้จ่ายของการตัดสินใจเดียวกัน ดูที่ รายละเอียดราคา Opus 5

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

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

หากไคลเอนต์ของคุณยังคงส่งค่า extended-context beta ในเฮดเดอร์ anthropic-beta จากการตั้งค่า Opus 4.8 ของคุณ ตอนนี้มันเป็นภาระที่ไม่มีประโยชน์แล้ว ถอดมันออก ค่า beta ที่ค้างอยู่ใน HTTP client ที่ใช้ร่วมกันคือวิธีที่คุณจะลงเอยด้วยการแก้ไขข้อผิดพลาดของคำขอที่ไม่เกี่ยวข้องกันในอีกหกเดือนต่อมา

เอาต์พุตสูงสุดบน Messages API คือ 128k โทเค็น หากคุณต้องการมากกว่านั้น Batch API สามารถส่งเอาต์พุตได้สูงสุด 300k โทเค็นด้วย beta header output-300k-2026-03-24 ซึ่งเป็นการเลือกใช้แยกต่างหากจากสิ่งที่คุณทำสำหรับความยาวบริบท

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

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

สิ่งที่คุ้มค่าที่จะทำคือการทบทวน ดูพรอมต์ระบบ คำจำกัดความของเครื่องมือ และบล็อก few-shot ที่อยู่ระหว่าง 512 ถึง 1,024 โทเค็น ซึ่งก่อนหน้านี้ไม่เคยคุ้มค่ากับการใช้ cache_control แต่ตอนนี้คุ้มค่าแล้ว ยืนยันผลกระทบโดยการอ่าน cache_read_input_tokens ในบล็อก usage ของการตอบกลับ: ในการเรียกใช้ครั้งที่สองที่เหมือนกัน ควรมีค่าไม่เป็นศูนย์ คู่มือการลดค่า API ของ Claude ครอบคลุมกลยุทธ์การแคชที่กว้างขึ้น

6. ตอนนี้ System messages ระหว่างการสนทนาได้รับการยอมรับแล้ว

Opus 4.8 ปฏิเสธการใส่ {"role": "system"} ภายในอาร์เรย์ messages ด้วยข้อผิดพลาด 400 แต่ Opus 5 ยอมรับ ซึ่งเป็นการเพิ่มความสามารถ จึงไม่ทำให้สิ่งใดเสีย แต่สามารถลบวิธีการแก้ปัญหาชั่วคราวออกได้ หากคุณสร้างกลไกที่รวมการเปลี่ยนแปลงคำสั่งระหว่างการสนทนาเข้ากับการตอบสนองของผู้ใช้สังเคราะห์ ตอนนี้คุณสามารถใส่คำสั่งนั้นในตำแหน่งที่ถูกต้องได้:

{
  "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."}
  ]
}

นี่คือความสามารถต่อโมเดล หากคุณส่งประวัติการสนทนาเดียวกันไปยัง Opus 4.8 ในฐานะทางเลือก โมเดลเก่าจะยังคงส่งคืนข้อผิดพลาด 400 สำหรับข้อความนั้น

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

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

ไม่มีการแก้ไขที่ชาญฉลาด ไม่ว่าคุณจะเก็บทราฟฟิกที่สำคัญต่อความหน่วงแฝงไว้บน claude-opus-4-8 ในขณะที่ส่วนที่เหลือย้ายไป Opus 5 หรือยอมรับความจุมาตรฐานและวัดว่าความหน่วงแฝงปลายทางของคุณลดลงหรือไม่ แบ่งการย้ายตามภาระงานแทนที่จะย้ายทั้งระบบพร้อมกัน

8. Fast mode ตอนนี้ใช้งานได้ และมี Cyber-refusal fallback ใหม่

Fast mode ทำงานบน Opus 5 ก่อนหน้านี้ Fast mode ส่งคืนข้อผิดพลาดใน Opus 4.7 และทำงานที่ความเร็วมาตรฐานโดยไม่แจ้งให้ทราบใน Opus 4.6 ใน Opus 5 ให้ความเร็วเอาต์พุตประมาณ 2.5 เท่า ที่ราคา 10 ดอลลาร์ต่อล้านอินพุต และ 50 ดอลลาร์ต่อล้านเอาต์พุต นี่เป็นการพรีวิวสำหรับการวิจัย เฉพาะ API ของบุคคลที่หนึ่งเท่านั้น (ไม่ใช่ Amazon Bedrock, Google Cloud หรือ Microsoft Foundry) และไม่สามารถใช้ร่วมกับ Batch API ได้ ควรใช้กับเส้นทางแบบโต้ตอบ ไม่ใช่สำหรับงานเบื้องหลัง

การสำรองข้อมูลฝั่งเซิร์ฟเวอร์สำหรับ cyber refusals การส่ง fallbacks: "default" พร้อมกับ beta header server-side-fallback-2026-07-01 ทำให้คำขอที่ Opus 5 ปฏิเสธด้วยเหตุผลประเภทไซเบอร์สามารถเปลี่ยนไปใช้ Opus 4.8 ได้โดยอัตโนมัติ เครื่องมือความปลอดภัยคือจุดที่สิ่งนี้จะแสดงประโยชน์ของมัน

นอกจากนี้ยังมี beta header mid-conversation-tool-changes-2026-07-01 ที่ให้คุณเพิ่มหรือลบคำจำกัดความของเครื่องมือระหว่างเทิร์นโดยไม่ทำให้แคชพรอมต์ไม่ถูกต้อง: เป็นตัวควบคุมค่าใช้จ่ายสำหรับเซสชันเอเจนต์ที่ยาวนานพร้อมชุดเครื่องมือที่เปลี่ยนแปลง

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

การรู้ว่าสิ่งใดที่คุณสามารถปล่อยไว้ได้จะช่วยประหยัดเวลา:

• พารามิเตอร์การสุ่มตัวอย่างยังคงส่งคืน 400 temperature, top_p และ top_k ที่มีค่าไม่เป็นค่าเริ่มต้นจะถูกปฏิเสธ เช่นเดียวกับใน Opus 4.8 ควบคุมพฤติกรรมผ่าน system prompt
• จำนวนโทเค็นโดยประมาณยังคงเท่าเดิม Opus 5 ใช้ tokenizer family เดียวกับ 4.8 ดังนั้นงบประมาณโทเค็นและโมเดลต้นทุนที่มีอยู่ยังคงใช้ได้โดยไม่ต้องนับใหม่ ซึ่งตรงกันข้ามกับการย้ายจาก Sonnet 4.6 ไป Sonnet 5 ซึ่งทำให้จำนวนเปลี่ยนแปลงไปประมาณ 30%
• ราคาพื้นฐานเท่าเดิม 5 ดอลลาร์สำหรับอินพุต 25 ดอลลาร์สำหรับเอาต์พุต ซึ่งตรงกับ Opus 4.8, 4.7, 4.6 และ 4.5 ดู หน้าเว็บราคา Opus 4.8
• รูปแบบคำขอและการตอบกลับ Streaming, tool use, vision, structured outputs และ batch ทั้งหมดทำงานเหมือนเดิม

สิ่งหนึ่งที่เปลี่ยนแปลงแม้ว่า API จะไม่เปลี่ยนแปลง: Opus 5 ตรวจสอบงานของตัวเองโดยไม่ต้องแจ้งให้ทราบ ดังนั้นคำสั่ง "double-check your answer" ที่นำมาใช้ซ้ำจะทำให้เกิดการตรวจสอบมากเกินไปและสิ้นเปลืองโทเค็น การตอบกลับเริ่มต้นยังยาวกว่าของ 4.8 และการลด effort จะลดการคิดแทนที่จะลดความยาวที่มองเห็นได้ ดังนั้นให้ขอความกระชับอย่างชัดเจน สิ่งเหล่านี้เป็นการแก้ไขระดับพรอมต์ ซึ่งครอบคลุมใน การเขียนพรอมต์ Claude Opus 5

ตรวจสอบการย้ายก่อนที่คุณจะนำไปใช้งานจริง

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

1. บันทึกคำขอหนึ่งไปยัง Messages endpoint โดยมีคีย์ของคุณจัดเก็บเป็นตัวแปรสภาพแวดล้อม ไม่เคยใส่ในเนื้อหาโดยตรง
2. โคลนเป็นเวอร์ชันต่างๆ: claude-opus-4-8 แบบพื้นฐาน, claude-opus-5 ด้วยค่าเริ่มต้น และโคลนหนึ่งชุดต่อระดับ effort
3. ยิงการรวมกันของ disabled-thinking บวก xhigh โดยตั้งใจและบันทึกเนื้อหา 400 เพื่อให้คุณจำมันได้ในบันทึกโปรดักชัน
4. ยืนยัน stop_reason เพื่อให้การตอบกลับ max_tokens ที่ถูกตัดทอนล้มเหลวในการทดสอบของคุณ แทนที่จะถูกส่งออกไปอย่างเงียบๆ
5. ส่งคำขอที่แคชไว้ที่เหมือนกันสองครั้งและตรวจสอบ usage.cache_read_input_tokens ในการเรียกครั้งที่สอง
6. เรียกใช้คำขอ streaming หนึ่งครั้งและยืนยันว่าตัวแยกวิเคราะห์ SSE ของคุณจัดการกับบล็อก thinking ที่ตอนนี้มาถึงโดยค่าเริ่มต้น

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

ข้อควรระวังอย่างหนึ่งก่อนที่คุณจะย้ายทุกอย่าง

Opus 5 ไม่ใช่จุดสูงสุดของ Claude stack Fable 5 ยังคงเป็นโมเดลที่ความสามารถสูงสุดที่ Anthropic ปล่อยสู่สาธารณะ และ Opus 5 ยังคงตามหลัง Mythos 5 ในด้านการหาประโยชน์ทางไซเบอร์และการวิจัยชีววิทยาแบบอัตโนมัติ Anthropic กล่าวไว้เองใน โพสต์เปิดตัว การอ้างสิทธิ์เกณฑ์มาตรฐานในการเปิดตัว (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench 3.2) เป็นการดำเนินการโดยผู้ขายและยังไม่ได้รับการทำซ้ำอย่างอิสระ ณ วันที่ 25 กรกฎาคม 2026 ให้ถือว่าเป็นตัวเลขที่ Anthropic รายงานและทำการประเมินของคุณเองก่อนที่จะนำภาระงานโปรดักชันไปใช้งานจริง สรุปที่แม่นยำ: ความสามารถระดับแนวหน้าในราคาครึ่งหนึ่งของแนวหน้า โดยมีขีดจำกัดสูงสุดที่ระบุไว้เหนือกว่า

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

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

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

สำหรับคำแนะนำคำขอฉบับเต็ม ดู คู่มือ Claude Opus 5 API หรือเริ่มต้นด้วย Claude Opus 5 คืออะไร สำหรับข้อมูลจำเพาะและความพร้อมใช้งาน หากคุณยังคงรันโมเดลเก่าในบางที่ คำอธิบาย Opus 4.8 และ คำแนะนำ API ของมันยังคงแม่นยำสำหรับโมเดลนั้น ภาพรวมโมเดล ของ Anthropic เป็นแหล่งข้อมูลที่เป็นทางการสำหรับ ID, หน้าต่างบริบท และการตัดออก

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

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

ทำไมฉันถึงได้ข้อผิดพลาด 400 หลังจากเปลี่ยนไปใช้ claude-opus-5? สาเหตุที่พบบ่อยที่สุดคือการปิดใช้งาน thinking ในขณะที่ขอ effort xhigh หรือ max ให้เลือกลบฟิลด์ thinking ออกและคง effort สูงไว้ หรือปิดใช้งาน thinking และลด effort ลงไปที่ high หรือต่ำกว่า ค่า temperature, top_p หรือ top_k ที่ไม่ใช่ค่าเริ่มต้นยังคงส่งคืน 400 เช่นเดียวกับใน Opus 4.8

ฉันจำเป็นต้องนับโทเค็นใหม่หลังจากย้ายหรือไม่? ไม่ Opus 5 ใช้ tokenizer family เดียวกับ Opus 4.8 ดังนั้นจำนวนโทเค็นโดยประมาณจึงไม่เปลี่ยนแปลงและงบประมาณที่มีอยู่ยังคงใช้ได้ ค่าใช้จ่ายของ tool-use system prompt ลดลงเล็กน้อยที่ 286 โทเค็น เทียบกับ 290 ราคาพื้นฐานก็เท่ากันที่ 5 ดอลลาร์สำหรับอินพุตและ 25 ดอลลาร์สำหรับเอาต์พุต แม้ว่าค่าใช้จ่ายของคุณอาจยังคงเปลี่ยนแปลงได้หาก thinking-by-default เพิ่มโทเค็นเอาต์พุต