ทำไม Claude คิดราคา Output Tokens แพงกว่า Input 5 เท่า

เหตุใด output tokens จึงมีราคาสูงกว่า input tokens

ในแคตตาล็อกปัจจุบันของ Claude ทุกรุ่น output tokens มีราคาสูงกว่า input tokens ถึง 5 เท่า สาเหตุมาจากลักษณะของการประมวลผล การอ่าน prompt เป็นการประมวลผลผ่านโมเดลเพียงรอบเดียว แต่การเขียนคำตอบนั้นต้องประมวลผลทีละ token โดยแต่ละรอบต้องรอให้รอบก่อนหน้าเสร็จสิ้นก่อน

อัตราส่วนนี้เท่ากันในทุกรายการของตารางราคา ดังนั้นการเลือกใช้โมเดลรุ่นใดจึงไม่ส่งผลต่อสัดส่วนค่าใช้จ่ายในส่วนของ output แต่ขึ้นอยู่กับลักษณะงานของคุณ ตัวอย่างเช่น ขั้นตอนการทำงานของ agent ที่อ่าน 60,000 tokens และตอบกลับ 800 tokens จะมีค่าใช้จ่ายในส่วน output น้อยมาก ในขณะที่งานร่างเอกสารที่อ่าน 2,000 tokens และเขียน 12,000 tokens จะมีค่าใช้จ่ายในส่วน input น้อยมาก ทั้งสองกรณีคำนวณตามอัตราค่าบริการที่ Anthropic ประกาศไว้ โดยตรวจสอบข้อมูล ณ วันที่ 9 ตุลาคม 2026

Prefill ทำงานหนึ่งครั้ง, Decoding ทำงานหนึ่งครั้งต่อหนึ่ง token

Inference server จัดการคำขอโดยแบ่งเป็นสองระยะที่มีต้นทุนต่างกันอย่างมาก โดย Prefill จะอ่าน prompt ส่วน Decoding จะเขียนคำตอบ

Prefill จะประมวลผล prompt ทั้งหมดในคราวเดียว ทุก token ใน prompt จะเข้าสู่โครงข่ายใน forward pass เดียวกัน ทำให้งานด้าน attention และ feed-forward กลายเป็นการคูณเมทริกซ์ขนาดใหญ่จำนวนไม่กี่ครั้งที่ครอบคลุม token หลายพันรายการในครั้งเดียว การอ่าน model weights จากหน่วยความจำเพียงหนึ่งครั้งจะรองรับ prompt ทั้งหมดได้ หน่วยประมวลผลเมทริกซ์ของ accelerator จะทำงานอย่างเต็มที่ ซึ่งหมายความว่า Prefill เป็นงานที่ถูกจำกัดด้วยพลังการคำนวณ (compute-bound): ขีดจำกัดอยู่ที่ความเร็วในการคูณของชิป

Decoding ไม่สามารถทำงานในลักษณะนั้นได้ เนื่องจาก token ที่ 2 ต้องอาศัย token ที่ 1 ดังนั้น token ที่โมเดลเพิ่งสร้างขึ้นมาจะกลายเป็นส่วนหนึ่งของ input ในขั้นตอนถัดไป ทำให้แต่ละขั้นตอนไม่สามารถทำงานพร้อมกันได้ แต่ละ output token จะต้องผ่าน forward pass ของตัวเอง และแต่ละ pass จะต้องอ่าน model weights ทั้งชุดออกจากหน่วยความจำความเร็วสูง (high-bandwidth memory) เพื่อสร้างเพียงหนึ่ง token เท่านั้น สิ่งนี้ทำให้ Decoding เป็นงานที่ถูกจำกัดด้วยหน่วยความจำ (memory-bound): ขีดจำกัดอยู่ที่ความเร็วในการย้ายข้อมูล weights ไม่ใช่ความเร็วในการคูณ ปริมาณการรับส่งข้อมูล weights เท่าเดิมที่ใช้ประมวลผล prompt ทั้งชุดในช่วง Prefill จะให้ผลลัพธ์เพียงหนึ่ง token ในช่วง Decoding

