Claude Sonnet 5.5 เร็วขึ้นแต่ราคา token เท่าเดิม: ต้องวัดต้นทุนต่อ task ใหม่

Anthropic เปิดตัว Claude Sonnet 5.5 เมื่อ 28 กันยายน 2026 โดยวางตำแหน่งเป็นโมเดลสำหรับงานประจำที่ขอบเขตชัด งานแก้บั๊ก และงานเอกสารที่ต้องการรอบตอบเร็วกว่าเดิม จุดสำคัญไม่ใช่แค่ตัวเลข benchmark สูงขึ้น แต่คือราคาต่อหนึ่งล้าน token ยังเท่า Sonnet 5 ขณะที่บริษัทบอกว่าใช้ token น้อยลงและสร้างคำตอบเร็วขึ้น นั่นทำให้ทีมที่จ่ายตามการใช้งานต้องกลับมาวัด ต้นทุนต่อ task สำเร็จ ไม่ใช่ดู rate card อย่างเดียวครับ

ผมตรวจประกาศต้นทางของ Anthropic, system card, คู่มือย้าย API และรายงานข่าวอิสระของ Reuters ผ่าน Boursorama ณ วันที่ระบุในบทความ ข้อความเรื่องความเร็วและประหยัดเป็นผลทดสอบที่ผู้ผลิตรายงาน ยังไม่ใช่คำรับประกันว่าจะเกิดกับ workload ของทุกทีม

สรุป 30 วินาที

• Sonnet 5.5 ใช้ model ID ใหม่คือ claude-sonnet-5-5 และเปิดให้ใช้บน Claude Platform รวมถึงผู้ให้บริการ cloud ที่ประกาศรองรับ
• Anthropic รายงานว่าสร้าง output เร็วกว่า Sonnet 5 มากกว่า 30% และต้นทุนต่อ task อาจต่ำลงได้สูงสุด 30% แม้ราคาต่อ token เท่าเดิม
• ราคาที่ประกาศคือ input 2 ดอลลาร์, output 10 ดอลลาร์ และ cache read 0.20 ดอลลาร์ต่อหนึ่งล้าน token ส่วน cache write อยู่ที่ 2.50 ดอลลาร์
• การย้ายไม่ใช่แค่เปลี่ยนชื่อโมเดล: thinking ทำงานโดยปริยาย, forced tool choice บางแบบใช้ไม่ได้ และ computer use เปลี่ยนไปใช้ toolset ใหม่บนบาง platform
• benchmark ดีขึ้นมากบางชุด แต่ประกาศเองก็เตือนว่า benchmark วัดได้เพียงบางมิติ และ Opus 5.5 ยังเหมาะกว่าสำหรับโจทย์เปิดกว้างที่ต้องใช้วิจารณญาณต่อเนื่อง

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าทีมใช้ Claude ช่วย review โค้ด สร้างเอกสาร หรือทำ agent loop ความเร็วที่เพิ่มขึ้นอาจลดเวลารอของคนและลดคิวของระบบ แต่ผลประโยชน์จะเกิดจริงก็ต่อเมื่อคุณภาพผ่านเกณฑ์เดิมโดยไม่ต้อง retry มากขึ้น สมมติร้านข้าวตามสั่งทำอาหารเร็วขึ้น 30% แต่ผิดออเดอร์จนต้องทำใหม่สองครั้ง ร้านไม่ได้ประหยัดครับ metric ที่ดีจึงควรนับ success rate, token รวม, tool calls, latency และจำนวนครั้งที่มนุษย์ต้องแก้

