แชทที่คุยค้างไว้นานแล้วกลับมาพิมพ์ต่อ อาจแพงกว่าที่คิด แม้พิมพ์ไปเพียงไม่กี่คำ สาเหตุไม่ได้อยู่ที่ข้อความใหม่ แต่อยู่ที่ context ก้อนเดิมที่ต้องโหลดกลับเข้า cache ใหม่ บทความนี้สรุปสิ่งที่ทีมควรเข้าใจตรงกัน พร้อมของที่นำไปวางได้เลย
สรุปสำหรับผู้บริหาร
- ค่าใช้จ่ายงาน context ยาวส่วนใหญ่อยู่ที่ cache read กับ cache write รวมกัน ไม่ใช่ output โดยข้อมูลจริงในเครื่องเราสองขานี้รวมกัน 62.4%
- cache หมดอายุทำให้ turn ถัดไปต้องเขียน context ใหม่ทั้งก้อน ไม่ว่าข้อความจะสั้นแค่ไหน
- งานชุดเดียวกันคิดราคา Sonnet-5-5 ถูกกว่า Opus-5-5 เท่าตัวในทุกหมวด จึงให้ Sonnet-5-5 เป็นรุ่นหลัก และ pin generation ทุกครั้งเพราะชื่อลอยราคาต่างกันตาม generation
- ของที่นำไปใช้ได้เลยคือ settings ที่บังคับ compact, กติกา routing งานก่อนเลือกรุ่น และนิสัย wrap แล้ว clear
- ตัวเลขในบทความนี้ผู้เขียนคำนวณซ้ำจาก token จริงในเครื่องแล้ว เป็นราคา list ไม่ใช่บิลจริง ควรยืนยันกับหน้าทางการก่อนตัดสินใจเรื่องเงิน
ทำไมข้อความสั้นถึงแพงได้
เมื่อคุยต่อเนื่อง context ก้อนเดิมจะอยู่ใน cache และการอ่านจาก cache ถูกกว่า input หลายเท่า จึงเป็นเหตุผลที่แชทยาวยังคุยต่อไหว ปัญหาเกิดเมื่อปล่อยแชททิ้งไว้นานจน cache หมดอายุ ข้อความถัดไปจะต้องเขียน context ทั้งก้อนกลับเข้า cache ใหม่ก่อน แล้วจึงเริ่มคิดคำตอบ
เอกสารทางการของ Anthropic อธิบาย กลไก prompt caching ไว้สองระดับ คือ cache อายุ 5 นาทีที่เป็นค่าเริ่มต้น และ cache อายุ 1 ชั่วโมงที่เป็นทางเลือก ไม่ใช่ข้อเสนอให้ย้ายทุกงานไป 1 ชั่วโมง ราคาเขียน cache 5 นาทีอยู่ที่ 1.25 เท่าของราคา input ส่วนราคาเขียน cache 1 ชั่วโมงอยู่ที่ 2 เท่า ขณะที่ราคาอ่านจาก cache อยู่ที่ประมาณ 0.1 เท่าในทั้งสองแบบ
ความหมายเชิงปฏิบัติคือ 5 นาทีคุ้มเมื่อมีการอ่านซ้ำอย่างน้อยหนึ่งครั้งในกรอบเวลา ส่วน 1 ชั่วโมงต้องมีการอ่านซ้ำมากกว่านั้นจึงคุ้ม และถ้าทิ้งแชทไว้นานเกินหนึ่งชั่วโมง ทั้งสองแบบก็หมดอายุเหมือนกัน จุดที่ควรดูหน้างานคือเวลาหมดอายุของ cache ที่ status line แสดงไว้ ถ้ากลับมาพิมพ์ก่อนเวลาหมดอายุ จะจ่ายราคา cache read ถ้ากลับมาหลังจากนั้น จะจ่ายค่าเขียนใหม่ทั้งก้อน
เลือกรุ่นตามงาน ไม่ใช่ตามโควตา
ความเข้าใจผิดที่พบบ่อยคือรุ่นเล็กกว่าต้องจ่ายน้อยกว่าเสมอ แต่งานที่คุยนานค่าใช้จ่ายส่วนใหญ่คือ cache read ที่จ่ายซ้ำทุก turn ดังนั้นรุ่นที่ cache read ถูกกว่าอาจจ่ายรวมน้อยกว่า แม้จะเป็นรุ่นใหญ่กว่าก็ตาม
| งาน | รุ่นที่เหมาะ | เหตุผล |
|---|---|---|
| งานหลักทั่วไป context โต | Sonnet 5.5 โดย pin 5.5 | ถูกกว่า Opus 5.5 เท่าตัวในทุกหมวด token จากผลทดสอบในเครื่องเรา |
| งานยากที่ต้อง flagship | Opus 5.5 โดย pin 5.5 | จ่ายแพงกว่าเท่าตัว แลกความสามารถ ใช้เฉพาะงานที่คุ้ม |
| ทางรองงานยาวราคาประหยัด | Fable 5.1 โดย pin 5.1 | ถูกกว่า Opus 5 แต่ต้องระวังชื่อลอย |
| งานกวาดรายการเชิงกลไก | Haiku 5.5 | ราคาเป็นขั้นตามขนาด prompt งานเล็กใช้ราคาขั้นต่ำ |
ชื่อรุ่นลอยมีความเสี่ยง เอกสารราคาระบุ Fable 5.1 กับ Fable 5 ไว้คนละราคากัน ส่วน Sonnet ราคาต่างกันตาม generation เช่นกัน ดังนั้นทุกครั้งที่เขียนกติกาให้ระบุ generation กำกับเสมอ อย่าเขียนแค่คำว่า Sonnet หรือ Fable แล้วถือว่าจบ ขอแก้ของเดิมด้วยว่าที่เคยเข้าใจว่า Opus 5.5 อ่าน cache ถูกสุดนั้นผิด Sonnet 5.5 อ่าน cache ที่ $0.10 ต่อ MTok ถูกกว่า Opus 5.5 ที่ $0.20 เท่าตัว
ของที่นำไปวางได้เลย
ส่วนนี้มีสองขา คือปรับ setting ให้ระบบบังคับแทนวินัย และเพิ่มจังหวะจัดการ session ให้ทีม
ขาแรกคือ settings ตัวอย่างนี้นำไปปรับกับไฟล์ของตัวเองได้ แต่ต้องตรวจก่อนว่าสคริปต์ hooks มีอยู่จริงในเครื่องแล้ว
{
"env": {
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "400000",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-5-5",
"CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-5-5"
},
"hooks": {
"UserPromptSubmit": [{ "hooks": [{ "type": "command", "command": "python3 ~/.claude/hooks/context-nudge.py", "timeout": 5 }] }],
"SessionStart": [{ "matcher": "clear|startup", "hooks": [{ "type": "command", "command": "python3 ~/.claude/hooks/session-handoff.py", "timeout": 5 }] }]
},
"statusLine": { "type": "command", "command": "~/.claude/hooks/statusline.sh", "refreshInterval": 30 }
}
เส้น compact 400K ยืนยันแล้วว่าใช้ได้ ทั้งสี่รุ่นปัจจุบันมี context window 1M ดังนั้นเส้นนี้อยู่ที่ 40% ของกรอบ ต่ำกว่านี้จะ compact บ่อยจนเสียค่าเขียน cache ใหม่เอง สูงกว่านี้ context จะโตจนค่า read ต่อ turn แพงตาม ค่านี้คือค่าที่เครื่องผู้เขียนใช้จริงอยู่แล้วใน settings.json ชื่อตัวแปร subagent ต้องใช้ชื่อเต็ม CLAUDE_CODE_SUBAGENT_MODEL ชื่อสั้นแบบ bare ใช้ไม่ได้ ส่วนเส้นทางสคริปต์ต้องขึ้นต้นด้วย ~/ ให้ครบก่อนเปิดใช้จริง
ขาที่สองคือกติกา routing ใน CLAUDE.md หลักมีสั้นคือ งานหลักใช้ Sonnet 5.5 ที่ pin แล้ว งานยากระดับ flagship เท่านั้นที่เปิด session ใหม่ด้วย Opus 5.5 งานตัดสินใจเรื่อง taste เปิด session ใหม่ด้วย Fable งานกวาดรายการเชิงกลไกใช้ Haiku 5.5 งานที่สคริปต์ตรวจได้ เช่น diff นับ byte หรือ lint ไม่ต้องใช้โมเดล ทุกครั้งที่เรียก agent ต้องระบุ model กับ effort ห้ามปล่อยให้ inherit เงียบ ส่วนวงจร verify ต้องมีเพดานรอบ และถ้าได้ค่า null ให้ล้มเหลวแบบเสียงดัง ห้าม fallback เป็นคำว่า UNVERIFIED เพราะจะทำให้รายงานดูเสร็จทั้งที่ไม่ได้ตรวจจริง
จังหวะจัดการ session คือ /wrap แล้ว /clear สรุป session ปัจจุบันไม่เกิน 60 บรรทัดลงไฟล์นอก repo เก็บเฉพาะสิ่งที่ session หน้าหาเองจาก repo ไม่ได้ ชี้ตำแหน่งเป็น file:line แทนการแปะโค้ด แล้วให้ hook ตอนเปิด session โหลดกลับมาเอง กติกาจำง่ายมีข้อเดียว คือพักเกินประมาณหนึ่งชั่วโมงไม่ควรกลับไปพิมพ์ต่อในแชทเดิม ส่วนคำสั่ง shell บรรทัดเดียวให้ใช้ ! นำหน้า เพื่อไม่ต้องให้โมเดลอ่านทั้งแชทเพียงเพื่อพิมพ์คำสั่งสั้น
ผลทดสอบจากเครื่องผู้เขียน
ตัวเลขกลไก cache กับราคาข้างต้นยืนยันจากเอกสารทางการแล้ว ส่วนคำแนะนำรุ่นในบทความนี้ผ่านการทดสอบจาก token จริงในเครื่องผู้เขียนแล้ว วิธีคือดึงข้อมูล TokenTracker ฝั่ง Claude จำนวน 1,636 buckets ช่วง พ.ค. ถึง ก.ย. 2026 ได้ปริมาณรวม input 18.2M cache read 1,293.2M cache write 72.1M และ output 15.0M แล้วคูณราคา list ทางการทั้งสองรุ่นโดยสมมติให้ cache write เป็นแบบ 5 นาที
ผลคืองานชุดเดียวกันคิดเป็น Sonnet-5-5 ที่ $496.18 ส่วน Opus-5-5 ที่ $992.37 ต่างกัน 2.00x ในทุกหมวด token และสัดส่วนต่อบิลจำลองคือ cache read 26.1% กับ cache write 36.3% รวมกัน 62.4% อยู่ตรง cache ไม่ใช่ output ผู้เขียนรับผิดชอบตัวเลขชุดนี้เพราะคำนวณซ้ำได้จากข้อมูลในเครื่อง วิธีและข้อสมมติเขียนไว้ครบในบทความนี้แล้ว
ด้านคุณภาพผู้เขียนยังไม่ได้รัน A/B ในเครื่องเอง สิ่งที่มีคือตัวเลขที่ Anthropic รายงานเองใน system card คือ SWE-Bench Pro ทาง Opus 5.5 ได้ 89.9% ส่วน Sonnet 5.5 ได้ 81.3% งานหลายภาษา Opus นำ 93.9% ต่อ 90.3% ขณะที่ Terminal-Bench 4.0 ฝั่ง Sonnet กลับนำ 70.6% ต่อ 66.4% สรุปคือ Opus ยังเป็นเพดานของงานยากที่สุด ส่วน Sonnet ใกล้เคียงในงาน coding ทั่วไปหลายตัวและนำในงาน agentic coding บางชุด ที่ราคาเพียงครึ่งเดียว ตัวเลขชุดนี้ข้าม harness กันตรงไม่ได้ ทีมที่จะยกเป็นมาตรฐานควรจับเวลากับคุณภาพบนงานจริงของตัวเองประกอบอีกชั้น
สิ่งที่ยังค้างพิสูจน์คือการทดสอบนี้วัดแค่ราคา ไม่ได้วัดว่าคุณภาพงานของสองรุ่นต่างกันแค่ไหน สคริปต์ hooks ทั้งสามไฟล์ยังไม่ได้รีวิวโค้ดในรอบนี้ และค่า compact 400K กับขีด context ของแต่ละรุ่นยังไม่ได้เทียบตรง ก่อนประกาศเป็นมาตรฐานทีมควรเช็กสามข้อนี้ก่อน
เอาไปใช้แล้วได้อะไร
ประโยชน์มีสามด้าน คือเงิน เวลา และคุณภาพ ตัวเลขด้านเงินมาจากการทดสอบในเครื่องเราแล้ว ส่วนด้านเวลาและคุณภาพเป็นผลที่คาดจากกลไก ทีมควรวัดซ้ำหลังใช้จริงหนึ่งถึงสองสัปดาห์ก่อนยกระดับเป็นมาตรฐาน
ด้านเงินเห็นชัดสุด งานที่เคยรันบน Opus-5-5 เมื่อย้ายมา Sonnet-5-5 จ่ายครึ่งหนึ่งในทุกหมวด token ตามผลจำลอง $496.18 เทียบ $992.37 ส่วนค่าเขียน cache ใหม่ทั้งก้อนจะลดลงเมื่อใช้ wrap แล้ว clear กับดูเวลาหมดอายุของ cache ก่อนพิมพ์ เพราะ turn ที่เคยจ่ายค่าเขียนใหม่จะกลายเป็น cache read ที่ถูกกว่าหลายเท่า
ด้านเวลาคือไม่ต้องเล่าบริบทใหม่ตอนเปิด session เพราะ handoff โหลดกลับมาเอง และคำสั่ง shell บรรทัดเดียวใช้ ! นำหน้าโดยไม่ต้องเสีย model turn เต็มรอบ ด้านคุณภาพคือ pin generation ทำให้ routing ซ้ำได้ผลเดิม ส่วนเพดาน verify กับการ fail ดังเมื่อได้ null ทำให้รายงานไม่ดูเสร็จทั้งที่ไม่ได้ตรวจจริง
วิธีวัดผลเริ่มจากจดสัดส่วน cache read กับ cache write จาก TokenTracker ไว้ก่อนใช้ แล้วเทียบหลังใช้สองสัปดาห์ ถ้า cold cache ลดลงและบิล API ลดโดยปริมาณงานเท่าเดิม แปลว่ามาตรการได้ผล ถ้าไม่ลด ปัญหาอาจอยู่ที่การแบ่งงาน ไม่ใช่ที่ราคา
สรุปชวนใช้
เริ่มจากทีมตกลงกันสามเรื่อง คือ pin รุ่นพร้อม generation ในกติกาทีม เปิด status line ให้เห็นเวลาหมดอายุของ cache และใช้ wrap แล้ว clear เป็นทางออกจากแชทเก่า จากนั้นค่อยวัดผลหนึ่งถึงสองสัปดาห์ว่า cold cache ลดลงจริงไหม ถ้าลด ค่อยยกระดับเป็นมาตรฐานทีม ถ้าไม่ลด ปัญหาอาจอยู่ที่การแบ่งงาน ไม่ใช่ที่ราคา