ระบบให้บริการจึงแก้ปัญหาด้วยการทำ batching โดยนำหลายคำขอมาทำ Decoding พร้อมกัน เพื่อให้การอ่าน weights หนึ่งครั้งสามารถสร้าง token ให้กับทุกคำขอใน batch นั้นได้ นี่คือเหตุผลที่ Decoding มีต้นทุนที่ยอมรับได้ ขีดจำกัดยังคงเป็นเรื่องของหน่วยความจำเช่นเดิม ทุกคำขอที่กำลังประมวลผลจะเก็บ KV cache (key/value cache ซึ่งเป็นสถานะ attention ที่ถูกจัดเก็บไว้สำหรับแต่ละ token จนถึงปัจจุบัน) โดย cache นี้จะขยายขนาดขึ้นตามทุก token ที่ถูกสร้าง และเมื่อมันเต็ม accelerator ก็จะไม่สามารถเพิ่มขนาด batch ได้อีก

ข้อมูลทั้งหมดนี้ไม่ได้ระบุตัวเลขที่แน่นอน และคุณไม่ควรตีความว่า 5x เป็นอัตราส่วนของฮาร์ดแวร์ที่วัดผลได้จริง แต่มันคือราคาที่กำหนดโดย Anthropic ซึ่งอ้างอิงจากความไม่สมมาตรดังกล่าว สิ่งที่คุณสามารถตรวจสอบได้ด้วยตัวเองคือทิศทางของมัน ซึ่งใช้เวลาเพียงประมาณหนึ่งนาทีเท่านั้น

วัดช่องว่างของข้อมูลขาเข้าและขาออกด้วยตัวคุณเอง

ติดตั้งเครื่องมือบนเครื่อง Ubuntu ใดก็ได้:

sudo apt update && sudo apt install -y curl jq moreutils

จากนั้นให้ส่ง prompt สั้นๆ ที่ต้องการคำตอบยาวๆ และประทับเวลาในทุกบรรทัดที่ได้รับข้อมูล

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s จะเพิ่มจำนวนวินาทีที่ผ่านไปตั้งแต่เริ่มคำสั่งไว้ที่หน้าแต่ละบรรทัด มีสองสิ่งที่ควรสังเกตจากผลลัพธ์นี้ บรรทัด content_block_delta แรกคือเวลาที่คุณได้รับ token แรก ซึ่งกระบวนการ prefill ทั้งหมดเกิดขึ้นภายในช่วงเวลานั้น ทุกบรรทัดหลังจากนั้นคือขั้นตอนการถอดรหัส (decoding) ทีละส่วน และตัวเลขเวลาจะเพิ่มขึ้นเรื่อยๆ จนกว่า message_stop จะมาถึง

คราวนี้ลองสลับรูปแบบดูบ้าง โดยใส่เอกสารขนาดยาวลงใน prompt และจำกัดคำตอบไว้เพียงไม่กี่ token

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

ส่วนต่างเวลา (delta) แรกจะใช้เวลานานกว่ากรณี prompt สั้น เนื่องจากกระบวนการ prefill ต้องอ่านข้อความจำนวนมาก หลังจากได้รับข้อมูลส่วนแรกแล้ว การตอบกลับจะสิ้นสุดลงเกือบจะทันทีเพราะเหลือ token ให้ถอดรหัสเพียงเล็กน้อย ข้อมูลขาเข้าจำนวนหลายหมื่น token แทบไม่ทำให้เวลาขยับ แต่ข้อมูลขาออกเพียงไม่กี่ร้อย token กลับใช้เวลาประมวลผลตลอดช่วงที่เหลือ

การตอบกลับแบบไม่สตรีมทุกครั้งจะลงท้ายด้วยตัวเลขที่คุณถูกเรียกเก็บเงิน

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

ให้บันทึกข้อมูลทั้งสี่ฟิลด์ต่อการร้องขอหนึ่งครั้ง output_tokens รวม token ที่ใช้ในการคิดวิเคราะห์ (thinking tokens) ไว้ด้วย ดังนั้นโมเดลที่คิดก่อนตอบจะคิดค่าใช้จ่ายส่วนการคิดวิเคราะห์ในอัตราเดียวกับข้อมูลขาออก หากต้องการประเมินราคา prompt ก่อนส่งจริง POST /v1/messages/count_tokens รองรับ body ของการร้องขอแบบเดียวกัน โดยจะส่งคืนค่า {"input_tokens": N} โดยไม่ต้องรันโมเดลและไม่มีค่าใช้จ่าย นี่ไม่ใช่ส่วนเดียวของ API ที่ไม่มีค่าใช้จ่าย และการตรวจสอบ ส่วนประกอบของ Claude API ที่ไม่มีการเรียกเก็บเงิน เป็นสิ่งที่ควรทำก่อนจัดทำงบประมาณสำหรับโปรเจกต์แรกของคุณ

