Claude Haiku 5.5 ถูกลงแรง แต่ context เกินแสน token คนละราคา: เลือกงานให้ถูกก่อนย้ายทั้งระบบ

Anthropic เปิด Claude Haiku 5.5 วันที่ 7 ตุลาคม 2026 ด้วยราคา input 0.10 ดอลลาร์และ output 0.50 ดอลลาร์ต่อหนึ่งล้าน token สำหรับ prompt ไม่เกิน 100,000 token แต่เมื่อ prompt ยาวกว่านั้น ราคาขยับเป็น 0.50 และ 2.50 ดอลลาร์ครับ เส้นแบ่งนี้ทำให้คำว่า “ถูกลง 90%” จริงสำหรับงานสั้นจำนวนมาก แต่ไม่ใช่สูตรเดียวสำหรับ agent ที่พก history ยาวทั้งวัน

Haiku 5.5 เป็น Haiku รุ่นแรกที่ปรับ effort ได้และ Anthropic วางตำแหน่งกับ summary, compaction, classification, database query, browser use และ subagent งานแคบ ๆ บริษัทบอกว่าค่าใช้จ่ายเฉลี่ยลดราว 75% เมื่อรวมรูปแบบ request เดิมกับ tokenizer ใหม่ แต่ยอมรับด้วยว่า Sonnet/Opus ยังเหมาะกว่าสำหรับ coding agent ซับซ้อน

สรุป 30 วินาที

• model ID คือ claude-haiku-5-5 และเปิดบน Claude Platform, AWS, Google Cloud และ Microsoft Azure
• ราคา prompt ไม่เกิน 100k token คือ input 0.10 / output 0.50 ดอลลาร์ต่อหนึ่งล้าน token; เกิน 100k เป็น 0.50 / 2.50 ดอลลาร์
• cache read อยู่ที่ 0.01 / 0.05 ดอลลาร์ตามช่วง context และ cache write 0.125 / 0.625 ดอลลาร์
• Anthropic ระบุว่าราคาต่ำกว่า Haiku 4.5 ถึง 90% ในช่วงแรก และ 50% ในช่วงยาว แต่ค่าเฉลี่ยต่อ “งาน” ลดราว 75% เพราะ tokenizer ใหม่ใช้ token ต่อ task ต่างจากเดิม
• benchmark ที่ประกาศดีขึ้นมาก เช่น OSWorld offline subset 72.4% แต่เป็นผลและ harness ที่ผู้ผลิตสรุป ต้องเทียบ eval ขององค์กรเอง
• safety card และหน้าเปิดตัวบอกว่าการป้องกัน cyber เข้มกว่า Haiku 4.5 แต่ผ่อนกว่ารุ่นใหม่บางตัวเพื่อรองรับงาน defensive มากขึ้น

ทำไมเกี่ยวกับคุณ

ทีมที่รัน classification, extraction หรือ subagent หลายล้านครั้งเห็นผลทันที เพราะราคา list ต่ำลงหนึ่งหลักทศนิยม แต่ agent workload มี trap: transcript, tool result และไฟล์แนบสะสมจนข้าม 100k โดยไม่รู้ตัว พอข้ามเส้น ค่า input/output เพิ่มห้าเท่า หาก observability ดูเพียง request count จะหาเหตุค่าใช้จ่ายพุ่งไม่เจอ

ทีมไทยยังต้องดู tokenizer ใหม่ด้วย ข้อความไทยไม่มีช่องว่างเหมือนอังกฤษ จำนวน token ต่อประโยคอาจเปลี่ยนจากรุ่นก่อน ประโยคว่า “ถูกลงต่อหนึ่งล้าน token” ไม่ตอบว่า invoice ต่อ ticket ถูกลงเท่าไร ต้อง replay ชุดข้อความไทยจริงและนับ token, cache hit, retry, tool loop และ output length

