Claude token คืออะไร คำนวณโทเค็นใน Claude Code

โทเค็นใน Claude คืออะไร

โทเค็นคือหน่วยข้อความที่ Claude อ่านและเขียน ซึ่งอาจเป็นส่วนหนึ่งของคำ โดย glossary ของ Anthropic ระบุว่า ในโมเดลก่อน Claude Opus 4.7 โทเค็นมีขนาดประมาณ 3.5 อักขระภาษาอังกฤษ ส่วน tokenizer รุ่นปัจจุบันมีขนาดใกล้ 2.5 อักขระมากกว่า เนื่องจาก Anthropic ระบุว่า 1M โทเค็นมีขนาดประมาณ 2.5M อักขระ อย่างไรก็ตาม เมื่อรวมช่องว่างและเครื่องหมายวรรคตอนแล้ว จำนวนโทเค็นจะมากกว่า 1 โทเค็นต่อคำอยู่มาก ดังนั้นข้อความร้อยแก้ว 1,000 คำจึงมีมากกว่า 1,300 โทเค็นได้อย่างสบาย โค้ดใช้โทเค็นมากกว่าต่อบรรทัด เนื่องจากวงเล็บปีกกา ตัวดำเนินการ เครื่องหมายขีดล่าง และการเยื้องบรรทัดถูกแยกเป็นโทเค็นมากกว่าเมื่อเทียบกับจำนวนอักขระในภาษาอังกฤษ ไฟล์ซอร์สที่มีไม่กี่ร้อยบรรทัดจึงมักมีขนาดหลายพันโทเค็น ไฟล์ขนาด 2,000 บรรทัดที่ agent ตัดสินใจอ่าน อาจใช้โทเค็นระดับห้าหลักก่อนที่จะมีการเขียนโค้ดใหม่แม้แต่บรรทัดเดียว

มี 2 ประเด็นเกี่ยวกับ tokenizer ที่ทำให้เกิดความเข้าใจผิด ประการแรก tokenizer ขึ้นอยู่กับโมเดล ณ เดือน October 2026 Claude Opus 4.7 และโมเดลรุ่นหลังทั้งหมด รวมถึง Fable 5.1, Opus 5.5, Sonnet 5.5 และ Haiku 5.5 รุ่นปัจจุบัน ใช้ tokenizer รุ่นใหม่ที่สร้างโทเค็นมากกว่าข้อความเดียวกันในโมเดล Claude รุ่นก่อน เช่น Haiku 4.5 ประมาณ 30% โดยอัตราที่เพิ่มขึ้นจริงจะแตกต่างกันตามเนื้อหา การเปลี่ยนแปลงนี้ทำให้การประมาณงบประมาณที่คิดเป็นโทเค็นเปลี่ยนไป แม้ราคาต่อโทเค็นจะไม่ได้เพิ่มขึ้นตาม ประการที่สอง tiktoken ซึ่งเป็น library ที่บทความในบล็อกมักเลือกใช้ คือ tokenizer ของ OpenAI ไม่ใช่ของ Claude ดังนั้นจำนวนที่นับได้จึงไม่ตรงกับจำนวนที่ Anthropic เรียกเก็บ วิธีนับที่เชื่อถือได้เพียงวิธีเดียวคือ endpoint count_tokens ซึ่งจะอธิบายในส่วนถัดไป

เหตุใดเซสชันการเขียนโค้ดของคุณจึงมีค่าใช้จ่ายเช่นนั้น

ค่าใช้จ่ายของ Claude ทุกประเภท ไม่ว่าจะเป็นใบแจ้งหนี้ API หรือขีดจำกัดของ subscription ล้วนคำนวณจากมิเตอร์หลักเดียวกันเป็นส่วนใหญ่ นั่นคือ token ที่ส่งเข้าและส่งออก เครื่องมือ API บางรายการมีค่าใช้จ่ายแยกต่างหาก เช่น web search มีค่าใช้จ่าย $10 ต่อการค้นหา 1,000 ครั้ง ณ เดือน October 2026 นอกเหนือจาก token ที่ผลลัพธ์เพิ่มเข้ามา แต่ในการทำงานเขียนโค้ด มิเตอร์ token เป็นตัวที่เพิ่มขึ้นเป็นหลัก หน้าราคาอาจทำให้ดูเรียบง่าย โดยระบุค่าใช้จ่ายจำนวนหนึ่งต่อ input token 1 ล้านรายการ และอีกจำนวนหนึ่งต่อ output token 1 ล้านรายการ แต่สิ่งที่ไม่ได้ระบุคือ ในเซสชันการเขียนโค้ดแบบ agentic ฝั่ง input ของมิเตอร์ทำงานสูงกว่าที่คาดจากความเข้าใจทั่วไปมาก เพราะระบบจะส่งบทสนทนาทั้งหมดซ้ำในการโต้ตอบแต่ละครั้ง ผมขายโครงสร้างพื้นฐานแบบคิดตามการใช้งานมา 15 ปี และ token เป็นมิเตอร์ตัวแรกที่ผมพบว่าลูกค้าส่วนใหญ่ไม่สามารถบอกได้อย่างแท้จริงว่าอะไรเป็นตัวทำให้มิเตอร์เพิ่มขึ้น บทนี้จะอธิบายวิธีอ่านมิเตอร์ดังกล่าว: อะไรนับเป็น input และ output ในเซสชันแบบ agentic เหตุใดการส่งซ้ำในแต่ละรอบจึงมีค่าใช้จ่ายสูง เหตุใด prompt caching จึงเปลี่ยนวิธีคำนวณ และตัวแปรใดที่ส่งผลต่อตัวเลขจริง