ราคาต่อล้านโทเค็นของ Claude ณ เดือนตุลาคม 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

คอลัมน์สุดท้ายคือผลหารของเอาต์พุตต่ออินพุต ซึ่งแสดงค่า 5 ในทุกแถว Haiku 4.5 คิดค่าบริการขาเข้า $1 และขาออก $5 ส่วน Opus 5 คิดค่าบริการ $5 และ $25 สำหรับ Fable 5 ซึ่งเป็นรุ่นที่มีราคาสูงที่สุด คิดค่าบริการ $10 และ $50 โดยเนื้อหาใน สิ่งที่ได้รับจากราคาของ Fable 5 เป็นสิ่งที่ควรศึกษาก่อนจะตัดสินใจมองข้ามแถวบนสุด การขยับขึ้นไปใช้รุ่นที่สูงกว่าจะคูณทั้งสองฝั่งด้วยตัวคูณเดียวกัน ซึ่งจะเปลี่ยนยอดรวมของคุณแต่ยังคงสัดส่วนอินพุตต่อเอาต์พุตไว้เท่าเดิม

Sonnet 5 คิดค่าบริการขาเข้า $2 และขาออก $10 Anthropic เปิดตัวด้วยราคานี้ในฐานะราคาแนะนำจนถึงวันที่ 31 สิงหาคม 2026 โดยมีกำหนดปรับขึ้นเป็น $3 และ $15 ในวันที่ 1 กันยายน ต่อมาในวันที่ 10 สิงหาคม 2026 ได้กำหนดให้ $2 และ $10 เป็นราคามาตรฐาน การปรับขึ้นราคาดังกล่าวไม่ได้เกิดขึ้นจริง ดังนั้นอัตราในทุกตัวอย่างด้านล่างจึงเป็นราคาที่คุณจ่ายในปัจจุบัน

Anthropic ได้เปิดตัวโมเดลใหม่ๆ นับตั้งแต่หน้านี้ถูกเผยแพร่ครั้งแรก และปัจจุบัน claude.com/pricing ได้ระบุว่าโมเดลทั้งสี่ข้างต้นเป็นโมเดลรุ่นเก่าที่ยังคงใช้งานได้ โมเดลใหม่ยังคงรักษาอัตราส่วน 5x ไว้เช่นเดิม โดย Opus 5.5 คิดค่าบริการ $4 และ $20, Sonnet 5.5 คิดค่าบริการ $2 และ $10, Fable 5.1 คิดค่าบริการ $10 และ $50 ส่วน Haiku 5.5 คิดค่าบริการ $0.10 และ $0.50 สำหรับพรอมต์ที่ไม่เกิน 100,000 โทเค็น และเพิ่มขึ้นเป็น $0.50 และ $2.50 หากเกินกว่านั้น ตัวเลขของ Opus 5 ทุกรายการด้านล่างจะต่ำกว่า Opus 5.5 อยู่ 20%

ราคาอาจมีการเปลี่ยนแปลง และหน้านี้ไม่ใช่ที่ที่คุณควรใช้ตรวจสอบราคา claude.com/pricing คือแหล่งข้อมูลที่ถูกต้องที่สุด สิ่งที่ยังคงอยู่หลังจากการเปลี่ยนแปลงราคาคือวิธีการคำนวณ

มีข้อควรระวังประการหนึ่งที่รายการราคาไม่ได้แสดงไว้ เอกสารของ Anthropic ระบุว่า Claude 4.7 และรุ่นที่ใหม่กว่าใช้ tokenizer แบบใหม่ ซึ่งสร้างโทเค็นมากกว่า tokenizer ใน Sonnet 4.6 และรุ่นก่อนหน้าประมาณ 30% สำหรับข้อความเดียวกัน การเปรียบเทียบโมเดลสองรุ่นด้วยราคาต่อล้านโทเค็นเพียงอย่างเดียวจะทำให้โมเดลรุ่นใหม่ดูคุ้มค่ากว่าความเป็นจริง เพราะเอกสารชุดเดียวกันจะมีจำนวนโทเค็นมากกว่าบนโมเดลรุ่นใหม่ ให้เปรียบเทียบที่ต้นทุนต่อชิ้นงานที่เสร็จสมบูรณ์ และคำนวณพรอมต์จริงของคุณเทียบกับโมเดลที่คุณวางแผนจะใช้งานจริง กับดักเดียวกันนี้ยังเกิดขึ้นระหว่างผู้ให้บริการแต่ละราย ซึ่งมี tokenizer ที่แตกต่างกันมากกว่านั้น ดังนั้น การคำนวณต้นทุนงานจริงทั้งบน Claude และ ChatGPT จะให้ข้อมูลได้มากกว่าการนำตารางราคาของทั้งสองมาวางเทียบกัน ปริมาณข้อความจริงที่เท่ากับหนึ่งล้านโทเค็นของ Claude จะช่วยให้เห็นภาพว่าปริมาณดังกล่าวมีขนาดเท่าใดในทางปฏิบัติ

