คู่มือราคา Claude Opus 4.7 API: $5/$25, Prompt Caching และวิธีนับ Token

ประเด็นสำคัญคือ อย่าใช้สูตร token รวม × ราคาเฉลี่ย เพราะ Opus 4.7 มีราคา input, output, cache write และ cache read คนละชุดกัน ถ้าแอปของคุณใช้ prompt caching การลงบัญชีต้นทุนต้องแยก token แต่ละประเภทตั้งแต่แรก

สูตรคำนวณต้นทุน

กรณีไม่ใช้ prompt caching

สูตรพื้นฐานคือ:

ตัวอย่างเช่น request หนึ่งมี 200,000 input tokens และ 20,000 output tokens หากไม่คิด cache ต้นทุนจะเป็น

$1.00 + $0.50 = $1.50

กรณีใช้ prompt caching

เมื่อเปิด prompt caching ให้คิดทีละรายการแล้วรวมกัน:

ถ้าใช้ TTL หรืออายุ cache เพียงแบบเดียว ก็เก็บเฉพาะรายการ cache write ของ TTL นั้น เอกสาร streaming ของ Anthropic แสดงตัวอย่าง usage ที่มีฟิลด์อย่าง input_tokens, output_tokens, cache_creation_input_tokens และ cache_read_input_tokens ส่วนเอกสาร pricing ก็แยกค่า cache write กับ cache hit ออกจากกัน

นับ token ก่อนส่ง: ใช้ count_tokens ไม่ใช่เดาจากจำนวนตัวอักษร

อย่าประเมินค่า API จากจำนวนตัวอักษร จำนวนคำภาษาอังกฤษ หรือความยาวข้อความแบบคร่าว ๆ โดยเฉพาะ payload ที่มี system prompt, tool definitions, รูปภาพ หรือ PDF วิธีที่ชัดที่สุดคือใช้ endpoint /v1/messages/count_tokens ก่อนส่งคำขอจริง

Anthropic ระบุว่า token counting endpoint นี้รับโครงสร้าง input คล้ายกับการสร้าง message รวมถึง system prompts, tools, images และ PDFs แล้วคืนค่า total input tokens; active models ทั้งหมดรองรับการนับ token แบบนี้

แนวทางที่ปลอดภัยคือ นำ payload ตัวจริงที่จะส่งเข้า Messages API ไปนับด้วย count_tokens ก่อน รวมทั้ง system prompt, messages, tools, รูปภาพ และ PDF วิธีนี้ช่วยประเมินต้นทุน input ล่วงหน้า และเหมาะสำหรับตั้ง budget cap, rate limit หรือระบบแจ้งเตือนในโปรดักต์

หลังเรียก API: ใช้ usage เป็นตัวเลขลงบัญชี

เมื่อ request เสร็จแล้ว ควรบันทึกฟิลด์ usage จาก response ของ API ไม่ใช่ย้อนคำนวณจากความยาวข้อความที่โมเดลตอบกลับ ตัวอย่างใน Messages API แสดงว่า response usage มีฟิลด์อย่าง input_tokens และ output_tokens ส่วนเอกสาร streaming แสดงฟิลด์ที่เกี่ยวกับ cache เช่น cache_creation_input_tokens และ cache_read_input_tokens

ถ้าใช้ streaming ต้องระวังเป็นพิเศษ เอกสาร streaming ของ Anthropic ระบุว่า token counts ใน message_delta.usage เป็นยอดสะสม ไม่ใช่จำนวน token ที่เพิ่มขึ้นในแต่ละ event ดังนั้นถ้านำทุก delta มาบวกกันตรง ๆ จะนับซ้ำ

กระทบยอดรายเดือนและแยกต้นทุนทีม

การบันทึก usage ราย request เหมาะกับการคุมต้นทุนแบบเรียลไทม์ในแอป แต่สำหรับการปิดยอดรายเดือน แยกค่าใช้จ่ายตาม workspace หรือดูแนวโน้มระยะยาว ควรใช้ Usage & Cost Admin API ของ Anthropic ด้วย เอกสารระบุว่า API นี้ให้ข้อมูล historical API usage and cost data แบบละเอียด และสามารถแตก usage report ตาม model, workspace และ service tier ได้

พูดง่าย ๆ คือ ฝั่งแอปควรเก็บ usage เพื่อควบคุมต้นทุนทันที ส่วนการกระทบยอดอย่างเป็นทางการควรอ้างอิงข้อมูล historical usage/cost จาก Usage & Cost Admin API

ย้ายจาก Opus 4.6? อย่าลืมทำ token budget ใหม่

Opus 4.7 ใช้ tokenizer ใหม่ เอกสารของ Anthropic ระบุว่าเมื่อประมวลผลข้อความ tokenizer ใหม่นี้อาจใช้ token ประมาณ 1x ถึง 1.35x เมื่อเทียบกับ previous models หรือสูงสุดราว 35% โดยขึ้นอยู่กับเนื้อหา และข้อความชุดเดียวกันเมื่อนับด้วย /v1/messages/count_tokens บน Opus 4.7 กับ Opus 4.6 จะได้จำนวน token ต่างกัน

ดังนั้น ราคา input $5/MTok และ output $25/MTok ไม่ได้แปลว่าบิลหลังอัปเกรดจะเท่าเดิมเสมอ หากย้ายจาก Opus 4.6 หรือรุ่นเก่ากว่า ควรสุ่ม workflow ที่มีทราฟฟิกสูง prompt ที่มี context ยาว payload ที่มี tool definitions และงานที่แพงที่สุด มารัน /v1/messages/count_tokens ใหม่ แล้วปรับ alert, rate limit และเพดานต้นทุนให้สอดคล้อง

เช็กลิสต์ก่อนเอาเข้า production

• ตรวจว่าใช้ model ID claude-opus-4-7 เมื่อเรียกผ่าน Claude API
• ก่อน release สำคัญ ให้นับ token ของ payload ตัวแทนด้วย /v1/messages/count_tokens
• บันทึก input_tokens, output_tokens, cache write และ cache read แยกกัน อย่าเก็บแค่ total token อย่างเดียว
• ถ้าใช้ streaming อย่าบวก message_delta.usage ทุก event เพราะค่านั้นเป็นยอดสะสม
• สำหรับการปิดยอดระดับทีม แยก workspace หรือวิเคราะห์แนวโน้มย้อนหลัง ใช้ Usage & Cost Admin API
• ก่อนย้ายจาก Claude รุ่นเก่ามา Opus 4.7 ให้ทดสอบผลของ tokenizer ใหม่กับ prompt จริงของระบบ

สรุปสั้น ๆ: ราคา Claude Opus 4.7 API จำได้ง่ายว่า input $5/MTok และ output $25/MTok แต่การคุมงบให้แม่นต้องนับ token ก่อนส่งด้วย count_tokens, บันทึก usage หลังส่ง และแยก prompt caching กับผลของ tokenizer ใหม่ออกจากต้นทุนหลัก