ทีม backend ต้องสนใจ migration มากเป็นพิเศษ เพราะ request เดิมบางรูปแบบอาจตอบ 400 คู่มือระบุว่า thinking แบบ disabled ไม่รองรับแล้ว หากอยากลดการคิดล่วงหน้าให้ใช้ between_tools ภายใต้ effort ที่รองรับ นอกจากนี้ tool_choice แบบบังคับชนิด tool หรือ any ถูกปฏิเสธ ต้องเปลี่ยนเป็น auto และใช้ strict schema เมื่อ platform รองรับ หากเปลี่ยนแค่ model ID โดยไม่รัน contract test ระบบ agent อาจหยุดตั้งแต่ก่อนเริ่มทำงาน

ฝั่ง product ก็ต้องทบทวน UX เมื่อข้อความระหว่าง tool calls อาจกลับมาใน thinking block และว่างตาม display ค่าเริ่มต้น แอปที่เคยอ่านเฉพาะ text block อาจดูเหมือนเงียบระหว่างทำงาน ทั้งที่โมเดลยังเดินต่อ นี่เป็นปัญหาคนละแบบกับคุณภาพโมเดล แต่ผู้ใช้จะรู้สึกว่า “ค้าง” ได้เหมือนกัน

ทำงานยังไง

คำว่า “เร็วขึ้น” ในประกาศมีสองชั้น ชั้นแรกคืออัตราสร้าง output ต่อเวลา ชั้นที่สองคือโมเดลใช้ขั้นตอนและ token น้อยลงใน task บางชนิด ลองเทียบกับพนักงานส่งอาหาร: คนหนึ่งขี่เร็วขึ้น ส่วนอีกคนวางเส้นทางสั้นลง ทั้งสองทำให้ถึงเร็ว แต่ต้นทุนและความเสี่ยงต่างกัน หากเส้นทางสั้นเพราะตัดการตรวจออก คุณภาพอาจลด หากสั้นเพราะวางแผนดีขึ้นจึงเป็นกำไรจริง

Sonnet 5.5 ใช้ adaptive thinking โดยปริยายเมื่อ request ไม่ระบุ thinking ทีมกำหนด effort ตั้งแต่ low ถึง max เพื่อแลกความเร็วกับการตรวจทานได้ แต่ระดับชื่อเดียวกันไม่ควรถูกสมมติว่าใช้ token เท่าโมเดลเดิม คู่มือแนะนำให้ sweep ค่า effort ใหม่ งานที่ขอบเขตชัดอาจเริ่ม medium ส่วนงานยาวหรือยากค่อยขยับ high สิ่งนี้คล้ายเลือกช่องชำระเงิน: ตะกร้าน้อยไม่ควรเข้าช่องตรวจละเอียดที่สุดทุกครั้ง แต่ของราคาแพงก็ไม่ควรรีบผ่านโดยไม่เช็ก

สำหรับ tool use โมเดลใหม่เน้น auto selection และ strict schema แทนการบังคับเรียกเครื่องมือทุกครั้ง Strict ช่วยให้ input ตรง JSON Schema แต่ไม่บังคับว่าโมเดลต้องเรียก tool จึงต้องเขียน prompt ให้ชัดว่ากรณีใดต้องใช้ และ server ต้อง validate ซ้ำเสมอ เพราะ schema ถูกต้องไม่ได้แปลว่า action ได้รับอนุญาต การเรียก “ลบไฟล์ที่ path ถูกชนิด” ยังอาจเป็น action ที่ไม่ควรอนุมัติ

thinking block ของ Sonnet 5.5 ผูกกับบทสนทนาและบัญชีมากขึ้นเพื่อป้องกันการแยก reasoning ไปใช้ผิดบริบท เมื่อทำ loop ต้องส่ง block กลับแบบไม่แก้ไขและรักษาประวัติ append-only ระบบที่ตัดต่อ history หรือสลับบัญชีกลาง session อาจเจอ error จึงควรทดสอบ resume, retry และ model fallback ไม่ใช่ทดสอบเฉพาะ request แรก

เรื่องเงินและผลกระทบ