เมื่อใดที่ค่าใช้จ่ายจาก output จะเริ่มกลายเป็นต้นทุนหลักของคุณ?

ด้วยราคาของ output ที่สูงกว่า input ถึง 5 เท่า จุดคุ้มทุนจึงเป็นสิ่งที่คำนวณในใจได้ง่าย ให้กำหนดจำนวน input token เป็น I และ output token เป็น O ต้นทุนของ input คือ I ส่วนต้นทุนของ output คือ 5 คูณด้วย O ค่าใช้จ่ายส่วนใหญ่จะตกไปอยู่ที่ output เมื่อ 5 คูณด้วย O มีค่ามากกว่า I ซึ่งคิดเป็นอัตราส่วน token คือ input 5 ส่วนต่อ output 1 ส่วน

ดังนั้น หาก prompt ของคุณมีความยาวมากกว่าคำตอบเกิน 5 เท่า input จะเป็นรายการค่าใช้จ่ายที่สูงกว่า แต่หากต่ำกว่านั้น output จะเป็นรายการหลักแทน

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

ที่อัตราส่วน 100 ต่อ 1 output จะคิดเป็น 4.8% ของค่าใช้จ่ายทั้งหมด และการลดขนาด prompt คือสิ่งเดียวที่คุ้มค่าจะทำ ที่อัตราส่วน 5 ต่อ 1 ทั้งสองฝั่งจะมีค่าใช้จ่ายเท่ากัน และที่อัตราส่วน 1 ต่อ 6 output จะคิดเป็น 96.8% ซึ่งทำให้ prompt กลายเป็นเพียงค่าความคลาดเคลื่อนเล็กน้อยเท่านั้น คนส่วนใหญ่มักประเมินอัตราส่วนของตนเองผิดพลาด ดังนั้นควรดึงข้อมูลจาก log ของคุณก่อนที่จะเริ่มปรับแต่งสิ่งใดก็ตาม

ภาระงานของเอเจนต์: ข้อมูลนำเข้าบริบทขนาดยาวและผลลัพธ์แบบสั้น

พิจารณาขั้นตอนการดึงข้อมูลของเอเจนต์หนึ่งครั้ง: มีการใช้โทเค็นนำเข้าจากเอกสารที่ดึงมาและประวัติการสนทนารวม 60,000 โทเค็น และได้คำตอบขนาด 800 โทเค็น ซึ่งคิดเป็นอัตราส่วน 75 ต่อ 1 ถือเป็นเรื่องปกติสำหรับงานที่ต้องอ่านข้อมูลก่อนเขียนผลลัพธ์

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

ผลลัพธ์คิดเป็น 6.25% ของการเรียกใช้งานนั้นในทุกโมเดล เนื่องจากอัตราส่วนนี้ถูกกำหนดไว้คงที่ในรายการราคา การเรียกใช้งานนี้มีค่าใช้จ่าย $0.32 บน Opus 5, $0.128 บน Sonnet 5 และ $0.064 บน Haiku 4.5 หากมีการเรียกใช้งานขั้นตอนดังกล่าววันละ 200 ครั้งบน Opus 5 จะมีค่าใช้จ่ายอยู่ที่ $64 ต่อวัน

