เปรียบเทียบเครื่องมือติดตามค่าใช้จ่าย Claude Code

สิ่งที่ตัวติดตามค่าใช้จ่ายของ Claude Code อ่านจริง ๆ

ตัวติดตามค่าใช้จ่ายของ Claude Code ทุกตัวจะอ่านข้อมูลจากแหล่งข้อมูลหนึ่งในสามแหล่ง และแหล่งข้อมูลนั้นจะเป็นตัวกำหนดว่าเครื่องมือจะตอบคำถามใดได้บ้าง ตัวแยกวิเคราะห์ log (log parser) จะอ่านไฟล์บันทึกเซสชันที่อยู่ในดิสก์ของคุณเอง ตัว dashboard จะอ่านบันทึกการใช้งานที่ Anthropic เก็บไว้สำหรับบัญชีหรือองค์กรของคุณ ส่วน metrics backend จะอ่านกระแสข้อมูล OpenTelemetry (OTel) ที่ Claude Code ส่งออกมาเมื่อคุณเปิดใช้งาน ทั้งสามแหล่งอาจถูกต้องพร้อมกันแต่ให้ตัวเลขไม่ตรงกันได้ เนื่องจากเป็นการนับข้อมูลคนละส่วนกัน

คู่มือนี้จะไม่กล่าวถึงเรื่อง token ซ้ำ วิธีที่ Claude Code นับการใช้งาน token ได้ครอบคลุมเรื่อง input, output, การเขียน cache และการอ่าน cache ไว้แล้ว และ dashboard จะไม่มีความหมายหากยังไม่เข้าใจส่วนนั้น คำถามในที่นี้จะแคบกว่า คือสำหรับเครื่องมือแต่ละรูปแบบ มันสามารถมองเห็นอะไรได้บ้าง และมีอะไรที่มันไม่มีทางมองเห็นได้เลย

เหตุใดตัวติดตามค่าใช้จ่ายของ Claude Code จึงปรากฏขึ้นพร้อมกัน 3 รายการในวันเดียว

มีการเผยแพร่ตัวติดตามค่าใช้จ่ายสำหรับ Claude Code แยกกัน 3 รายการในวันเดียวกัน เครื่องมือเหล่านี้ไม่ใช่ 3 เวอร์ชันของเครื่องมือเดียวกัน ซึ่งนั่นคือส่วนที่เป็นประโยชน์ ตัวแรกใช้วิธีอ่านไฟล์ session ในเครื่อง ตัวที่สองใช้วิธีดึงข้อมูลจากหน้าจอแสดงการใช้งานบัญชี และตัวที่สามเป็นระบบ tracing backend แบบโฮสต์เองที่คุณสามารถรันได้ด้วยตนเอง

เครื่องมือเหล่านี้ปรากฏขึ้นพร้อมกันเนื่องจากค่าใช้จ่ายของ agent session ไม่ใช่สิ่งที่เห็นได้ชัดเจนอีกต่อไป การแชททั่วไปจะมีค่าใช้จ่ายประมาณเท่าที่คุณเห็นบนหน้าจอ แต่ agent จะอ่านไฟล์ 20 ไฟล์ รันชุดทดสอบ และส่งบทสนทนาทั้งหมดซ้ำในทุกรอบการทำงาน ดังนั้นค่าใช้จ่ายจึงถูกขับเคลื่อนด้วยบริบทที่คุณไม่ได้พิมพ์เอง สำหรับการสมัครสมาชิกแบบรายเดือนนั้นไม่มีตัวเลขดอลลาร์ระบุไว้ มีเพียงแถบแสดงการใช้งานที่ลดลงเร็วในบางวันมากกว่าวันอื่น เครื่องมือทั้ง 3 รูปแบบจึงเข้ามาเติมเต็มช่องว่างในส่วนที่แตกต่างกันออกไป

รูปแบบที่ 1: ตัวแยกวิเคราะห์ log ในเครื่องเพื่อคำนวณค่าใช้จ่ายรายวัน

Claude Code จัดเก็บแต่ละบทสนทนาในรูปแบบ JSON Lines ไว้ที่ ~/.claude/projects/<project>/<session-id>.jsonl โดยที่ <project> คือพาธของไดเรกทอรีทำงานของคุณที่แทนที่อักขระที่ไม่ใช่ตัวอักษรหรือตัวเลขด้วย - ในไฟล์ดังกล่าว ทุกการตอบกลับของผู้ช่วยจะมีจำนวนโทเค็นสำหรับคำขอนั้นๆ ตัวแยกวิเคราะห์ log จะรวมจำนวนโทเค็นเหล่านี้และคำนวณเป็นราคา

