ข้อมูลที่บันทึก
Usage event มี identifier, ชื่อ provider และ model, เวลา event และจำนวน token แยก input, output, cache-read และ cache-write เพราะ provider อาจตั้งราคาแต่ละประเภทไม่เท่ากัน
{
"provider": "example-provider",
"model": "example-model",
"input_tokens": 1000000,
"output_tokens": 500000,
"token_source": "reported"
}สูตรประมาณค่าใช้จ่าย
ทุก token class ที่ provider รายงานจะคูณกับ rate ต่อหนึ่งล้าน token หารด้วย 1,000,000 แล้วรวมเป็นหน่วย micro-USD class ที่ไม่มีการรายงานจะไม่ขัดขวางการคำนวณ แต่ถ้ามี class ที่รายงานแล้วไม่มี rate ระบบจะทำให้ cost ของ event นั้นเป็นไม่ทราบ เพื่อไม่ให้ยอดบางส่วนดูเหมือนครบ
ตัวอย่างราคา (สมมติ ไม่ใช่ราคาปัจจุบัน):
input 1,000,000 × $3.00 / 1M = $3.00
output 500,000 × $15.00 / 1M = $7.50
ยอดประมาณ = $10.50 = 10,500,000 micro-USDProvider, model และวันที่มีผล
ระบบจับคู่ทั้ง provider และ model แล้วเลือก price window ที่ effective-from และ effective-to ครอบคลุมเวลา event การเปลี่ยนราคาในภายหลังจึงไม่เขียนทับ event เก่า และผลลัพธ์ตรวจ pricing version ได้
- model ชื่อเหมือนกันแต่คนละ provider ถือเป็นราคาอีกชุดหนึ่ง
- provider หรือ model ที่ไม่มีราคา matching จะยังเป็น unpriced
- ถ้า cache class มีข้อมูลแต่ไม่มี rate cost จะเป็นไม่ทราบ
- event เก่าใช้ราคาที่มีผลในเวลาเกิด event นั้น
ทำไมไม่ทราบจึงไม่ใช่ศูนย์
เลขศูนย์อาจหมายถึงใช้ฟรี ไม่มีข้อมูล provider ไม่มีราคา หรือจำนวนเป็นศูนย์ ซึ่งไม่ใช่ความหมายเดียวกัน AtoAxis จึงแสดง token เมื่อมีข้อมูลและเว้น estimated cost เมื่อหลักฐานราคาไม่ครบ พร้อม coverage ว่าช่วงใดคิดราคาได้
ยอดต่อโปรเจกต์และข้อจำกัด
- ระบบจัด usage ตาม project เมื่อ session ให้บริบทที่ชัดเจน
- session ที่แตะหลาย project จะคงเป็น Unattributed แทนการคัดลอกไปทุก project
- ยอดประมาณไม่ใช่ใบแจ้งหนี้ ราคา negotiated, subscription และการปรับฝั่ง provider อาจอยู่นอกข้อมูล
- ไม่ต้องและไม่เก็บ prompt หรือ response text เพื่อคำนวณ
ทบทวนและตรวจสอบ
ดูหน้าติดตามค่าใช้จ่าย AI สำหรับ agent ที่รองรับ แล้วเทียบ token total, priced-token coverage และ pricing version ในช่วงเวลาเดียวกัน ผู้ทบทวน: ทีมผลิตภัณฑ์ AtoAxis อัปเดตล่าสุด: 20 กันยายน 2026