rate card ของ Sonnet 5.5 เท่ากับ Sonnet 5 แต่ Anthropic อ้างว่าต้นทุนต่อ task ลดได้สูงสุด 30% เพราะใช้ token น้อยลง คำว่า “สูงสุด” สำคัญมาก งานบางแบบอาจไม่ลดเลย หรือแพงขึ้นเมื่อ adaptive thinking ใช้ output token เพิ่ม ทีมควร replay ชุดงานจริงแบบปิดข้อมูลลับและเทียบ cost distribution ไม่ใช่ค่าเฉลี่ยเดียว

ตัวอย่างเชิงวิธีคิด: หากเดิมงานหนึ่งใช้ input 100,000 token และ output 20,000 token ต้นทุนตาม rate card คือ 0.20 บวก 0.20 ดอลลาร์ ยังไม่รวม cache write/read หากรุ่นใหม่ลด output แต่เพิ่ม cache write หรือ retry ผลรวมอาจไม่ตรงเปอร์เซ็นต์โฆษณา ควรแยก cold request, cached request และ agent task หลายรอบ เพราะพฤติกรรม cache มีผลมากกับ prompt ใหญ่

ผลกระทบอีกด้านคือ capacity ทีม ถ้า latency ลด คนอาจส่งงานถี่ขึ้นและยอดรวม token ต่อวันสูงขึ้น แม้หนึ่ง task ถูกลง เหมือนโปรโมชันส่งฟรีทำให้สั่งบ่อยขึ้น งบรายเดือนอาจโตได้ จึงต้องมี quota, budget alert และ circuit breaker ต่อ workspace ไม่ใช่ดู unit cost เพียงอย่างเดียว

ความปลอดภัยและข้อจำกัด

Anthropic ระบุว่าทำ behavioral audit ราว 1,850 สถานการณ์ และเพิ่ม cyber safeguards คล้ายโมเดลที่มีความสามารถสูงกว่า รวมถึง fallback สำหรับคำขอบางประเภท System card เป็นหลักฐานสำคัญเพราะอธิบายวิธีประเมินและข้อจำกัดมากกว่าหน้าการตลาด แต่เป็นการประเมินของผู้ผลิต ทีมที่ใช้กับข้อมูลสำคัญยังต้องทำ red-team และ eval ของตน

โมเดลมีความสามารถ computer use และ agentic coding สูงขึ้น ซึ่งทำให้ทั้งประโยชน์และ blast radius โตขึ้น หากเชื่อม shell, browser หรือ credential ควรให้สิทธิ์น้อยที่สุด ใช้ environment แยก บังคับ approval ก่อน action ที่เปลี่ยน state และเก็บ audit log การที่โมเดลตอบถูก benchmark มากขึ้นไม่ใช่เหตุผลให้ขยาย permission โดยอัตโนมัติ

การ fallback ด้าน cyber อาจเปลี่ยนโมเดลที่ตอบ request บางกลุ่ม ระบบต้องยอมรับว่าคุณภาพ latency และพฤติกรรมอาจไม่เหมือนเดิม รวมทั้ง handle stop reason แบบ refusal ให้ผู้ใช้เห็นอย่างตรงไปตรงมา ห้าม retry อัตโนมัติไม่จำกัดเพียงเพราะคิดว่าเป็น transient error

ข้อมูลที่ยังไม่ชัดและแหล่งที่ไม่ตรงกัน

ประกาศต้นทางใช้ถ้อยคำว่าเร็วกว่า 30% ขึ้นไปและถูกลงต่อ taskได้สูงสุด 30% แต่ Reuters รายงานภาพกว้างของการเปิดตัวและการแข่งขัน ไม่ได้ยืนยันตัวเลขด้วย benchmark อิสระ ดังนั้นตอนนี้มีหลักฐานชัดว่า Anthropic กล่าวอ้างและเผยวิธีทดสอบ แต่ยังไม่มีข้อมูลสาธารณะเพียงพอว่าตัวเลขเดียวกันเกิดกับ workload ภาษาไทย, repository ขนาดใหญ่ หรือ tool stack ของแต่ละองค์กร