ทุกอย่างคือ input: สิ่งที่ meter นับจริง

ผู้ใช้มักคิดว่าตนเองจ่ายสำหรับโค้ดที่ Claude เขียน ใน session แบบ agentic ค่าใช้จ่ายส่วนนั้นมีสัดส่วนไม่มากนัก input tokens ซึ่งมีอัตราค่าบริการถูกกว่าแต่มีปริมาณสูงกว่ามาก ประกอบด้วย:

• System prompt คำสั่งของ harness ที่ Claude Code ใช้ รวมถึง CLAUDE.md และไฟล์ memory ซึ่งโหลดเมื่อเริ่ม session และยังอยู่ในทุก request หลังจากนั้น
• คำจำกัดความของ tool schema ของทุก tool ที่ agent อาจเรียกใช้ ทุก MCP server ที่คุณเชื่อมต่อ จะเพิ่ม overhead คงที่ส่วนนี้ แม้ปัจจุบัน Claude Code จะเลื่อนการโหลดคำจำกัดความ tool ของ MCP แบบเต็มไว้เป็นค่าเริ่มต้น ดังนั้นใน context จะมีเพียงชื่อ tool จนกว่าจะมีการใช้ tool ครั้งแรก วิธีนี้ช่วยลดค่าใช้จ่ายได้บางส่วน แต่ไม่ได้ตัดค่าใช้จ่ายทั้งหมด
• ไฟล์ทุกไฟล์ที่ agent อ่าน การทำ Read กับไฟล์ source จะนำเนื้อหาทั้งหมดเข้า context และเนื้อหานั้นจะยังคงอยู่ใน context
• ผลลัพธ์จาก tool ทุกครั้ง ผลการทดสอบ output จาก grep ข้อความจาก terminal และ build log ทั้งหมดจะกลับมาเป็น input tokens หาก test suite ที่ล้มเหลวพิมพ์ออกมา 8,000 บรรทัด ก็มีขนาดใกล้เคียงกับหนังสือเล่มเล็ก ณ เดือน October 2026 Claude Code จะส่ง command output ประมาณ 30,000 characters ในข้อความโดยตรงเป็นค่าเริ่มต้น และหากยาวกว่านั้นจะส่งเป็นไฟล์ที่บันทึกไว้พร้อม preview ความยาวไม่เกิน 2,000 characters แต่ output ทุกส่วนที่อยู่ต่ำกว่าเพดานนี้ รวมถึงการอ่านไฟล์ที่บันทึกไว้ในภายหลัง จะถูกคิดค่าบริการเต็มจำนวน
• บทสนทนาทั้งหมดจนถึงตอนนี้ ซึ่งส่งซ้ำในทุก turn ประเด็นนี้ควรมี section แยกเป็นของตัวเอง

ค่าใช้จ่ายจากการส่งซ้ำที่ไม่มีใครนึกถึง

Claude API ไม่มีสถานะ โดยจะไม่จดจำเซสชันระหว่างคำขอ และไม่มีสิ่งใดทำเช่นนั้น ดังนั้นใน turn 2 ไคลเอนต์จะส่ง turn 1 พร้อมคำตอบของโมเดลและข้อความใหม่ของคุณไปด้วย ส่วนใน turn 50 ไคลเอนต์จะส่งทุกสิ่งที่ยังอยู่ใน context จาก turn 1 ถึง turn 49 ซ้ำอีกครั้ง ซึ่งรวมถึงไฟล์ที่อ่าน ผลลัพธ์จาก tool และ diff ที่ยังไม่ได้ถูก compact รวมทั้ง turn 50 ด้วย (การ compact จะแทนที่ประวัติเก่าด้วยสรุป ส่วนการอ่านไฟล์ของ subagent จะยังอยู่ใน context ของ subagent เอง และส่งกลับมาเฉพาะผลลัพธ์ของมัน) โมเดลจะอ่าน transcript ที่ยังเก็บไว้อยู่ทั้งหมดใหม่ทุกครั้ง และ token ที่ถูกอ่านซ้ำเหล่านั้นจะถูกคิดเป็น input ทั้งหมด