จุดที่สามารถปรับเปลี่ยนได้นั้นชัดเจนเมื่อเห็นการแบ่งสัดส่วน การลดคำตอบจาก 800 โทเค็นเหลือ 400 โทเค็นช่วยประหยัดค่าใช้จ่ายได้เพียงประมาณ 3% ของการเรียกใช้งาน แต่การตัดบริบทที่ไม่จำเป็นออกไป 20,000 โทเค็นจากพรอมต์จะช่วยประหยัดค่าใช้จ่ายได้ถึงประมาณหนึ่งในสาม การพยายามลดความยาวของผลลัพธ์ในเอเจนต์ที่เน้นการอ่านข้อมูลเป็นหลักจึงแทบไม่เกิดประโยชน์ จุดที่โทเค็นของเอเจนต์เขียนโค้ดถูกใช้ไปจริง จะแจกแจงรายละเอียดว่าสิ่งใดที่เติมเต็มพรอมต์เหล่านั้นตั้งแต่แรก

ภาระงานสร้างเนื้อหา: คำสั่งสั้น, ร่างยาว

คราวนี้ลองสลับรูปแบบดูบ้าง หากมีโจทย์ความยาว 2,000 token และร่างเนื้อหาความยาว 12,000 token ซึ่งคิดเป็นอัตราส่วน 1 ต่อ 6

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

ผลลัพธ์คือ 96.8% ของค่าใช้จ่ายนี้ Opus 5 มีต้นทุนอยู่ที่ $0.31 ต่อหนึ่งร่าง ในขณะที่ Haiku 4.5 มีต้นทุนอยู่ที่ $0.062 ส่วนต่างที่สูงถึง 5 เท่านี้มาจากฝั่ง output เกือบทั้งหมด ซึ่งเป็นจุดที่โมเดลราคาประหยัดช่วยคุณประหยัดค่าใช้จ่ายได้มากที่สุด

คอลัมน์สุดท้ายคือการทำงานเดียวกันผ่าน Batch API ซึ่งช่วยลดค่าใช้จ่ายทั้ง input และ output ลง 50% ทำให้ Opus 5 มีต้นทุนลดลงเหลือ $0.155 ต่อหนึ่งร่าง การประมวลผลแบบ Batch จะส่งผลลัพธ์กลับมาภายใน 24 ชั่วโมงแทนที่จะได้ทันที จึงเหมาะสำหรับงานประเภทการสร้างรายงานข้ามคืนหรือการจัดหมวดหมู่ข้อมูลจำนวนมาก แต่ไม่เหมาะกับงานที่ต้องรอผลลัพธ์ในขณะนั้น

การเลือกใช้โมเดล (Model routing) ในขั้นตอนนี้ให้ผลลัพธ์ที่คุ้มค่ากว่าขั้นตอนการทำงานแบบ agent อย่างเห็นได้ชัด หากส่วนที่ต้องเขียนเนื้อหายาวๆ ของงานนั้นเป็นงานเชิงกลไก เช่น การจัดรูปแบบข้อความใหม่ หรือการขยายความจากโครงร่างที่คุณอนุมัติไว้แล้ว โมเดลราคาประหยัดจะสร้าง token เหล่านั้นด้วยต้นทุนเพียง 1 ใน 5 ของราคาปกติ เนื้อหาใน การเลือกระหว่าง Opus, Sonnet และ Haiku จะอธิบายถึงจุดที่คุณภาพของแต่ละโมเดลแตกต่างกันอย่างชัดเจน

การแคชส่วนลดเฉพาะข้อมูลขาเข้าเท่านั้น

Prompt caching จะจัดเก็บส่วนนำของ prompt ไว้บนเซิร์ฟเวอร์ และคิดค่าบริการในการอ่านข้อมูลซ้ำในอัตราส่วนที่ถูกกว่าการประมวลผลข้อมูลขาเข้าปกติ ณ วันที่ 9 ตุลาคม 2026 ตัวคูณราคาคือ 1.25 เท่าของอัตราข้อมูลขาเข้าพื้นฐานสำหรับการเขียนแคชที่มีอายุ 5 นาที, 2 เท่าสำหรับการเขียนแคชที่มีอายุ 1 ชั่วโมง และ 0.1 เท่าสำหรับการอ่านข้อมูลที่พบในแคช (cache hit) สำหรับโมเดลที่ระบุราคาในหน้านี้ ส่วนโมเดลรุ่นใหม่ล่าสุดจะมีอัตราการอ่านข้อมูลที่พบในแคชถูกลงไปอีก คือ 0.05 เท่าสำหรับ Opus 5.5 และ Sonnet 5.5 และ 0.025 เท่าสำหรับ Fable 5.1