ccusage เป็นวิธีที่คนส่วนใหญ่เลือกใช้ ไม่จำเป็นต้องติดตั้ง:

npx ccusage@latest daily
npx ccusage@latest daily --breakdown
npx ccusage@latest blocks
npx ccusage@latest session --json

daily ใช้รวมยอดตามวันที่ --breakdown ใช้แยกแต่ละแถวตามโมเดล ซึ่งช่วยให้คุณทราบว่าการใช้งาน Opus ในช่วงบ่ายเพียงครั้งเดียวอาจเป็นค่าใช้จ่ายส่วนใหญ่ของสัปดาห์ blocks ใช้จัดกลุ่มตามช่วงเวลา 5 ชั่วโมงที่การสมัครสมาชิกจะรีเซ็ต session ใช้รวมยอดต่อบทสนทนา และ --instances ใช้จัดกลุ่มตามโปรเจกต์เพื่อให้คุณเห็นว่า repository ใดมีค่าใช้จ่ายสูง เพิ่ม --since และ --until เพื่อกำหนดช่วงเวลา และรัน npx ccusage@latest daily --help สำหรับรูปแบบวันที่ที่เวอร์ชันของคุณรองรับ ณ เดือนสิงหาคม 2026 เครื่องมือนี้ยังสามารถอ่าน CLI ของเอเจนท์อื่นได้ รวมถึง Codex และ OpenCode ซึ่งสำคัญหากคุณกำลังเปรียบเทียบประสิทธิภาพ

ราคาอ้างอิงจากตารางราคาโมเดล และเครื่องมือนี้มีโหมดคำนวณค่าใช้จ่าย 3 โหมด --mode auto จะใช้ค่า costUSD ที่ Claude Code เขียนลงในไฟล์หากมีอยู่ และคำนวณจากจำนวนโทเค็นหากไม่มีค่าดังกล่าว --mode calculate จะคำนวณจากโทเค็นเสมอและเพิกเฉยต่อค่าใช้จ่ายที่บันทึกไว้ --mode display จะแสดงเฉพาะค่าใช้จ่ายที่บันทึกไว้และพิมพ์ $0.00 สำหรับแถวที่ไม่มีข้อมูล หากยอดรวมดูไม่ถูกต้อง ให้รันรายงานเดิมด้วย calculate แล้วตามด้วย display หากมีความแตกต่างกันมาก แสดงว่ารายการส่วนใหญ่ไม่มีการบันทึกค่าใช้จ่ายไว้ ดังนั้นสิ่งที่คุณกำลังอ่านอยู่จึงเป็นเพียงการประมาณการเท่านั้น

ข้อมูลเดียวกันนี้สามารถนำไปใช้ใน prompt ของคุณได้ ccusage statusline จะพิมพ์บรรทัดสรุปสำหรับแถบสถานะของ Claude Code ซึ่งเชื่อมต่อเข้ากับ ~/.claude/settings.json เช่นเดียวกับคำสั่งแถบสถานะอื่นๆ ดู การสร้างแถบสถานะ Claude Code สำหรับบล็อกการตั้งค่าและฟิลด์ที่ได้รับ

สิ่งที่ตัวแยกวิเคราะห์ log ไม่สามารถมองเห็นได้คือสิ่งที่ไม่ได้เกิดขึ้นบนเครื่องนี้ แล็ปท็อปเครื่องที่สอง เซสชันบน claude.ai หรือการทำงานของเพื่อนร่วมทีม: ทรานสคริปต์เหล่านั้นจะอยู่ในดิสก์ของเครื่องนั้นๆ ข้อมูลเก่าจะหายไปเช่นกันเนื่องจากทรานสคริปต์จะถูกลบหลังจาก 30 วันโดยค่าเริ่มต้นภายใต้การตั้งค่า cleanupPeriodDays ดังนั้นข้อมูลของไตรมาสที่แล้วจะหายไปเว้นแต่คุณจะสำรองข้อมูลไว้