ผลที่ตามมาคือ ค่าใช้จ่ายต่อ turn จะเพิ่มขึ้นโดยประมาณตามความยาวของเซสชัน และค่าใช้จ่ายรวมของเซสชันจะเพิ่มขึ้นโดยประมาณแบบกำลังสอง ข้อความที่มีค่าใช้จ่ายครึ่งเซนต์ใน turn 3 อาจมีค่าใช้จ่ายสูงกว่านั้น 20 เท่าใน turn 60 แม้เป็นคำถามหนึ่งบรรทัดเดียวกัน เพราะต้องส่งข้อมูลของทั้ง 60 turn ไปด้วย ข้อเท็จจริงนี้เป็นสาเหตุหลักที่อธิบาย ticket ประเภท “เหตุใดบิลจึงสูงมาก” ได้เกือบทั้งหมด และไม่ได้เป็นลักษณะเฉพาะของ Claude เพราะผลิตภัณฑ์ LLM ทุกชนิดที่ให้ความรู้สึกเหมือนมีสถานะ ล้วนเป็น API แบบไม่มีสถานะที่มีลูปส่งข้อมูลซ้ำอยู่เบื้องหลัง

ผลลัพธ์: สิ่งที่คุณเห็น และกระบวนการคิดที่คุณไม่เห็น

Output tokens มีราคาสูง โดยมีอัตราค่าบริการเป็น 5 เท่าของ input tokens ในกลุ่มโมเดลปัจจุบัน (ราคา ณ เดือนตุลาคม 2026 คือ $10/$50 สำหรับ Fable 5.1, $4/$20 สำหรับ Opus 5.5, $2/$10 สำหรับ Sonnet 5.5 และ $0.10/$0.50 สำหรับ Haiku 5.5 สำหรับ prompt ที่มีความยาวไม่เกิน 100,000 tokens) Output รวมถึงข้อความและโค้ดที่ Claude สร้างขึ้น และ thinking tokens: ซึ่งเป็นกระบวนการใช้เหตุผลภายในที่โมเดลทำก่อนตอบคำถาม มีข้อเท็จจริง 2 ประการที่ต้องทราบ: การคิดจะถูกเรียกเก็บเงินในอัตรา output และนับรวมใน max_tokens การตอบสนองของ API ที่สิ้นสุดลงด้วย stop_reason: "max_tokens" และคำตอบที่ถูกตัดทอนมักหมายความว่ากระบวนการคิดได้ใช้โควตาจนหมดก่อนที่จะได้คำตอบ และในโมเดลปัจจุบัน สรุปกระบวนการใช้เหตุผลอาจไม่แสดงผลให้เห็น โดย API จะละเว้นส่วนนี้ไว้เป็นค่าเริ่มต้นใน Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5 และโมเดลรุ่นก่อนหน้าย้อนไปถึง Opus 4.7 แต่กระบวนการคิดยังคงเกิดขึ้นและถูกเรียกเก็บเงิน สิ่งที่มองไม่เห็นไม่ได้หมายความว่าฟรี

Claude Code เปิดใช้งาน extended thinking เป็นค่าเริ่มต้นเนื่องจากช่วยปรับปรุงงานหลายขั้นตอนได้อย่างชัดเจน และงบประมาณเริ่มต้นอาจสูงถึงหลายหมื่น tokens ต่อคำขอ สำหรับงานที่ง่ายกว่า คุณสามารถปรับลดระดับลงได้: ลดระดับความพยายามด้วย /effort หรือใน /model หรือปิดการคิดใน /config สำหรับโมเดลที่อนุญาต ณ เดือนตุลาคม 2026 Claude Code ไม่สามารถปิดการคิดใน Opus 5.5, Sonnet 5.5, Haiku 5.5 หรือโมเดล Fable ได้ ดังนั้นระดับความพยายาม (effort) จึงเป็นตัวแปรเดียวที่ปรับได้ API ให้พื้นที่คุณมากขึ้นในสองโมเดล: Haiku 5.5 รองรับ thinking: {"type": "disabled"} ที่ระดับความพยายาม high หรือต่ำกว่า เช่นเดียวกับ Opus 5 รุ่นเก่า ในขณะที่ Sonnet 5 รุ่นเก่ารองรับที่ทุกระดับความพยายาม รวมถึง xhigh และ max สำหรับ Sonnet 5.5 จะปฏิเสธ "disabled" และรับ thinking: {"type": "between_tools"} แทน ซึ่งจะลดการคิดล่วงหน้าในระดับความพยายาม low, medium หรือ high ดังนั้นคำขอที่ไม่มีการใช้เครื่องมือจะได้รับคำตอบโดยไม่มีการคิดก่อน มีเพียง Opus 5.5 และโมเดล Fable เท่านั้นที่ยังคงเปิดการคิดไว้ไม่ว่าคุณจะส่งอะไรไป นี่คือตัวแปรด้านต้นทุนที่แท้จริง ไม่ใช่ความเชื่อส่วนบุคคล

Prompt caching เปลี่ยนการคำนวณต้นทุน