ข้อมูลขาออกไม่รวมอยู่ในส่วนลดนี้ ไม่มีการแคชข้อมูลขาออก ทุก token ที่โมเดลเขียนจะถูกคิดเงินในอัตราเต็มของข้อมูลขาออกเสมอ ไม่ว่าข้อมูลขาเข้าส่วนใดจะถูกดึงมาจากแคชก็ตาม

ลองพิจารณาการทำงานของ agent ขั้นตอนเดียวกันบน Opus 5 โดยมี token ขาเข้า 55,000 จากทั้งหมด 60,000 token ที่ดึงมาจากแคชที่พร้อมใช้งาน

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

ค่าใช้จ่ายในการเรียกใช้งานจะลดลงจาก $0.32 เหลือ $0.0725 ในขณะที่ค่าใช้จ่ายส่วนข้อมูลขาออกจะไม่มีการเปลี่ยนแปลง คืออยู่ที่ $0.02 ก่อนการแคช และ $0.02 หลังการแคช การแคชช่วยลดค่าใช้จ่ายรวมและเปลี่ยนโครงสร้างต้นทุน เดิมทีข้อมูลขาออกคิดเป็น 6.25% ของค่าใช้จ่ายในการเรียกใช้งานนั้น แต่ตอนนี้สัดส่วนดังกล่าวเพิ่มขึ้นเป็นมากกว่าหนึ่งในสี่ ซึ่งส่งผลต่อการตัดสินใจว่าควรปรับจูนส่วนใดต่อไปเพื่อให้เกิดความคุ้มค่าที่สุด

การเรียกใช้งานครั้งแรกจะเป็นการจ่ายค่าธรรมเนียมการเขียนแคช การเขียนแคชอายุ 5 นาทีมีค่าใช้จ่าย 1.25 เท่าของราคาข้อมูลขาเข้าพื้นฐาน ดังนั้นจึงคุ้มทุนหลังจากมีการเรียกใช้งานซ้ำเพียงครั้งเดียว ส่วนการเขียนแคชอายุ 1 ชั่วโมงมีค่าใช้จ่าย 2 เท่า จึงต้องมีการเรียกใช้งานซ้ำสองครั้ง ตัวคูณสำหรับการเขียนและการอ่าน รวมถึงจุดที่การแคชเริ่มไม่คุ้มทุน ได้อธิบายการคำนวณทางคณิตศาสตร์ในส่วนนี้ไว้อย่างละเอียด

สี่กลไกที่คุณควบคุมได้

1. ตั้งค่า max_tokens ไว้ที่ความยาวผลลัพธ์ระดับ p95 ไม่ใช่ที่ค่าสูงสุดของโมเดล
2. ส่งขั้นตอนที่ต้องใช้คำอธิบายยาวๆ ไปยังโมเดลที่มีราคาถูกกว่า
3. ทำ Batching สำหรับงานที่ไม่มีใครรอผลลัพธ์แบบทันที
4. ลบคำสั่งที่ทำให้คำตอบยืดยาวเกินความจำเป็น

max_tokens เป็นเพดานจำกัดสูงสุด การตั้งค่าไว้สูงไม่ได้ทำให้เสียค่าใช้จ่ายเพิ่มในตัวมันเอง เพราะคุณถูกเรียกเก็บเงินตามจำนวนโทเค็นที่สร้างจริง ไม่ใช่ตามเพดานที่ตั้งไว้ การตั้งค่าเพดานที่สูงเกินไปมีข้อเสียคือหากโมเดลตอบผิดพลาด ระบบจะปล่อยให้ตอบไปเรื่อยๆ จนกว่าจะถึงขีดจำกัด ให้ดึงข้อมูลการกระจายตัวของ output_tokens ออกจาก log ของคุณ แล้วตั้งค่าเพดานให้สูงกว่าเปอร์เซ็นไทล์ที่ 95 เล็กน้อย จากนั้นจัดการกับ stop_reason: "max_tokens" ในโค้ดด้วยการสั่งให้ตอบต่อหรือลองใหม่ การตัดข้อความที่ตรวจพบได้นั้นมีต้นทุนต่ำกว่าการปล่อยให้โมเดลร่ายยาว 4,000 โทเค็นที่คุณต้องจ่ายเงินซื้อแล้วสุดท้ายก็ไม่ได้ใช้งาน กระบวนการคิด (Thinking) จะถูกนับรวมใน output_tokens และหักออกจาก max_tokens ด้วย ดังนั้นควรใช้ข้อมูลชุดเดียวกันในการกำหนดขนาดเพดาน และในโมเดลที่มีระบบคิดแบบปรับตัวได้ (adaptive thinking) ให้ลดระดับความพยายามลงหากกระบวนการคิดกินพื้นที่ของคำตอบมากเกินไป

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