สำหรับงาน customer support ความเร็วช่วยลดเวลารอ แต่โมเดลเล็กที่ตอบไวอาจส่งเคสยากผิดแผนก หากไม่มี confidence threshold และ escalation ราคาต่อ call ที่ถูกลงอาจแลกกับค่าแก้ incident ในภายหลัง เป้าหมายควรเป็น cost ต่อ ticket ที่แก้ถูก ไม่ใช่ cost ต่อ token

ทำงานยังไง: model เล็ก + effort + routing

Haiku 5.5 ใช้ adjustable effort ให้ผู้เรียกเลือกระดับการคิด เปรียบเหมือนร้านข้าวที่มีทั้งออเดอร์ไข่ดาวและโต๊ะจีน เราไม่ควรให้ครัวใช้ขั้นตอนตรวจทุกจานเท่ากัน งาน label ง่ายใช้ effort ต่ำ ส่วนเคสคลุมเครือส่งต่อ effort สูงหรือ model ใหญ่กว่า

Routing ที่ดีเริ่มจาก scope งาน ไม่ใช่ชื่อรุ่น แยก task เป็น extraction ที่มี schema, summary ที่มี rubric, browser action ที่มี approval และ coding subtask ที่มี test ถ้าผลไม่ผ่าน validator ให้ retry แบบจำกัดหรือ escalate อย่าให้ Haiku ตัดสินเองว่าต้องส่งต่อโดยไม่มี budget เพราะ model อาจมั่นใจผิด

Context tier ทำให้ compaction เป็นส่วนของ cost architecture เมื่อ transcript ใกล้ 100k เราเลือกตัดข้อมูล, cache prefix, สรุป state หรือเริ่ม session ใหม่ได้ แต่การสรุปอาจทำให้ caveat/approval หาย ต้องเก็บ structured state แยกจาก prose และมี test ว่า constraint สำคัญอยู่ครบหลัง compact

Cache ช่วยงานที่มี system prompt และเอกสารต้นทางซ้ำ แต่อัตรา cache hit ต้องวัดจริง หาก prompt เปลี่ยนเล็กน้อยหรือ provider boundary ต่างกัน cache อาจพลาด การคำนวณ business case ควรมีสามแถว: no cache, hit ตาม p50 และ hit ตาม p90 ไม่ใช้ best case แถวเดียว

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

สมมติงานสั้นใช้ input 20k และ output 2k ก่อนคิด cache ค่า list ของ Haiku 5.5 ช่วงแรกต่ำมาก แต่ agent ที่วนเครื่องมือห้ารอบไม่ได้จ่ายแค่ prompt แรก ทุก request อาจพก history และ tool output กลับเข้าไปด้วย หาก log 60k ถูกแนบซ้ำสองรอบ ค่า context ขยายเร็วกว่าจำนวน user message

ทีม finance ควรทำ histogram ของ input token แยกช่วงต่ำกว่า/สูงกว่า 100k และแยก cache read/write, output, retry กับ error แล้วรายงาน cost per accepted result การตั้ง hard cap อาจช่วยงบ แต่ถ้าตัดข้อมูลกลางงานต้องมี explicit failure แทนตอบต่อแบบขาดบริบท

Anthropic ยังลด cache-read ของ Sonnet 5.5 ลงครึ่งหนึ่งในวันเดียวกัน ทำให้ routing comparison เปลี่ยนด้วย บางงาน agentic ที่ใช้ prefix ซ้ำมากอาจยังคุ้มกับ Sonnet เพราะ success rate สูงกว่าและ cache ถูกลง การเลือก Haiku เพียงเพราะราคา output ต่ำอาจเป็น false economy

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

Anthropic รายงาน benchmark และ customer quotes ที่แข็งแรง แต่ตัวเลขมาจากชุดทดสอบหรือ early customer ที่บริษัทเลือก DataCamp อธิบายจุดเด่นและทดลองเพิ่มเติม แต่ยังไม่ใช่ผลระยะยาวบน production ไทย เราจึงรู้ว่า model เปิดตัวและมีผลทดสอบที่ดี แต่ยังไม่รู้ error distribution ของงานเรา