Prompt caching คือเหตุผลที่การส่งซ้ำเป็นลูปไม่ทำให้ทุกคนมีค่าใช้จ่ายจนรับไม่ไหว API สามารถ cache prefix ที่คงที่ของ prompt, system prompt, tool definitions และประวัติการสนทนา แล้วใช้ prefix นี้กับคำขอถัดไปในราคาส่วนหนึ่งของราคาปกติ ณ เดือน October 2026 ตัวคูณมีดังนี้: การ เขียน cache มีค่าใช้จ่าย 1.25× ของอัตรา input พื้นฐาน (2× สำหรับรูปแบบ 1-hour) และการ อ่าน cache มีค่าใช้จ่าย 0.1× ในโมเดลส่วนใหญ่, 0.05× ใน Claude Opus 5.5 และ Claude Sonnet 5.5 และ 0.025× ใน Claude Fable 5.1 การเขียนมีค่าใช้จ่ายเพิ่ม ส่วนการอ่านลดราคา 90% ในโมเดลส่วนใหญ่, 95% ใน Opus 5.5 และ Sonnet 5.5 และ 97.5% ใน Fable 5.1 (อัตราการอ่านของ Sonnet 5.5 ลดจาก 0.1× เป็น 0.05× เมื่อ October 7, 2026) การอ่านเพียงครั้งเดียวก็ชดเชยค่าใช้จ่ายส่วนเพิ่มของการเขียนแบบ 5-minute ได้มากกว่าแล้ว

Claude Code จัดการ cache ให้คุณ และใน session ที่ทำงานเป็นปกติ การส่งซ้ำขนาดใหญ่เกือบทั้งหมดจะให้บริการจาก cache แต่ cache จะหมดอายุหลังไม่มีการใช้งานต่อเนื่องระยะหนึ่ง ณ เดือน October 2026 Claude Code ให้ conversation หลักของคุณใช้ cache แบบ one-hour เมื่อใช้ subscription ภายในโควตาที่รวมอยู่ใน plan และให้ใช้เวลา five minutes นับจากการใช้งานครั้งล่าสุดเมื่อใช้ API key, cloud provider หรือเมื่อเริ่มใช้ usage credits (การตั้งค่า promptCacheTtl สามารถขอระยะเวลา 1 ชั่วโมงในกรณีดังกล่าวได้ โดยใช้อัตราค่าการเขียน 2×) หากใช้ cache แบบ five-minute แล้วหยุดไปดื่มกาแฟนานกว่าที่คิด กลับมาและส่งข้อความ cache จะหมดอายุ ทำให้ต้องเขียน prefix ที่สะสมไว้ทั้งหมดใหม่ที่อัตรา 1.25× แทนการอ่านด้วยอัตรา cache ใน session ขนาด 150K-token การส่งคำขอครั้งแรกหลัง cache หมดอายุจะเขียนทั้ง 150K tokens ที่อัตรา 1.25× ขณะที่การส่งคำขอระหว่างที่ cache ยังใช้งานได้จะอ่านด้วยอัตรา 0.1× จึงต่างกัน 12.5 เท่าสำหรับ prefix (25 เท่าใน Opus 5.5 และ Sonnet 5.5 และ 50 เท่าใน Fable 5.1) ผลที่ขัดกับความเข้าใจทั่วไปและควรจำไว้คือ การทำงานต่อหลังปล่อยให้ระบบว่างอาจมีค่าใช้จ่ายมากกว่าการทำงานต่อเนื่อง เพราะทุกช่วงว่างที่นานเกิน TTL จะเปลี่ยนการส่งคำขอครั้งถัดไปจากการอ่านราคาถูกเป็นการเขียนใหม่ที่มีราคาแพง ควรทำงานเป็นช่วง ๆ และเมื่อใช้ cache แบบ five-minute อย่าทยอยส่งข้อความใน session ขนาดใหญ่เพียง 1 ข้อความทุก 10 นาที

หากคุณเรียกใช้ API จาก แอปพลิเคชันของคุณเองบน VPS จะไม่มีการทำงานเหล่านี้โดยอัตโนมัติ คุณต้องเปิดใช้ด้วย cache_control และปัญหาที่เกิดจากการตั้งค่าเองซึ่งพบบ่อยคือการแทรก timestamp หรือ request ID ลงใน system prompt ทำให้ bytes ของ prefix เปลี่ยนไปในทุก request และปิดการทำงานของ caching โดยไม่แสดงข้อผิดพลาด จุดสังเกตคือ usage.cache_read_input_tokens มีค่าเป็นศูนย์ในคำขอที่ดูเหมือนเหมือนกันทุกประการ

สูตรคำนวณพร้อมตัวอย่าง

อย่าเชื่อคำกล่าวที่ว่า “หนึ่ง session มีค่าใช้จ่าย $X” แบบอัตราคงที่ ค่าใช้จ่ายของ session อาจแตกต่างกันถึง 2 ลำดับขนาด สิ่งที่ใช้ได้จริงคือสูตรคำนวณ:

turn cost = (uncached input        x base input price)
          + (cache writes          x 1.25 x base input price)
          + (cache reads           x read multiplier x base input price)
          + (output incl. thinking x output price)

read multiplier = 0.10 on most models, 0.05 on Opus 5.5 and Sonnet 5.5, 0.025 on Fable 5.1
session cost = sum over all turns

ตัวอย่างการคำนวณบน Claude Opus 4.8 ซึ่งปัจจุบันเป็นโมเดล legacy แต่ยังใช้งานได้ และ ณ เดือน October 2026 ยังคงมีราคา $5 ต่อ input tokens 1 ล้านรายการ และ $25 ต่อ output 1 ล้านรายการ สมมติว่าเป็น turn กลาง session ที่มี context สะสม 80,000 tokens โดยอ่านจาก cache 75,000 รายการ เขียนเพิ่ม 3,000 รายการ มี fresh input ที่ไม่อยู่ใน cache 2,000 รายการ และมี output 1,500 tokens รวมส่วน thinking แล้ว