Batching เป็นกลไกเดียวที่ช่วยลดราคาค่า Output ได้ โดยลดราคาลง 50% ทั้งฝั่ง Input และ Output โดยแลกกับการได้รับผลลัพธ์ภายใน 24 ชั่วโมง ซึ่งงานใดก็ตามที่สามารถตั้งเวลาทำงานได้จะเข้าข่ายนี้ทั้งหมด

กลไกสุดท้ายคือสิ่งที่คนมักมองข้าม วลีอย่าง "be thorough" หรือ "explain your reasoning" จะเพิ่มความยาวของ Output ในทุกๆ ครั้งที่คุณเรียกใช้งาน ให้เปลี่ยนมาใช้การกำหนดรูปแบบที่ต้องการแทน เช่น "Answer in at most three sentences" หรือ "Return only the JSON object, with no preamble" การใช้ system prompt ที่เพิ่มโทเค็นเข้าไป 300 โทเค็นในทุกคำตอบ จะมีต้นทุนสูงกว่าการใส่ 300 โทเค็นนั้นไว้ใน prompt ปกติถึง 5 เท่า การควบคุมค่าใช้จ่ายของเอเจนต์ที่ทำงานต่อเนื่อง ครอบคลุมด้านการตรวจสอบ และ การเปรียบเทียบว่า API หรือการสมัครสมาชิกแบบเหมาจ่ายคุ้มค่ากว่าสำหรับรูปแบบการใช้งานของคุณ เป็นสิ่งที่ควรตัดสินใจก่อนที่คุณจะเสียเวลาเป็นสัปดาห์ไปกับการปรับจูนค่าใช้จ่ายรายโทเค็นที่การสมัครสมาชิกแบบเหมาจ่ายอาจครอบคลุมอยู่แล้ว สำหรับนักพัฒนาคนเดียว เรื่องนี้มักขึ้นอยู่กับว่า Claude Pro ราคา $20 ต่อเดือนและขีดจำกัดการใช้งานที่มาพร้อมกัน เพียงพอสำหรับงานที่คุณต้องจ่ายเงินตามจริงหรือไม่ หากคุณพบว่าขีดจำกัดเหล่านั้นหมดลงระหว่างการใช้งาน การวิเคราะห์ว่าคุณกำลังติดขัดที่ส่วนไหน คือขั้นตอนแรก เพราะวิธีแก้ไขคือการใช้โมเดลที่เล็กลง, ลดบริบท (context) ลง, การใช้เครดิตเสริม หรือย้ายงานนั้นไปทำบน API แบบคิดเงินตามจริง หากพบว่า API แบบคิดเงินตามจริงเป็นทางเลือกที่ถูกกว่าสำหรับงานนั้น การลดระดับแผนการใช้งานหรือยกเลิก จะไม่ทำให้เดือนที่คุณจ่ายเงินไปแล้วเสียเปล่า ดังนั้นการเปลี่ยนแผนจึงไม่มีต้นทุนแฝง หากแผนที่คุณกำลังเปรียบเทียบกับ Pro คือของ ChatGPT แทนที่จะเป็น API แบบคิดเงินตามจริง ตารางเปรียบเทียบราคาการสมัครสมาชิกทั้งสองแบบ จะแสดงให้เห็นว่าแบบไหนคุ้มค่ากว่าสำหรับงานเขียนโค้ด หากคำถามนี้มาจากทีมงานไม่ใช่แค่นักพัฒนาคนเดียว โปรดทราบว่า Claude Enterprise คิดค่าธรรมเนียมต่อที่นั่งควบคู่ไปกับโทเค็นที่คิดราคาตามอัตรา API นี้ ดังนั้นกลไกทุกอย่างในหน้านี้จึงยังคงใช้ได้กับส่วนของค่าใช้จ่ายที่คิดตามจริงในบิลนั้น

FAQ

ทำไม output token ถึงมีราคาสูงกว่า input token?