มีความเสี่ยงอีกประการหนึ่งซึ่งเป็นเรื่องของโครงสร้าง เอกสารของ Anthropic ระบุว่ารูปแบบรายการเป็นข้อมูลภายในของ Claude Code และมีการเปลี่ยนแปลงระหว่างเวอร์ชัน ดังนั้นสคริปต์ที่แยกวิเคราะห์ไฟล์เหล่านี้โดยตรงอาจใช้งานไม่ได้เมื่อมีการอัปเดตเวอร์ชัน ซึ่งรวมถึงเครื่องมือทุกตัวในรูปแบบนี้ด้วย นี่คือเหตุผลที่การเขียนคำสั่ง jq แบบบรรทัดเดียวด้วยตัวเองเพื่อจัดการ JSONL เป็นความคิดที่ไม่ดีนัก: ตัวแยกวิเคราะห์ที่มีการดูแลรักษาจะคอยติดตามการเปลี่ยนแปลงรูปแบบให้คุณ ในขณะที่คำสั่งบรรทัดเดียวของคุณอาจรายงานตัวเลขที่ผิดพลาดอย่างมั่นใจในวันที่ฟิลด์ถูกเปลี่ยนชื่อ

สุดท้าย ตัวเลขดอลลาร์ต้องมีข้อควรระวังสำหรับการสมัครสมาชิก คุณไม่ได้ถูกเรียกเก็บเงินตามจำนวนโทเค็นในแผน Pro หรือ Max ดังนั้นตัวเลขนี้คือราคาที่โทเค็นของคุณจะมีมูลค่าหากคิดตามอัตรา API ปกติ มันเป็นตัววัดว่าการใช้งานของคุณหนักหน่วงเพียงใด ไม่ใช่ยอดเรียกเก็บเงินจริงของคุณ หากคำถามที่แท้จริงคือควรใช้แผนใด การเปรียบเทียบนั้นเป็นอีกหัวข้อหนึ่ง: ดู การเรียกเก็บเงิน API เทียบกับการสมัครสมาชิก Claude

รูปแบบที่ 2: หน้าจอแสดงการใช้งานในตัวช่วยให้ทราบว่าโมเดลใดเป็นผู้ใช้จ่ายงบประมาณ

Claude Code มาพร้อมกับระบบรายงานในตัวซึ่งผู้ใช้ส่วนใหญ่มักไม่ได้เปิดดู ให้รันคำสั่ง /usage ภายในเซสชัน บล็อก Session ที่ด้านบนจะแสดงจำนวนโทเค็นแยกตามโมเดลและมูลค่าเป็นดอลลาร์สำหรับเซสชันปัจจุบัน โดยคำนวณจากจำนวนโทเค็นในเครื่องตามอัตรามาตรฐาน ตัวเลขนี้ไม่รวมส่วนลดหรือราคาโปรโมชัน จึงอาจแตกต่างจากใบแจ้งหนี้จริง ยอดรวมจะถูกรีเซ็ตเมื่อ /clear เริ่มการสนทนาใหม่

สำหรับแผน Pro, Max, Team หรือ Enterprise หน้าจอเดียวกันจะแสดงปริมาณการใช้งานที่ใช้ไปเทียบกับขีดจำกัดของแผน และระบุการใช้งานล่าสุดแยกตามทักษะ, subagents, ปลั๊กอิน และ MCP servers แต่ละตัวเป็นเปอร์เซ็นต์ของยอดรวม ระบบจะแจ้งเตือนพฤติกรรมที่ส่งผลต่อการใช้งาน 10% ขึ้นไป เช่น บริบทที่ยาวเกินไปหรือการพลาด cache ให้กด d หรือ w เพื่อสลับระหว่างช่วงเวลา 24 ชั่วโมงล่าสุดและ 7 วันล่าสุด ตัวเลขเหล่านี้เป็นค่าประมาณที่คำนวณจากประวัติเซสชันในเครื่องนี้เท่านั้น ดังนั้นการใช้งานจากอุปกรณ์อื่นจะไม่ถูกนับรวม เมื่อแถบแสดงสถานะว่างเปล่าแทนที่จะเป็นเพียงระดับต่ำ หน้าจอจะแจ้งว่าหน้าต่างการใช้งานได้ปิดลงแล้วแต่ไม่ได้ระบุวิธีทำงานต่อ ซึ่ง สิ่งที่ต้องทำเมื่อถึงขีดจำกัด เป็นการตัดสินใจแยกต่างหากเกี่ยวกับโมเดล, บริบท และแผนการใช้งาน