• การอ่านจาก cache: 75,000 × $0.50/M = $0.0375
• การเขียนลง cache: 3,000 × $6.25/M = $0.019
• input ที่ไม่อยู่ใน cache: 2,000 × $5/M = $0.010
• output: 1,500 × $25/M = $0.0375

รวมประมาณ $0.10 ต่อ turn หากมี 50 turn ในลักษณะเดียวกัน จะอยู่ที่ประมาณ $5 ลองพิจารณา turn เดิมหลังจาก cache หมดอายุ: tokens ที่นำกลับมาใช้ใน cache จำนวน 78,000 รายการต้องเขียนใหม่ด้วยราคา $6.25/M รวมกับ uncached tokens จำนวน 2,000 รายการที่ราคา $5/M จะเป็นประมาณ $0.50 ก่อนคิดค่า output หรือประมาณ 5 เท่าของ warm turn ทั้งหมด ทั้งที่เป็นงานเดียวกัน ความแตกต่างนี้สรุปประเด็นของ caching ได้ทั้งหมดในตัวเลขเดียว สำหรับ Claude Opus 5.5 รุ่นปัจจุบัน ($4/$20 โดยการอ่านจาก cache มีราคา 0.05×) warm turn เดิมมีค่าใช้จ่ายประมาณ $0.07 (การอ่าน $0.015, การเขียน $0.015, input ที่ไม่อยู่ใน cache $0.008 และ output $0.030) ส่วน cold version มีค่าใช้จ่าย $0.40 ก่อนคิดค่า output หรือเกือบ 6 เท่าของ warm turn วิธีคำนวณ 4 บรรทัดนี้ยังเป็นวิธีเดียวที่ใช้เปรียบเทียบผู้ให้บริการได้อย่างตรงไปตรงมา เพราะอัตราราคาที่แสดงไว้ไม่รวมการอ่านจาก cache และ thinking และเมื่อนำไปทดสอบกับงานจริง 3 งาน จะเห็น ว่าค่า Claude สูงหรือต่ำกว่าค่า OpenAI ตรงไหน

หากต้องการทำความเข้าใจหน่วยคิดค่าบริการเอง แทนที่จะดูเพียง turn เดียว การคำนวณว่า tokens 1 ล้านรายการเทียบเป็นหน้าไฟล์ ไฟล์ และค่าใช้จ่ายได้เท่าใด จะทำการคำนวณแบบเดียวกันในระดับที่ใหญ่ขึ้น ตัวเลขของ Anthropic ที่เผยแพร่สำหรับการใช้งาน Claude Code ในองค์กร ณ เดือน October 2026 ระบุว่า โดยเฉลี่ยมีค่าใช้จ่ายประมาณ $13 ต่อนักพัฒนาต่อวันที่ใช้งานจริง และ $150 ถึง $250 ต่อเดือน โดยผู้ใช้ 90% มีค่าใช้จ่ายไม่เกิน $30 ต่อวัน ตัวเลขที่เกิดขึ้นจริงขึ้นอยู่กับการเลือกโมเดล การจัดการ session และขนาด codebase ซึ่งเป็นเหตุผลโดยตรงว่าทำไมปัจจัยควบคุมด้านล่างจึงมีความสำคัญ

การดูการใช้งานของคุณ

ใน Claude Code คำสั่งคือ /usage (/cost ยังคงใช้งานได้ เป็นเพียงชื่อเรียกแทน) ส่วน Session ที่ด้านบนจะแสดงสถิติ token และการประมาณค่าใช้จ่ายที่คำนวณในเครื่องสำหรับเซสชันปัจจุบัน สำหรับแผนการสมัครสมาชิก หน้าจอเดียวกันจะแสดงแถบขีดจำกัดของแผนและรายละเอียดการใช้งานล่าสุดที่แบ่งตามทักษะ, subagents, ปลั๊กอิน และ MCP servers แต่ละตัว ในเวอร์ชันล่าสุด ส่วน Session ยังมีบรรทัด Prompt cache (main) ที่แสดงสัดส่วนของ input ที่ดึงมาจาก cache, จำนวนที่พลาด (misses) และสถานะว่า cache พร้อมใช้งานหรือไม่ สำหรับการเรียกเก็บเงินที่ถูกต้องแม่นยำในบัญชี API หน้าการใช้งานใน Claude Console คือแหล่งข้อมูลที่เชื่อถือได้ ส่วนตัวเลขใน CLI เป็นเพียงการประมาณการ /context จะวาดตารางสีของ สิ่งที่กำลังใช้พื้นที่ใน context window เช่น system prompt, เครื่องมือ, คำจำกัดความของ MCP, ไฟล์, ประวัติ และเป็นวิธีที่เร็วที่สุดในการตรวจหา CLAUDE.md ที่บวมหรือ MCP server ที่ส่งข้อมูลมากเกินไป ในโหมดเต็มหน้าจอ มันจะยุบรายละเอียดของแต่ละรายการ และการส่ง all จะเป็นการขยายรายละเอียดเหล่านั้น