การสร้าง token เหล่านี้ต้องใช้เวลาประมวลผลบน accelerator ต่อหนึ่ง token มากกว่ามาก โดย prompt จะถูกประมวลผลในรอบ forward pass เดียวสำหรับข้อมูลทั้งหมด ดังนั้นการอ่าน model weights เพียงครั้งเดียวจึงครอบคลุม token จำนวนหลายพันตัว และฮาร์ดแวร์จะถูกจำกัดด้วยความเร็วในการคูณเมทริกซ์ (multiply throughput) ในขณะที่การตอบกลับจะถูกสร้างขึ้นทีละหนึ่ง token ซึ่งแต่ละ token จำเป็นต้องใช้ forward pass ของตัวเองที่ต้องอ่าน model weights ทั้งหมดใหม่อีกครั้ง ฮาร์ดแวร์จึงถูกจำกัดด้วย memory bandwidth แทน Anthropic กำหนดราคา output ไว้ที่ 5 เท่าของ input สำหรับรายการบริการทั้งหมดในปัจจุบัน ตั้งแต่ Haiku 5.5 ไปจนถึง Fable 5.1

การทำ prompt caching ช่วยให้ output token มีราคาถูกลงหรือไม่?

ไม่ช่วย การทำ prompt caching มีผลกับ input เท่านั้น ณ วันที่ 9 ตุลาคม 2026 การอ่านจาก cache มีค่าใช้จ่าย 0.1 เท่าของอัตรา input พื้นฐานในโมเดลส่วนใหญ่ (0.05 เท่าบน Opus 5.5 และ Sonnet 5.5, 0.025 เท่าบน Fable 5.1) และการเขียนลง cache มีค่าใช้จ่าย 1.25 เท่าสำหรับระยะเวลา 5 นาที หรือ 2 เท่าสำหรับระยะเวลา 1 ชั่วโมง ส่วน output จะถูกเรียกเก็บเงินในอัตราเต็มทุกครั้งที่มีการเรียกใช้งาน ไม่ว่า cache จะทำงานอย่างไรก็ตาม นี่คือเหตุผลที่การทำ caching เปลี่ยนแปลงทั้งรูปแบบและขนาดของใบแจ้งหนี้ของคุณ เมื่อฝั่ง input มีค่าใช้จ่ายลดลง output จึงกลายเป็นส่วนที่มีมูลค่าสูงที่สุดที่ควรพิจารณาควบคุม

การตั้งค่า max_tokens สูงๆ จะทำให้เสียเงินเพิ่มหรือไม่หากคำตอบที่ได้สั้น?

ไม่เสีย คุณจะถูกเรียกเก็บเงินตามจำนวน token ที่โมเดลสร้างขึ้นจริงเท่านั้น ดังนั้น max_tokens จึงเป็นเพียงเพดานจำกัด ไม่ใช่การจองทรัพยากร อย่างไรก็ตามค่านี้ยังคงมีความสำคัญเพราะเป็นขีดจำกัดเดียวที่ป้องกันไม่ให้การตอบกลับทำงานยาวเกินไปโดยไม่หยุด ควรตั้งค่าให้สูงกว่าค่าเปอร์เซ็นไทล์ที่ 95 ของ output_tokens ที่คุณสังเกตพบเล็กน้อย จากนั้นให้จัดการกับ stop_reason: "max_tokens" ในโค้ดแทนการปล่อยให้คำตอบถูกตัดทอนโดยไม่แจ้งเตือน

ฉันจะหาอัตราส่วนระหว่าง input token กับ output token ของตัวเองได้อย่างไร?

ให้บันทึกค่า input_tokens, output_tokens, cache_read_input_tokens และ cache_creation_input_tokens จากออบเจกต์ usage ของทุกการตอบกลับ จากนั้นนำผลรวมมาหารกันในรอบหนึ่งสัปดาห์ หากอัตราส่วนสูงกว่า 5 ต่อ 1 แสดงว่าค่าใช้จ่ายส่วนใหญ่อยู่ที่ prompt ให้ทำการ cache ส่วนที่คงที่และตัดส่วนที่ไม่จำเป็นออก หากอัตราส่วนต่ำกว่านั้น แสดงว่าค่าใช้จ่ายส่วนใหญ่อยู่ที่การตอบกลับ ให้จำกัดความยาวของคำตอบและย้ายขั้นตอนที่สร้าง token จำนวนมากไปใช้โมเดลที่ราคาถูกกว่าหรือใช้ Batch API แทน