สำหรับองค์กรที่มีนักพัฒนามากกว่าหนึ่งคน ตัวเลขจะถูกย้ายไปที่ระดับบัญชี องค์กรที่ใช้ API จะได้รับหน้า Console usage ซึ่งเป็นแดชบอร์ดของ Claude Code ที่แสดงยอดการใช้จ่ายและจำนวนบรรทัดที่ยอมรับแยกตามสมาชิก รวมถึง Claude Code Analytics API ที่ส่งคืนเมตริกรายวันต่อผู้ใช้ด้วย admin key สำหรับแผน Teams และ Enterprise จะได้รับรายงานการใช้จ่ายในคอนโซลผู้ดูแลระบบพร้อมตัวเลือกส่งออกเป็น CSV ซึ่งอัปเดตทุกวัน โดยแผน Enterprise จะเพิ่ม Analytics API เข้ามา สิ่งที่คุณเห็นจะขึ้นอยู่กับวิธีการลงชื่อเข้าใช้ของนักพัฒนาแต่ละคน ดังนั้นองค์กรแบบผสมจะต้องอ่านรายงานสองชุดและรวมยอดด้วยตนเอง

สำหรับการกำหนดงบประมาณ ตัวเลขที่เผยแพร่ในเอกสารต้นทุนของ Anthropic ณ เดือนสิงหาคม 2026 คือค่าเฉลี่ยประมาณ $13 ต่อวันต่อหนึ่งนักพัฒนา และ $150 ถึง $250 ต่อเดือนต่อหนึ่งนักพัฒนา โดย 90% ของผู้ใช้มีค่าใช้จ่ายต่ำกว่า $30 ต่อวัน ให้ถือว่าตัวเลขนี้เป็นเกณฑ์มาตรฐานจากการใช้งานในระดับองค์กร ไม่ใช่การคาดการณ์สำหรับทีมของคุณ ควรเริ่มจากกลุ่มนำร่องและวัดผลก่อนที่จะสรุปตัวเลขในภาพรวม

สิ่งที่แดชบอร์ดไม่สามารถมองเห็นได้คือรายละเอียดที่ต่ำกว่าระดับวันและระดับบุคคล แดชบอร์ดจะบอกคุณว่า Opus เป็นโมเดลที่ถูกใช้มากที่สุดในวันอังคาร แต่จะไม่บอกว่า prompt ใด, repository ใด หรือ CI job ใดที่เป็นสาเหตุ นอกจากนี้ยังมีอาการหน่วงเนื่องจากรายงานขององค์กรอัปเดตเป็นรายวัน จึงเป็นเครื่องมือสำหรับทบทวนย้อนหลังมากกว่าการหยุดยั้งเอเจนต์ที่ทำงานผิดปกติในทันที การหยุดยั้งเอเจนต์ที่ทำงานผิดปกติจำเป็นต้องใช้การจำกัดขีดความสามารถ (limits) ไม่ใช่รายงาน ซึ่งเป็นหัวข้อของ การควบคุมต้นทุนของเอเจนต์บน VPS

รูปแบบที่ 3: การใช้ OpenTelemetry stack ของคุณเองเพื่อระบุว่า prompt ใดที่ประสิทธิภาพลดลง

Claude Code จะส่งข้อมูล metrics และ events ของ OpenTelemetry ออกมาทันทีที่คุณตั้งค่า environment variable เพียงหนึ่งตัว นี่เป็นตัวเลือกเดียวที่สามารถสตรีมข้อมูลจำนวน token และค่าใช้จ่ายรายผู้ใช้เข้าสู่ระบบที่คุณควบคุมได้แบบเกือบเรียลไทม์ ข้อมูล metrics เหล่านี้ประกอบด้วย claude_code.cost.usage ในหน่วย USD, claude_code.token.usage ในหน่วย token, claude_code.session.count และ claude_code.active_time.total