จาก API การตอบสนองแต่ละครั้งจะบอกคุณอย่างชัดเจนว่าเกิดอะไรขึ้น:

response = client.messages.create(model="claude-sonnet-5-5", max_tokens=2048,
                                  messages=messages)
u = response.usage
total_prompt = u.input_tokens + u.cache_creation_input_tokens + u.cache_read_input_tokens
print(f"uncached={u.input_tokens} written={u.cache_creation_input_tokens} "
      f"read={u.cache_read_input_tokens} output={u.output_tokens}")

โปรดทราบว่า input_tokens คือ ส่วนที่เหลือที่ไม่ได้ถูกแคช เท่านั้น ขนาดของ prompt ที่แท้จริงคือผลรวมของ input ทั้ง 3 ช่อง Agent ที่ทำงานเป็นเวลาหนึ่งชั่วโมงโดยแสดง input_tokens: 4000 ไม่ได้หมายความว่าราคาถูก เพราะอีก 200,000 tokens ที่เหลือถูกดึงมาจาก cache หากต้องการประมาณการก่อนส่ง ให้ใช้ endpoint สำหรับนับจำนวน token ซึ่งเรียกใช้งานได้ฟรี มีขีดจำกัดอัตราการเรียกของตัวเอง และนับด้วย tokenizer ของโมเดลที่คุณระบุ (ให้ถือว่าผลลัพธ์เป็นการประมาณการที่ใกล้เคียง การเรียกเก็บเงินจะสะท้อนตามคำขอจริง):

count = client.messages.count_tokens(model="claude-sonnet-5-5",
                                     messages=[{"role": "user", "content": big_file}])
print(count.input_tokens)

ห้ามใช้ tiktoken ด้วยเหตุผลข้างต้น

แผนแบบสมาชิกเทียบกับการใช้งานแบบจ่ายตามจริง

กลไกในคู่มือนี้เหมือนกันทุกกรณี ความแตกต่างมีเฉพาะวิธีคิดค่าบริการเท่านั้น เมื่อใช้ API key, Anthropic จะคิดค่าบริการแบบจ่ายตามจริงตามจำนวน token และอัตราที่ประกาศไว้ ดังนั้นตัวเลขทั้งหมดข้างต้นจึงเป็นค่าใช้จ่ายเงินจริง มิเตอร์นี้เริ่มนับเร็วกว่าที่หลายคนคาด เพราะไม่มี free tier ให้ใช้ มีเพียงเครดิตจำนวนเล็กน้อยตอนสมัคร และ endpoint บางรายการที่ไม่คิดค่าบริการ ซึ่งก็คือ สิ่งที่บัญชี API ใหม่ได้รับจริงก่อนเพิ่มบัตรสำหรับเรียกเก็บเงิน ข้อยกเว้นตั้งแต่ October 7, 2026 คือสมาชิกแบบ Max หรือ Team แผนเหล่านี้มีเครดิต API รายเดือนสำหรับแอปและ agent ของคุณเองบน Claude Platform แล้ว โดย Max 5x ได้รับ $100 ต่อเดือน, Max 20x ได้รับ $200 ต่อเดือน และ Team ได้รับ $20 ต่อ Standard seat และ $100 ต่อ Premium seat โดยรวมเครดิตเข้าด้วยกันและจำกัดวงเงินที่ $500 คุณต้องเชื่อมโยง Console organization เพื่อรับเครดิต เครดิตที่ไม่ได้ใช้จะหมดอายุเมื่อสิ้นสุดรอบการเรียกเก็บเงินแต่ละรอบ และไม่ครอบคลุมการใช้งาน Claude Code แบบโต้ตอบ สำหรับ Claude subscription ได้แก่ Pro, Max, Team และ Enterprise แบบคิดตาม seat รุ่นเดิม การใช้งาน Claude Code จะหักจากโควตาที่แผนรวมไว้แทน โดย ณ October 2026 จะเป็นหน้าต่างการใช้งานแบบต่อเนื่อง 5 ชั่วโมงและหน้าต่างรายสัปดาห์ ใช้ร่วมกันระหว่างโมเดลและแชตบน claude.ai และตัวเลขดอลลาร์ /usage เป็นเพียงข้อมูล ไม่ใช่ยอดเรียกเก็บเงิน ข้อยกเว้น 2 รายการ ณ October 2026 คือ Enterprise seat รุ่นปัจจุบันที่คิดตามการใช้งานไม่มีโควตาการใช้งานรวมเลย ดังนั้นทุก token จะถูกคิดตามอัตรา API มาตรฐาน และ Fable models ไม่รวมอยู่ในโควตาของ Pro, Standard Team seat หรือ Standard Enterprise seat รุ่นเดิม โดยจะคิดจาก usage credits แบบจ่ายตามจริงแทน เมื่อใช้หน้าต่างใดจนหมด คุณจะเห็นข้อความ "You've hit your session limit" หรือ "You've hit your weekly limit" พร้อมเวลาที่จะรีเซ็ต การเปลี่ยนโมเดลด้วย /model จะไม่ทำให้กลับมาใช้งานได้ เพราะหน้าต่างเหล่านี้ใช้ร่วมกันระหว่างโมเดล หน้าต่างดังกล่าวผูกกับบัญชี ไม่ใช่ client ที่คุณกำลังใช้งานอยู่ จึงควรทราบเรื่องนี้หากคุณกำลังตรวจสอบ สิ่งที่ทำงานบน Linux ได้โดยตรงและแต่ละแผนครอบคลุมการใช้งานส่วนใด หน้าต่างใดที่ใช้จนหมดจะเป็นตัวกำหนดว่าต้องรอนานเท่าใดและควรทำอะไรระหว่างนั้น ดังนั้นควรทราบ ทางเลือกเมื่อถึงขีดจำกัดระหว่างทำงาน แผนต่างๆ สามารถเปิดใช้ usage credits ได้ตามต้องการ โดยจัดการผ่าน /usage-credits เพื่อซื้อการใช้งานเพิ่มเติมหลังถึงขีดจำกัด ฉันจะไม่แสดงโควตาของแผน เพราะเป็นตัวเลขที่เปลี่ยนแปลงบ่อยที่สุดในหัวข้อนี้ ให้ตรวจสอบที่ claude.com/pricing และแถบ /usage ของบัญชีคุณเอง กลไกการคิดตาม token ยังคงสำคัญแม้ใช้แผนสมาชิก เซสชันที่ใช้ทรัพยากรสิ้นเปลืองจะทำให้หน้าต่างการใช้งานลดลงเช่นเดียวกับการเสียค่าใช้จ่ายเป็นดอลลาร์ สำหรับส่วนของแผนสมาชิก โปรดดู แผน Claude ที่เหมาะกับรูปแบบการใช้งานของคุณ