คะแนน Terminal-Bench ที่ประกาศกระโดดจาก 10.3% เป็น 70.6% มากผิดจากการขยับรุ่นทั่วไป ผู้ผลิตให้รายละเอียด evaluation ไว้ แต่ความต่างของ harness, effort, timeout และ pre-release configuration ทำให้เทียบเลขเดียวข้ามระบบไม่ได้ หน้าประกาศยังบอกเองว่า benchmark เป็นเพียงมิติหนึ่ง และ footnote ระบุข้อบกพร่องใน pre-release deployment ที่อาจกระทบบางชุด แม้คาดว่ากระทบเล็ก

ยังไม่ชัดว่าผู้ให้บริการ cloud ทุกแห่งเปิด feature, model alias, toolset และ fallback พร้อมกันแค่ไหน คู่มือแยกข้อกำหนดของ Claude API, Bedrock และ Google Cloud จึงห้ามถือว่า config จาก platform หนึ่งย้ายตรง ๆ ได้ ไม่มีราคาไทยเฉพาะหรือ SLA ใหม่ในแหล่งที่ตรวจ และไม่มีหลักประกันว่า alias ที่ไม่ลงวันที่จะคงพฤติกรรมเดิมตลอดอายุระบบ

ควรทำอะไร

ทีมที่ยังทดลองควรเลือกงานจริง 30–100 ตัวอย่าง แยกง่าย/กลาง/ยาก แล้ววัด pass rate, human edit time, latency, token, tool-call error และต้นทุนรวม ใช้ prompt และ permission เท่าเดิมก่อนเพื่อเห็นผลของ model อย่างเดียว จากนั้นค่อยปรับ effort อย่าเปลี่ยนโมเดล prompt และ harness พร้อมกันจนหาสาเหตุไม่ได้

ทีมที่ใช้ production ควรสร้าง canary route จำนวนเล็ก ตรวจ response block ทุกชนิด รองรับ refusal และ model-context-window-exceeded ทดสอบ forced tool migration, thinking block replay, cache, fallback และ computer toolset ตั้ง budget ceiling กับ rollback switch ไว้ก่อนเปิด traffic เพิ่ม

ทีม security ควรทบทวน tool allowlist, network egress, secret injection และ approval boundary โดยถือว่าโมเดลมีความสามารถสูงขึ้นแต่ไม่ได้มี authority เพิ่ม ตรวจ audit log ว่าแยกคำแนะนำออกจาก action จริง และอย่าให้ model-generated text เปลี่ยน policy เอง

ผู้ใช้ทั่วไปไม่ต้องรีบย้ายเพราะ benchmark หากงานเดิมดีอยู่ ให้ลองงานที่รู้คำตอบและดูว่าความเร็วที่รู้สึกได้แลกกับความถูกต้องหรือไม่ สำหรับข้อมูลส่วนตัวหรือเอกสารสำคัญ อ่าน data policy ของช่องทางที่ใช้ เพราะการมี zero data retention บางตัวเลือกไม่ได้หมายถึงทุกแผนหรือทุก integration ตั้งค่าเหมือนกัน

Recap

• Sonnet 5.5 ใช้ราคา token เท่าเดิม แต่ผู้ผลิตอ้างว่าต่อ task เร็วและถูกลง
• วัด success-adjusted cost ด้วย workload จริงก่อนเปลี่ยน production
• ย้าย thinking, tool choice และ computer use ตามคู่มือ ไม่ใช่เปลี่ยน model ID อย่างเดียว
• เก็บ permission เท่าเดิมหรือแคบลงจนกว่าจะผ่าน security review
• แยก claim ของผู้ผลิตออกจากผล benchmark อิสระที่ยังมีไม่มาก
• เปิด canary, budget alert และ rollback ก่อนขยาย traffic