คำว่า “90% cheaper” ใช้กับ list price ช่วงไม่เกิน 100k เทียบ Haiku 4.5 ส่วน “around 75% less per task” รวม tokenizer และสัดส่วน traffic เดิมของ Anthropic สองตัวเลขนี้ไม่ขัดกัน แต่ตอบคนละคำถาม หากบทความหรือ dashboard ยกตัวแรกไปใช้กับทุก workload จะทำให้ประมาณงบต่ำเกินจริง

หน้าเปิดตัวบอกว่า Haiku เหมาะกับ computer/browser use แต่ benchmark OSWorld เป็น offline subset และสภาพแวดล้อมจริงมี latency, auth, popup, locale, stale DOM และ approval policy เพิ่ม ทีมไม่ควรแปลง 72.4% เป็น automation success rate ของระบบตน

system card ให้รายละเอียด safety มากกว่าหน้าราคา แต่ model card ไม่สามารถครอบคลุม prompt injection จากข้อมูลเฉพาะองค์กร, tool permission และ connector ที่แต่ละทีมเปิด ความปลอดภัยของ model กับความปลอดภัยของ agent system เป็นคนละชั้น

ยังไม่มีราคาไทยเป็นบาท, SLA ของทุก provider, effective availability ทุก region, และผล eval ภาษาไทยที่แยก public อย่างละเอียด ค่าเงินบาทกับภาษีทำให้ต้นทุนจริงต่างจากตารางดอลลาร์

ควรทำอะไร

ทีม platform ควรเก็บ sample 200–500 งาน แยก short/long context, ไทย/อังกฤษ, cache hit/miss และ tool/no-tool จากนั้น replay Haiku 5.5 เทียบ baseline ด้วย rubric เดิม วัด accepted result, latency, token, retry และ escalation ไม่วัด score เฉลี่ยอย่างเดียว

ตั้ง router ให้ task แคบและ reversible ไป Haiku ก่อน ส่วนการแก้โค้ดหลายไฟล์, migration, financial decision หรือ action ที่ย้อนยากให้ model ใหญ่และ human approval กำหนด max tool turns, max context, network allowlist และ output schema ต่อ route

ทีม FinOps ควร alert เมื่อ request ข้าม 100k, cache hit ลด, output พุ่ง หรือ retry loop เกิน budget ให้ compaction เป็น operation ที่ตรวจได้และเก็บ constraint สำคัญใน structured state อย่าซ่อนการตัดบริบทไว้ใน SDK จนทีมเห็นเพียง bill ปลายเดือน

ผู้ใช้ทั่วไปเลือก Haiku กับงานเร็วและซ้ำ แต่ควรขอแหล่งอ้างอิง/ตรวจผลเมื่อเรื่องสำคัญ ผมมองว่า model เล็กที่ดีไม่ใช่ตัวแทน model ใหญ่ทุกงาน มันคือเลนด่วนที่ต้องมีป้ายบอกว่างานแบบไหนเข้าได้

สิ่งที่ควรจับตาคือผล independent eval, behavior ภาษาไทย, token consumption หลัง tokenizer ใหม่ และอัตรา success ของ browser use นอก demo หากทีมคุณมีงานที่ prompt มักอยู่แถว 90k จะ compact ก่อนเส้นราคา หรือยอมข้ามเพราะคุณภาพต้องใช้บริบทเต็ม?

Recap

• แยกราคา prompt ไม่เกินและเกิน 100k token
• คิด cost ต่อ accepted task รวม retry/tool loop ไม่ใช่ token rate อย่างเดียว
• วัด tokenizer กับข้อความไทยจริง
• ใช้ effort และ routing ตามความเสี่ยงของงาน
• เก็บ constraint สำคัญแยกจาก prose ก่อน compaction
• เทียบ Sonnet ใหม่ที่ cache read ถูกลงด้วย
• ถือ benchmark ผู้ผลิตเป็น hypothesis แล้วรัน eval ภายใน