แนวทางที่ให้ผลจริง

• กำหนดขอบเขตไฟล์ที่ agent อ่าน “แก้ bug ของการตรวจสอบใน auth.py” จะอ่านเพียงไฟล์เดียว ส่วน “ปรับปรุง codebase นี้” จะอ่าน 40 ไฟล์ ควรรักษา CLAUDE.md ให้กระชับ เพราะถูกโหลดในทุก session จึงควรใส่เฉพาะสิ่งจำเป็น และย้ายคำสั่งเฉพาะ workflow ไปไว้ใน skill ที่โหลดเมื่อจำเป็น
• ชัดเจนและกระชับ /clear ระหว่างงานที่ไม่เกี่ยวข้องกัน เพราะ context ที่ล้าสมัยจะถูกส่งซ้ำและถูกคิดค่าบริการอีกครั้งในทุกข้อความถัดไป ภายในงานยาวงานเดียว /compact Focus on the failing tests and the diff จะสรุปประวัติให้สั้นลงและช่วยหลีกเลี่ยงการเพิ่มขึ้นแบบ quadratic
• เลือกขนาด model ให้เหมาะสม Sonnet รองรับงานเขียนโค้ดส่วนใหญ่ ในราคา $2/$10 ต่อล้าน token ณ เดือน October 2026 ซึ่งปัจจุบันเป็นราคามาตรฐาน ไม่ใช่ราคาแนะนำช่วงเปิดตัว: Sonnet 5.5 อยู่ที่ $2/$10 และ Sonnet 5 ยังคงราคา $2/$10 หลังจากยกเลิกการปรับขึ้นตามแผนจาก $2/$10 เป็น $3/$15 ในวันที่ September 1 เมื่อเปรียบเทียบกันแล้ว Opus 5.5 อยู่ที่ $4/$20 ส่วน Haiku 5.5 อยู่ที่ $0.10/$0.50 (สำหรับ prompt ไม่เกิน 100,000 token และ $0.50/$2.50 สำหรับส่วนที่เกิน) จึงเหมาะกับงานของ subagent ที่เป็นงานเชิงกลไก เช่น การคัดกรอง log ส่วน Fable 5.1 อยู่ที่อีกระดับหนึ่ง คือ $10/$50 ซึ่งเป็นอัตราเดียวกับ Fable 5 และสูงกว่า Opus 5.5 สองเท่าครึ่งทั้งฝั่ง input และ output ดังนั้นควรทราบ ว่างานใดคุ้มค่ากับอัตรานี้จริง ก่อนปล่อยให้เลือก model นี้ไว้สำหรับงานประจำ /model จะสลับ model ระหว่าง session
• กรอง output ที่มีรายละเอียดมากล่วงหน้า hook ที่ใช้ grep เพื่อตัดผลการทดสอบให้เหลือเฉพาะ failure ก่อนที่ Claude จะเห็น จะลดผลลัพธ์จาก tool จาก 20,000 token เหลือ 300 token และการส่ง turn นั้นซ้ำในอนาคตก็จะใช้ผลลัพธ์ที่สั้นลงนี้ทุกครั้ง
• รวมงานที่ไม่ต้องโต้ตอบแบบทันที สำหรับ API pipeline ของคุณเอง งานจัดประเภท งาน review จำนวนมาก และงานที่ทำทุกคืน Batches API จะรัน model เดิมในราคาลด 50% แลกกับการส่งผลลัพธ์แบบ asynchronous
• คำนึงถึงอายุของ cache ทำงานต่อเนื่องเป็นช่วง ๆ session ของ Claude Code ใน tmux บน VPS ที่แยกทำงานอยู่ จะไม่เสียค่าใช้จ่ายขณะ idle โดยจะใช้ token เฉพาะเมื่อมีการรัน turn แต่หาก idle เกิน cache TTL จะไม่สามารถใช้ warm cache ต่อได้ และ turn ถัดไปจะต้องเสียค่าใช้จ่ายสำหรับการเขียน context ใหม่