metric ของ token เป็นสิ่งที่น่าสนใจเนื่องจากมี attributes ที่เฉพาะตัว ข้อมูลแต่ละจุดจะมี type ซึ่งก็คือ input, output, cacheRead หรือ cacheCreation รวมถึง model และ query_source ซึ่งก็คือ main, subagent หรือ auxiliary นอกจากนี้ยังมี agent.name, skill.name, mcp_server.name และ mcp_tool.name ข้อมูลเหล่านี้เพียงพอที่จะตอบคำถามที่ dashboard ทั่วไปเข้าไม่ถึง เช่น ค่าใช้จ่ายส่วนใดมาจาก subagents แทนที่จะเป็นคำสั่งของคุณเอง, MCP server ตัวใดทำให้ input tokens เพิ่มขึ้นเป็นสองเท่า, หรือการอ่าน cache ลดลงหลังจากที่มีการแก้ไขไฟล์ CLAUDE.md หรือไม่ พฤติกรรมของ cache มักเป็นจุดที่ซ่อนความผิดปกติเอาไว้ และ เมื่อการทำ prompt caching คุ้มค่ากับต้นทุน จะอธิบายสิ่งที่คุณกำลังตรวจสอบอยู่

มีข้อควรแก้ไขหนึ่งประการที่ควรทราบ เนื่องจากเป็นประเด็นที่พบได้ในทุกการสนทนา Langfuse เป็น tracing backend แบบ self-hosted ที่ดี และการรันบน VPS ได้อธิบายไว้ใน การทำ self-hosting Langfuse สำหรับการติดตาม agent อย่างไรก็ตาม OTLP endpoint ของ Langfuse ยอมรับเฉพาะ traces เท่านั้น ในขณะที่ Claude Code ส่งออกข้อมูล metrics และ log events ไม่ใช่ spans ดังนั้นการชี้ OTEL_EXPORTER_OTLP_ENDPOINT ไปที่ Langfuse จะทำให้โปรเจกต์ว่างเปล่าและไม่แสดงข้อผิดพลาดใดๆ ที่เป็นประโยชน์ Langfuse เป็นเครื่องมือที่เหมาะสมสำหรับ agent ที่คุณสร้างขึ้นบน API ด้วยตนเอง ซึ่งโค้ดของคุณเป็นผู้สร้างแต่ละ span พร้อมกับ prompt, model และค่าใช้จ่าย แต่สำหรับ Claude Code CLI นั้น การใช้ metrics store จะเป็นตัวเลือกที่เหมาะสมกว่า

การตั้งค่าการติดตามค่าใช้จ่ายของ Claude Code บน VPS ของคุณเอง

ใช้เพียงสองบริการก็เพียงพอแล้ว ได้แก่ collector สำหรับรับข้อมูลเมตริก และ Prometheus สำหรับจัดเก็บข้อมูล ให้เก็บทั้งสองบริการไว้ไม่ให้เข้าถึงได้จากอินเทอร์เน็ตสาธารณะ เนื่องจากพอร์ต OTLP ที่เปิดทิ้งไว้จะยอมรับการเขียนข้อมูลจากใครก็ตามที่พบพอร์ตนั้น เขียน /opt/ccmetrics/compose.yaml:

services:
  collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel/config.yaml"]
    volumes:
      - ./collector.yaml:/etc/otel/config.yaml:ro
    ports:
      - "10.8.0.1:4318:4318"
    restart: unless-stopped
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prom-data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    restart: unless-stopped

volumes:
  prom-data:

10.8.0.1 คือที่อยู่ของเซิร์ฟเวอร์ภายใน WireGuard tunnel เพื่อให้สามารถเข้าถึง collector ได้จากเครื่องของคุณเท่านั้นและจากที่อื่นไม่ได้ ที่อยู่หน้าพอร์ตทำหน้าที่สำคัญในจุดนี้ เนื่องจากพอร์ตที่เผยแพร่ผ่าน Docker จะไม่ถูกกรองโดย ufw: ดู เหตุผลที่พอร์ตที่เผยแพร่โดย Docker ข้ามการกรองของ ufw การตั้งค่า tunnel นั้นอ้างอิงจาก การทำ WireGuard VPN บน VPS ของคุณเอง

/opt/ccmetrics/collector.yaml:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

/opt/ccmetrics/prometheus.yml พอร์ต 8889 จะไม่ถูกเผยแพร่ออกไปยังโฮสต์ เนื่องจาก Prometheus จะเข้าถึง collector ผ่านเครือข่าย Compose โดยใช้ชื่อบริการ:

global:
  scrape_interval: 30s

scrape_configs:
  - job_name: claude-code
    static_configs:
      - targets: ["collector:8889"]

cd /opt/ccmetrics
docker compose up -d
docker compose logs collector

log ของ collector ควรจบด้วย Everything is ready. Begin running and processing data. หาก log หยุดลงที่ข้อผิดพลาดของ config แสดงว่า YAML ไม่สามารถ parse ได้ และ container จะรีสตาร์ทวนไปเรื่อยๆ

จากนั้นให้ชี้ Claude Code ไปที่บริการนี้ ในแต่ละเครื่องที่รัน Claude Code ให้เพิ่มค่านี้ลงใน ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "none",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://10.8.0.1:4318",
    "OTEL_METRIC_EXPORT_INTERVAL": "10000"
  }
}

เริ่มเซสชัน ส่ง prompt หนึ่งครั้ง รอจนครบช่วงเวลาการส่งออก (ในที่นี้คือ 10 วินาที โดยปกติคือ 60 วินาที) แล้วสอบถาม Prometheus ว่าได้รับข้อมูลอะไรบ้าง:

curl -s http://localhost:9090/api/v1/label/__name__/values | grep -o 'claude_code[a-z_]*'

คุณควรได้รับชื่อหลายรายการที่ขึ้นต้นด้วย claude_code_ ตัว exporter จะเปลี่ยนจุดเป็นขีดล่างและต่อท้ายด้วยหน่วย ดังนั้นสตริงที่แน่นอนจะขึ้นอยู่กับเวอร์ชันของ collector ของคุณ หากผลลัพธ์ว่างเปล่าแสดงว่าไม่มีข้อมูลส่งเข้ามา ให้ตรวจสอบว่าโปรโตคอลและพอร์ตตรงกัน เนื่องจาก http/protobuf ใช้พอร์ต 4318 และ grpc ใช้พอร์ต 4317 หากไม่ตรงกันจะเกิดความล้มเหลวโดยไม่มีการแจ้งเตือน ให้รัน claude --debug แล้ว debug log จะรายงานข้อผิดพลาดในการส่งออก OTel

สำหรับกรณีที่มีเครื่องเดียวและไม่มีเซิร์ฟเวอร์ ให้ข้ามขั้นตอนข้างต้นทั้งหมด ให้ตั้งค่า OTEL_METRICS_EXPORTER=prometheus แล้ว Claude Code จะเปิด scrape endpoint ที่ http://localhost:9464/metrics ด้วยตัวเอง เมื่อ prometheus เป็น exporter รายการเดียวที่ระบุไว้ Claude Code จะละเว้นหน่วย USD, tokens และ s ออกจากชื่อเมตริก เพื่อให้ scrape ยังคงอยู่ในรูปแบบข้อความ Prometheus ที่ถูกต้อง

การตัดสินใจเรื่องความเป็นส่วนตัวประการหนึ่งมาพร้อมกับรูปแบบนี้ โดยค่าเริ่มต้นจะมีเพียงตัวเลขเท่านั้นที่ออกจากเครื่อง โดยไม่มีข้อความ prompt และไม่มีผลลัพธ์จากเครื่องมือ OTEL_LOG_USER_PROMPTS=1 และ OTEL_LOG_TOOL_CONTENT=1 จะเปลี่ยนพฤติกรรมดังกล่าว ซึ่งจะทำให้กล่องเก็บเมตริกของคุณมีซอร์สโค้ดและข้อมูลอื่นใดก็ตามที่อยู่ในบริบท ให้เปิดใช้งานฟีเจอร์เหล่านี้อย่างตั้งใจ และอ่าน การเก็บความลับให้พ้นจากบริบทของเอเจนต์ ก่อนดำเนินการ

การติดตามค่าใช้จ่ายสำหรับการรันแบบสคริปต์และ CI

การรันแบบไม่โต้ตอบ (non-interactive runs) มักทำให้ผู้ใช้ประหลาดใจเนื่องจากไม่มีใครคอยเฝ้าดูหน้าจอ claude -p ร่วมกับ --output-format json จะรายงานค่าใช้จ่ายของการรันนั้นไว้ในผลลัพธ์ payload:

claude -p "summarise the failing tests" --output-format json | jq '.total_cost_usd'

payload ดังกล่าวจะระบุค่า total_cost_usd พร้อมรายละเอียดแยกตามโมเดล ทำให้งาน CI สามารถบันทึกค่าใช้จ่ายของตัวเองได้โดยไม่ต้องพึ่งพาแดชบอร์ด คุณสามารถผนวกค่านี้ลงในไฟล์ หรือส่งเป็นเมตริกไปยังตัวรวบรวมข้อมูลที่กล่าวถึงข้างต้น นี่เป็นวิธีติดตามค่าใช้จ่ายที่มีประสิทธิภาพและประหยัดที่สุด โดยมีค่าใช้จ่ายเพียงหนึ่งการเรียก jq ต่อการรันหนึ่งครั้ง