FAQ

เซสชันเขียนโค้ดใน Claude Code ใช้โทเคนกี่โทเคน?

ไม่มีจำนวนตายตัว การโต้ตอบหนึ่งครั้งระหว่างเซสชันมักมี prompt tokens หลายหมื่นโทเคนเมื่อไฟล์และประวัติสะสมเพิ่มขึ้น และเซสชันที่ใช้งานจริงอาจมีจำนวนรวมหลายล้านโทเคน โดยส่วนใหญ่ให้บริการจาก cache ในอัตราไม่ถึงหนึ่งในสิบของอัตราพื้นฐาน ทั้งนี้ขึ้นอยู่กับ model ตัวเลขอ้างอิงจากข้อมูลระดับองค์กรที่ Anthropic เผยแพร่ ณ เดือน October 2026 ระบุว่าค่าเฉลี่ยอยู่ที่ประมาณ $13 ต่อ developer ต่อวันที่ใช้งาน และผู้ใช้ 90% มีค่าใช้จ่ายต่ำกว่า $30 ให้เรียกใช้ /usage ในเซสชันของคุณเอง การเฝ้าดูเป็นเวลา 5 นาทีมีประโยชน์มากกว่าค่าเฉลี่ยที่เผยแพร่ใด ๆ

thinking tokens มีค่าใช้จ่ายหรือไม่ แม้ว่าฉันจะมองไม่เห็น?

มีการคิดค่าใช้จ่าย thinking tokens ในอัตรา output tokens ซึ่งเป็นอัตราที่สูงกว่า และนับรวมใน max_tokens model รุ่นปัจจุบันยังคิดค่าใช้จ่ายสำหรับโทเคนเหล่านี้ แม้ interface จะไม่แสดงสรุป reasoning ก็ตาม หาก response จบลงด้วย stop_reason: "max_tokens" ก่อนที่คำตอบที่มองเห็นได้จะแสดงครบ แสดงว่า thinking น่าจะใช้ budget ไปแล้ว ใน Claude Code ให้ลดระดับ effort ด้วย /effort สำหรับงานที่ไม่จำเป็นต้องใช้ reasoning เชิงลึก

เหตุใดเซสชัน Claude Code ที่ยาวจึงมีค่าใช้จ่ายต่อข้อความสูงขึ้น?

เนื่องจาก API ไม่มี state ทุกครั้งที่โต้ตอบจึงต้องส่ง conversation ที่ยังอยู่ใน context กลับไปทั้งหมด รวมถึงไฟล์ที่อ่าน, ผลลัพธ์จาก tool และการโต้ตอบก่อนหน้าที่ยังไม่ได้ compact ออก โดยคิดค่าใช้จ่ายเป็น input ดังนั้น turn ที่ 50 จึงมี turns ที่ 1 ถึง 49 ติดไปด้วย Prompt caching ให้บริการ prefix ที่ซ้ำกันในราคาหนึ่งในสิบของ input พื้นฐานสำหรับ model ส่วนใหญ่ (5% สำหรับ Opus 5.5 และ Sonnet 5.5, 2.5% สำหรับ Fable 5.1) แต่ prefix เองยังคงยาวขึ้น และหากเว้นช่วงไม่มีการใช้งานเกิน cache TTL แล้ว turn ถัดไปจะถูกเขียนใหม่ทั้งหมดในราคาเต็ม /compact ช่วยลดขนาดประวัติ ส่วน /clear จะเริ่มประวัติใหม่

จะตรวจสอบการใช้โทเคนและค่าใช้จ่ายของ Claude ได้อย่างไร?

ใน Claude Code, /usage จะแสดงสถิติโทเคนของเซสชัน ค่าประมาณการใช้จ่ายภายในเครื่อง และแถบแสดงขีดจำกัดของแผนสำหรับ subscription (/cost เป็น alias); /context จะแสดงสิ่งที่ใช้พื้นที่ใน window ในการตรวจสอบการเรียกเก็บเงินจาก API ที่เป็นข้อมูลอ้างอิง ให้ใช้หน้า usage ใน Claude Console หากเขียน code เอง ให้อ่าน response.usage โดยผลรวมของ input_tokens, cache_creation_input_tokens และ cache_read_input_tokens คือขนาด prompt ที่แท้จริง และให้ประเมินล่วงหน้าด้วย endpoint count_tokens ไม่ใช่ tiktoken