รูปแบบความล้มเหลวและสิ่งที่คุณจะพบ

รายงานว่างเปล่า npx ccusage@latest daily การไม่แสดงแถวข้อมูลหมายความว่าโปรแกรมไม่ได้อ่านข้อมูลจากตำแหน่งที่ Claude Code เขียนไว้ CLAUDE_CONFIG_DIR จะย้ายตำแหน่งดังกล่าว และจำเป็นต้องระบุตำแหน่งใหม่ให้แก่ตัวแยกวิเคราะห์ (parser) หากมีแถวข้อมูลอยู่แต่หยุดแสดงผลไปเมื่อประมาณหนึ่งเดือนก่อน นั่นคือ cleanupPeriodDays ทำงานตามที่ออกแบบไว้ โดยค่าเริ่มต้นจะลบรายการบันทึก (transcript) ออกหลังจากผ่านไป 30 วัน

เครื่องสองเครื่องรายงานยอดรวมไม่เท่ากัน เป็นเรื่องปกติและไม่ใช่บั๊ก ทั้ง /usage และตัวแยกวิเคราะห์ log ใดๆ จะอ่านเฉพาะประวัติเซสชันในเครื่องเท่านั้น ดังนั้นการใช้งานจากอุปกรณ์อื่นหรือจาก claude.ai จึงไม่ปรากฏในทั้งสองแหล่ง

ยอดรวมในเครื่องไม่ตรงกับใบแจ้งหนี้ ตัวเลขในเครื่องคำนวณจากจำนวนโทเค็นตามอัตรามาตรฐาน ซึ่งไม่ทราบถึงราคาโปรโมชันหรือส่วนลดตามสัญญา และหากคุณสมัครสมาชิก โทเค็นของคุณจะไม่ได้ถูกเรียกเก็บเงินแยกเป็นรายรายการ หน้าการใช้งานใน Console คือแหล่งข้อมูลที่ถูกต้องที่สุดสำหรับการเรียกเก็บเงินผ่าน API

ค่าใช้จ่ายเพิ่มขึ้นทั้งที่ทำงานเท่าเดิม ให้ตรวจสอบคอลัมน์แคชก่อนเป็นอันดับแรก เซสชันที่ยาวนานจะส่งประวัติทั้งหมดซ้ำในทุกเทิร์น โดยคิดราคาตามอัตราแคชในขณะที่แคชยังคงทำงานอยู่ และคิดราคาเต็มตามอัตรา input เมื่อแคชหมดอายุ ดังนั้นการหยุดพักนานๆ หนึ่งครั้งจะทำให้ระบบต้องประมวลผลการสนทนาทั้งหมดใหม่ ซึ่งจะแสดงเป็นตัวเลข input จำนวนมากเทียบกับตัวเลข output จำนวนน้อย และ การกำหนดราคาโทเค็น input เทียบกับ output จะอธิบายว่าเหตุใดทั้งสองค่าจึงเปลี่ยนแปลงอย่างเป็นอิสระต่อกัน

จำนวนวันที่มีการใช้ subagent ดูเป็นไปไม่ได้ subagent แต่ละตัวจะรัน context window ของตัวเอง ดังนั้นการใช้โทเค็นจะเพิ่มขึ้นตามจำนวน subagent ที่รันและระยะเวลาที่แต่ละตัวทำงาน มีเพียงข้อมูล OTel เท่านั้นที่แยกแยะข้อมูลเหล่านี้ได้ผ่านแอตทริบิวต์ query_source บน claude_code.token.usage ตัวแยกวิเคราะห์ log จะแสดงเพียงยอดรวมและทิ้งให้คุณคาดเดาเอาเอง

FAQ

ccusage แสดงยอดที่ฉันต้องจ่ายจริงสำหรับแผน Max หรือไม่?

ไม่แสดง ในกรณีที่คุณสมัครสมาชิก คุณไม่ได้ถูกเรียกเก็บเงินตามจำนวนโทเค็น ดังนั้นตัวแยกวิเคราะห์ log (log parser) จะคำนวณราคาโทเค็นของคุณตามอัตรามาตรฐานของ API เพื่อแสดงให้เห็นว่างานเดียวกันนี้จะมีค่าใช้จ่ายเท่าใดหากเรียกผ่าน API ซึ่งเป็นค่าเปรียบเทียบที่ดีว่าในแต่ละวันมีการใช้งานหนักเพียงใด และมีประโยชน์สำหรับการเปรียบเทียบระหว่างโปรเจกต์หรือโมเดล สำหรับยอดที่คุณต้องชำระจริง ให้ดูที่หน้า Console usage สำหรับการเรียกเก็บเงินผ่าน API และหน้าการเรียกเก็บเงินของแผน (plan billing page) สำหรับค่าสมาชิก

Claude Code จัดเก็บไฟล์ session ที่เครื่องมือเหล่านี้อ่านไว้ที่ไหน?

จัดเก็บไว้ใน ~/.claude/projects/<project>/<session-id>.jsonl โดยที่ <project> คือ path ของไดเรกทอรีทำงานที่ถูกแทนที่อักขระที่ไม่ใช่ตัวอักษรหรือตัวเลขด้วย - แต่ละบรรทัดจะเป็น JSON object สำหรับหนึ่งข้อความ การเรียกใช้เครื่องมือ หรือรายการ metadata CLAUDE_CONFIG_DIR จะย้ายไดเรกทอรีทั้งหมด และ cleanupPeriodDays ใน settings.json จะควบคุมการเก็บข้อมูลไว้ 30 วัน Anthropic ระบุว่ารูปแบบรายการข้อมูลนี้เป็นข้อมูลภายในและอาจมีการเปลี่ยนแปลงระหว่างเวอร์ชัน ดังนั้นควรใช้เครื่องมือที่มีการดูแลรักษาในการแยกวิเคราะห์ข้อมูล แทนการเขียนสคริปต์ขึ้นมาเอง

ฉันสามารถส่ง telemetry ของ Claude Code ไปยัง Langfuse ได้หรือไม่?

ไม่ได้โดยตรง Langfuse OTLP endpoint รองรับการรับ traces แต่ Claude Code ส่งออก metrics และ log events แทนที่จะเป็น spans ข้อมูลจึงไม่มีปลายทางที่รองรับ ให้ส่ง metrics ของ Claude Code ไปยัง OpenTelemetry collector แล้วจัดเก็บไว้ใน Prometheus แทน สำหรับเอเจนต์ที่คุณสร้างขึ้นเองบน API ให้ใช้ Langfuse เนื่องจากโค้ดของคุณเองจะเป็นตัวส่ง spans ที่ระบุ prompt, โมเดล และค่าใช้จ่ายออกมา

ทำไมตัวเลขในเครื่องของฉันถึงไม่ตรงกับหน้า Console usage?

เนื่องจากมีการคำนวณที่แตกต่างกัน /usage และตัวแยกวิเคราะห์ log จะรวมจำนวนโทเค็นจากไฟล์ session ในเครื่องที่คุณใช้งานอยู่ แล้วนำมาคำนวณราคาตามอัตรามาตรฐาน ส่วน Console จะรายงานยอดที่องค์กรของคุณถูกเรียกเก็บจริงจากทุกเครื่องและทุกคีย์ หลังจากหักส่วนลดแล้ว ความไม่ตรงกันถือเป็นเรื่องปกติ หากตัวเลขต่างกันมาก มักหมายความว่ามีอุปกรณ์เครื่องที่สอง, CI runner หรือสมาชิกในทีมคนอื่นกำลังเรียกเก็บเงินเข้าบัญชีเดียวกัน

ฉันจะติดตามค่าใช้จ่ายของการรัน claude -p ใน CI ได้อย่างไร?

ให้รันด้วย --output-format json แล้วอ่านค่า total_cost_usd จากผลลัพธ์ ตัวอย่างเช่นโดยใช้ claude -p "..." --output-format json | jq '.total_cost_usd' ข้อมูล payload ชุดเดียวกันนี้จะรวมรายละเอียดแยกตามโมเดลและ session ID ไว้ด้วย ให้บันทึกค่าดังกล่าวต่อหนึ่ง job คุณก็จะทราบค่าใช้จ่ายต่อ pipeline โดยไม่จำเป็นต้องใช้เอเจนต์, แดชบอร์ด หรือบริการเสริมใดๆ