SSD Nodes Learn
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-07-24

เลือกใช้ Claude model ไหนดี เทียบราคา API

เปรียบเทียบราคา Claude Opus 4.8, Sonnet 5 และ Haiku 4.5 อัปเดตอัตราค่าบริการต่อ MTok เดือน July 2026 พร้อมคำนวณต้นทุนจริงเมื่อรันงาน 100,000 jobs

ควรเลือกใช้ Claude model ใด?

คำตอบสั้นๆ สำหรับคำถามที่ว่าควรใช้ Claude model ใดคือ: เริ่มต้นด้วย Claude Opus 4.8 และเปลี่ยนไปใช้ model อื่นก็ต่อเมื่อมีเหตุผลที่ชัดเจนเท่านั้น แนวทางของ Anthropic ระบุไว้เช่นเดียวกันว่า "หากไม่แน่ใจว่าควรใช้ model ใด ให้เริ่มด้วย Claude Opus 4.8 สำหรับงานเขียนโปรแกรมแบบ agentic ที่มีความซับซ้อนและงานระดับองค์กร" ให้เปลี่ยนไปใช้ Claude Sonnet 5 เมื่อคำสั่งมีความชัดเจนและต้องรันคำสั่งนั้นหลายครั้งต่อวัน และให้เปลี่ยนไปใช้ Claude Haiku 4.5 สำหรับงานเชิงกลไกที่มีปริมาณมากซึ่งทราบรูปแบบคำตอบที่ถูกต้องอยู่แล้ว ส่วน Claude Fable 5 เหมาะสำหรับงาน agent ที่ต้องทำงานต่อเนื่องเป็นเวลานาน

การเลือกใช้มีค่าใช้จ่ายประกอบด้วย นี่คืออัตราค่าบริการของ Claude API (application programming interface) ณ วันที่ 23 July 2026 ต่อหนึ่งล้าน token (ซึ่งในเอกสารระบุเป็น MTok)

  • Claude Fable 5 (claude-fable-5): $10 / MTok (in), $50 / MTok (out) บริบท 1M context
  • Claude Opus 4.8 (claude-opus-4-8): $5 (in), $25 (out) บริบท 1M context
  • Claude Opus 4.7 (claude-opus-4-7): $5 (in), $25 (out) บริบท 1M context
  • Claude Sonnet 5 (claude-sonnet-5): $2 (in), $10 (out) สำหรับราคาแนะนำจนถึง 31 August 2026 ราคามาตรฐาน $3 (in), $15 (out) จะเริ่มใช้ในวันที่ 1 September 2026 บริบท 1M context
  • Claude Haiku 4.5 (claude-haiku-4-5): $1 (in), $5 (out) บริบท 200K context

ตัวระบุ (identifiers) เหล่านั้นมีความสมบูรณ์ตามที่เขียนไว้แล้ว และไม่มีข้อมูลอื่นเพิ่มเติมต่อท้าย

ขนาดของข้อมูลไม่มีค่าธรรมเนียมเพิ่มเติมสำหรับ model ที่มีบริบท 1M-token: "คำขอขนาด 900k-token จะถูกคิดค่าบริการต่อ token ในอัตราเดียวกับคำขอขนาด 9k-token"

วัตถุประสงค์การใช้งานของแต่ละโมเดล

Anthropic อธิบายคุณสมบัติของแต่ละโมเดลไว้ในบรรทัดเดียว ซึ่งข้อมูลนี้มีความแม่นยำในการใช้งานมากกว่าการดูจาก leaderboard

  • Claude Fable 5: "Intelligence ยุคใหม่สำหรับ agent ที่ต้องทำงานต่อเนื่องเป็นเวลานาน" มีค่า latency สูงที่สุดในบรรดาทั้ง 4 โมเดล
  • Claude Opus 4.8: "สำหรับการเขียนโปรแกรมแบบ agentic ที่ซับซ้อนและงานระดับองค์กร" มีค่า latency ระดับปานกลาง
  • Claude Sonnet 5: "การผสมผสานระหว่างความเร็วและความฉลาดที่ดีที่สุด" ทำงานได้รวดเร็ว
  • Claude Haiku 4.5: "โมเดลที่เร็วที่สุดที่มีความฉลาดใกล้เคียงระดับ frontier"

Haiku 4.5 มีข้อจำกัดบางประการที่ใช้พิจารณาความเหมาะสมของงานก่อนเรื่องราคา โดยมี context window อยู่ที่ 200K tokens แทนที่จะเป็น 1M tokens ดังนั้นจึงไม่สามารถรองรับ repository ขนาดใหญ่หรือ transcript ของ agent ที่มีความยาวมากได้ นอกจากนี้ การส่ง output สูงสุดผ่าน synchronous Messages API อยู่ที่ 64K tokens ในขณะที่โมเดลอื่นอยู่ที่ 128K tokens และมี knowledge cutoff ที่เชื่อถือได้คือเดือน February 2025 ในขณะที่อีก 3 โมเดลอยู่ที่เดือน January 2026

การเลือกโมเดลส่งผลต่อค่าใช้จ่ายในการใช้งานจริงอย่างไร?

ทุกโมเดลในกลุ่มผลิตภัณฑ์นี้คิดราคา output เป็น 5 เท่าของราคา input โดย Opus 4.8 มีราคา input อยู่ที่ $5 และ output อยู่ที่ $25 ส่วน Haiku 4.5 มีราคา input อยู่ที่ $1 และ output อยู่ที่ $5 อัตราส่วนนี้คงที่ตลอดทุกระดับโมเดล ดังนั้นโมเดลที่คุณเลือกจึงมีความสำคัญมากที่สุดกับงานที่มีการสร้าง output จำนวนมาก

งานประเภท Agentic คือหนึ่งในงานลักษณะนั้น เนื่องจาก thinking tokens จะถูกคิดเงินในฐานะ output tokens และนับรวมใน max_tokens แม้ว่าข้อความนั้นจะไม่ได้ส่งมาถึงคุณก็ตาม สำหรับ Fable 5, Opus 4.8, Opus 4.7 และ Sonnet 5 ระบบจะไม่ได้รวม reasoning summary มาให้โดยค่าเริ่มต้น ทำให้ฟิลด์ thinking ส่งค่ากลับมาเป็นค่าว่าง อย่างไรก็ตาม การคิดเงินยังคงเหมือนเดิม: "ไม่ว่าจะกรณีใด การคิดเงินต่อ block จะเท่ากันและส่งกลับมาในรูปแบบเดียวกันในการสนทนาแบบ multi-turn" รายละเอียดการคำนวณค่าใช้จ่ายของ Claude token จะอธิบายรายละเอียดเรื่องนี้อย่างครบถ้วน

ความสามารถในการทำงานแบบ thinking ของแต่ละโมเดลที่นำมาเปรียบเทียบกันนั้นแตกต่างกัน ซึ่งอาจทำให้ผลการทดสอบค่าใช้จ่ายผิดพลาดหากคุณไม่ได้ตรวจสอบ สำหรับ Sonnet 5 และ Fable 5 ระบบจะเปิดใช้งาน thinking ไว้แล้วโดยไม่ต้องตั้งค่า ส่วน Opus 4.8 และ Opus 4.7 ระบบจะปิดการใช้งานไว้จนกว่าคุณจะตั้งค่า thinking: {type: "adaptive"} ใน request คุณควรตั้งค่าให้เหมือนกันทั้งสองด้านก่อนที่จะนำตัวเลขมาวิเคราะห์

ทำไมโมเดลที่ราคาถูกที่สุดอาจมีค่าใช้จ่ายสูงที่สุด

พิจารณางานเขียนโปรแกรมแบบจบในขั้นตอนเดียว (self-contained) หนึ่งงาน งานนี้มี context จำนวน 60,000 tokens และโมเดลสร้าง output จำนวน 8,000 tokens ซึ่งรวมขั้นตอนการคิด (thinking) แล้ว โดยไม่มีการใช้ caching ทำให้คำนวณค่าใช้จ่ายตามจริงได้

บน Opus 4.8: input 0.06 MTok ที่ราคา $5 คิดเป็น $0.30 และ output 0.008 MTok ที่ราคา $25 คิดเป็น $0.20 รวมค่าใช้จ่ายต่อหนึ่งความพยายามคือ $0.50 ส่วนบน Haiku 4.5 การทำงานแบบเดียวกันจะมีค่าใช้จ่าย $0.06 บวกกับ $0.04 รวมเป็น $0.10

Haiku มีราคาถูกกว่าต่อหนึ่งความพยายามถึง 5 เท่า ซึ่งดูเหมือนจะประหยัดได้มาก จนกว่าคุณจะพบผลกระทบจากการทำงานที่ผิดพลาด เมื่อคุณได้รับคำตอบที่ผิด คุณต้องเสียเวลาในการอ่าน และเมื่อคุณส่งคำตอบนั้นกลับไปเป็น context ในการลองใหม่ (retry) แต่ละความพยายามจะมีขนาดใหญ่ขึ้นกว่าครั้งก่อนหน้า และเมื่อความพยายามที่สามยังคงผิดพลาด คุณอาจต้องเปลี่ยนไปใช้โมเดลที่สูงกว่า ซึ่งจะทำให้ค่าใช้จ่ายของ Haiku $0.30 รวมกับ Opus $0.50 กลายเป็น $0.80 หรือมากกว่าการใช้ Opus เพียงครั้งเดียวถึง 60%

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

กรณีที่โมเดลขนาดเล็กมีประสิทธิภาพเหนือกว่าอย่างชัดเจน

Haiku 4.5 เป็นตัวเลือกที่เหมาะสมในกรณีต่อไปนี้:

  • งานของ subagent เชิงกล (Mechanical subagent work) การใช้ subagent เพื่อเปลี่ยนชื่อไฟล์หรือรวบรวมผลลัพธ์จากการค้นหาไม่จำเป็นต้องใช้การใช้เหตุผลขั้นสูง (frontier reasoning) นี่คือรูปแบบมาตรฐานเมื่อคุณ build an AI agent with Claude และกำหนดตัวช่วยให้แก่โมเดล
  • การคัดกรอง Log (Log triage) การตัดสินว่าข้อความหนึ่งเป็นข้อมูลขยะหรือเป็นข้อมูลที่มนุษย์ควรตรวจสอบ เป็นการตัดสินใจเฉพาะทางที่มีรูปแบบความผิดพลาดที่ชัดเจน
  • การจำแนกประเภทด้วยชุดป้ายกำกับที่กำหนดไว้ (Classification against a fixed label set) ผลลัพธ์ที่ได้จะมีลักษณะสั้น และสามารถวัดความแม่นยำได้จากกลุ่มตัวอย่าง
  • การเรียกใช้งานในระบบ Production ปริมาณมาก การเรียกใช้งาน 100,000 ครั้งต่อวัน ทำให้ความแตกต่างของราคาต่อ token มีนัยสำคัญ นี่คือลักษณะทั่วไปของ AI workflows wired into n8n
  • งานที่ความเร็วในการตอบสนองมีความสำคัญต่อผู้ใช้ Haiku 4.5 ได้รับการจัดอันดับให้เป็นโมเดลที่เร็วที่สุดในกลุ่มผลิตภัณฑ์

ข้อจำกัดหนึ่งที่เกิดขึ้นเฉพาะกับ Haiku คือ ค่า minimum cacheable prompt คือ 4,096 tokens ในขณะที่ Opus 4.8 และ Sonnet 5 ใช้เพียง 1,024 tokens หากจำนวน token ต่ำกว่าค่าขั้นต่ำนี้ "any requests to cache fewer than this number of tokens will be processed without caching, and no error is returned" ตัวอย่างเช่น instruction block ขนาด 1,500 tokens ที่สามารถทำ cache บน Sonnet 5 ได้ จะไม่สามารถทำ cache บน Haiku 4.5 ได้โดยไม่มีการแจ้งเตือน ข้อสังเกตคือค่า cache_creation_input_tokens และ cache_read_input_tokens จะมีค่าเป็นศูนย์ ซึ่งเป็นหนึ่งในสาเหตุที่ทำให้ไม่เกิดการ cache นอกเหนือจากวิธีอื่นๆ ที่ทำให้ keeping an always-on agent's costs down ล้มเหลว

ปัจจัยที่มีผลต่อคำตอบ

ปัจจัยแต่ละอย่างส่งผลต่อค่าใช้จ่ายมากกว่าชื่อรุ่นของโมเดล

Effort. output_config.effort ควบคุมปริมาณการประมวลผลของโมเดลก่อนที่จะตอบคำถาม ระดับที่มีให้เลือกคือ low, medium, high, xhigh และ max โดยมีค่าเริ่มต้นคือ high: "การตั้งค่า effort เป็น high จะให้ผลลัพธ์ที่เหมือนกับการไม่ใส่พารามิเตอร์ effort เลย" พารามิเตอร์นี้เป็นพารามิเตอร์ย่อยภายใต้ output_config ไม่ได้อยู่ที่ระดับบนสุดของคำสั่ง (request):

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=messages,
)

Effort ส่งผลต่อทุก token ในคำตอบ: "ค่านี้ส่งผลต่อจำนวน token ที่ใช้ทั้งหมด รวมถึงการเรียกใช้ tool calls ด้วย ตัวอย่างเช่น หากใช้ effort ต่ำ Claude จะเรียกใช้ tool calls น้อยลง" ผลกระทบนี้จะทวีคูณเมื่อทำงานในรูปแบบ agentic loop ค่านี้ไม่ใช่การจำกัดจำนวน token: "Effort คือสัญญาณเชิงพฤติกรรม ไม่ใช่การกำหนดงบประมาณ token ที่ตายตัว" Anthropic ไม่ได้ระบุตัวคูณราคาสำหรับแต่ละระดับ และแนะนำให้ทดสอบด้วยกรณีการใช้งานจริง ดังนั้นการเปรียบเทียบระหว่าง Sonnet 5 ที่ใช้ high กับ Opus 4.8 ที่ใช้ low จึงเป็นสิ่งที่สามารถทดสอบได้ทันที ทั้งนี้ Haiku 4.5 ไม่ได้อยู่ในรายการโมเดลที่รองรับ effort

Prompt caching. การอ่านข้อมูลจาก cache มีค่าใช้จ่ายเพียง 0.1 เท่าของอัตรา input พื้นฐาน โดยจำนวนนี้จะเป็นตัวกำหนดความคุ้มค่าในการเลือกโมเดลในแต่ละระดับ การใช้งาน cache hit บน Opus 4.8 มีค่าใช้จ่าย $0.50 / MTok ในขณะที่ input แบบ uncached บน Haiku 4.5 มีค่าใช้จ่าย $1 / MTok ดังนั้นการใช้ Opus prefix ที่มีการทำ cache ไว้เป็นอย่างดีจึงมีราคาต่อ input token ถูกกว่าการใช้ Haiku prompt แบบ cold cache การจัดการ session ให้ดี (session hygiene) ให้ความคุ้มค่ามากกว่าการเลือกโมเดล สำหรับ workload ใดก็ตามที่มีการส่ง prefix ขนาดใหญ่ที่คงที่ซ้ำๆ

Batches. หากไม่จำเป็นต้องรอคำตอบทันที Message Batches API จะรันโมเดลเดิมด้วย "ส่วนลด 50% ทั้ง token input และ output" ซึ่งจะทำให้ค่าใช้จ่ายในทุกแถวของการเปรียบเทียบด้านล่างลดลงครึ่งหนึ่ง และสามารถใช้ได้กับทุกระดับโมเดล: งาน Opus 4.8 แบบ batched จะมีราคาถูกกว่างาน Sonnet 5 แบบ synchronous ในราคามาตรฐาน ตั้งแต่วันที่ 1 September 2026 โดยเป็นการแลกเปลี่ยนระหว่างความหน่วง (latency) กับความสามารถของโมเดลภายใต้งบประมาณที่เท่ากัน

การเปรียบเทียบต้นทุนต่อหนึ่งหน่วยงาน

ปริมาณงาน: การจำแนกประเภทอีเมลสนับสนุนจำนวน 100,000 ฉบับ โดยแต่ละฉบับเรียกใช้งานหนึ่งครั้ง ใช้ input tokens 2,000 tokens และ output tokens 300 tokens ต่อการเรียกใช้งานหนึ่งครั้ง คิดเป็น input ทั้งหมด 200 MTok และ output ทั้งหมด 30 MTok

  • Haiku 4.5: input 200 x $1 = $200, output 30 x $5 = $150. รวม $350.
  • Sonnet 5, อัตราเริ่มต้น: input 200 x $2 = $400, output 30 x $10 = $300. รวม $700.
  • Sonnet 5, ตั้งแต่วันที่ 1 กันยายน 2026: input 200 x $3 = $600, output 30 x $15 = $450. รวม $1,050.
  • Opus 4.8: input 200 x $5 = $1,000, output 30 x $25 = $750. รวม $1,750.

สามารถเปลี่ยนตัวเลขสี่ค่าเพื่อคำนวณใหม่ด้วยราคาในอนาคต การปรับปรุงด้านล่างนี้ส่งผลต่อผลลัพธ์มากกว่าการเปลี่ยนชื่อโมเดล:

  • Batching ช่วยลดค่าใช้จ่ายลงครึ่งหนึ่งในทุกบรรทัด: $175, $350, $525 และ $875 การประมวลผลแบบ Batch ไม่ต้องรอคอยสำหรับการจำแนกประเภทแบบรายคืน ดังนั้นจึงไม่มีเหตุผลที่จะไม่ใช้งาน
  • การทำ Caching สำหรับ shared prefix: สมมติว่า 1,200 จาก 2,000 input tokens เป็นชุดคำสั่งเดิมทุกครั้ง สำหรับ Sonnet 5 ในอัตราเริ่มต้น ค่าใช้จ่ายสำหรับ cache hits จะอยู่ที่ $0.20 / MTok แทนที่จะเป็น $2 / MTok ดังนั้น 120 MTok จะมีค่าใช้จ่าย $24 แทนที่จะเป็น $240 เมื่อรวมกับ input ใหม่จำนวน 80 MTok ที่ราคา $2 ซึ่งเท่ากับ $160 และ output จำนวน $300 จะทำให้ Sonnet 5 มีค่าใช้จ่ายใกล้เคียง $484 แทนที่จะเป็น $700 เทคนิคเดียวกันนี้ใช้ไม่ได้กับ Haiku 4.5 เนื่องจาก 1,200 tokens ต่ำกว่าเกณฑ์ขั้นต่ำ 4,096 tokens
  • Retries: สมมติว่าคุณปฏิเสธคำตอบของ Haiku ในอีเมล 8% และนำอีเมลเหล่านั้นไปประมวลผลใหม่ด้วย Opus 4.8 เมื่อนำ 0.08 x $1,750 = $140 ไปบวกกับ $350 จะได้ผลลัพธ์คือ $490 ควรวัดอัตราการปฏิเสธ (rejection rate) ของคุณเองแทนการใช้ตัวเลขของผม
  • Tool definitions หากงานมีการใช้งาน: System prompt ที่ถูกสร้างขึ้นมีขนาด 290 tokens บน Opus 4.8 เมื่อตั้งค่า tool_choice เป็น auto, ขนาด 354 tokens บน Sonnet 5 และ 496 tokens บน Haiku 4.5 โมเดลที่ราคาถูกที่สุดจะมีค่าใช้จ่ายคงที่ (fixed overhead) สูงที่สุด

Haiku ที่มีเส้นทางการส่งต่องาน (escalation path) ที่ $490 และ Sonnet 5 ที่ทำ caching แล้วที่ $484 มีต้นทุนเท่ากัน โดยโมเดลหนึ่งสามารถทำงานให้เสร็จสิ้นได้ในการประมวลผลเพียงครั้งเดียว โมเดลไม่ใช่ปัจจัยเดียวในการพิจารณาเสมอไป

การเปลี่ยนโมเดลระหว่างเซสชันช่วยประหยัดค่าใช้จ่ายหรือไม่?

การประหยัดค่าใช้จ่ายเกิดขึ้นน้อยกว่าที่ราคาป้ายระบุไว้ เนื่องจากค่าใช้จ่ายคำนวณตามจำนวน token และสิ่งที่ต้องเสียไปคือ prefix ที่ถูก cache ไว้ทั้งหมด

Anthropic ระบุเงื่อนไขที่ทำให้ cache สิ้นสุดอายุการใช้งาน Prefix ถูกสร้างตามลำดับคือ tools ตามด้วย system และ messages โดย "การเปลี่ยนแปลงในแต่ละระดับจะทำให้ระดับนั้นและระดับถัดไปทั้งหมดใช้งานไม่ได้" นอกจากนี้ยังมีค่ากำหนดการส่งคำขออีกสองรายการที่อยู่ในรายการนี้ด้วย: "การกำหนดค่า thinking configuration และระดับ effort ที่ถูกประมวลผลจะถูกรวมเข้าไปใน prompt ดังนั้นการเปลี่ยนค่าใดๆ จะเป็นการเริ่ม prefix ใหม่" ในส่วนของ effort เอกสารระบุเพิ่มเติมว่า: "ควรเปลี่ยนค่า effort ระหว่างชุดงาน (workloads) แทนที่จะเปลี่ยนภายในบทสนทนาที่ต้องอาศัยการใช้งาน cache"

โมเดลไม่ได้อยู่ในรายการที่ระบุไว้ในเอกสาร ดังนั้นจึงไม่ควรสันนิษฐานไปเอง ให้ตรวจสอบ cache_read_input_tokens ในการส่งคำขอครั้งแรกหลังจากเปลี่ยนโมเดลเพื่อดูผลลัพธ์ สำหรับ prefix ของ Opus ขนาด 150,000 token การอ่าน cache มีค่าใช้จ่ายประมาณ $0.08 ในขณะที่การเขียนใหม่มีค่าใช้จ่ายประมาณ $0.94 ซึ่งสูงกว่าส่วนต่างต่อ token ของการสนทนาหลายรอบที่คุณต้องการประหยัด

ดังนั้น ควรเปลี่ยนค่าเหล่านี้ระหว่างการเปลี่ยนงาน ไม่ใช่ภายในงานเดียวกัน สำหรับ Claude Code หมายถึงให้เปลี่ยน /clear ก่อน เนื่องจาก cache จะถูกยกเลิกอยู่แล้ว จากนั้นจึงเปลี่ยน /model หรือ /effort

วิธีการทดสอบคำตอบด้วย Workload ของคุณเอง

ห้ามกำหนดขนาดของ Prompt โดยใช้จำนวน Token จากโมเดลอื่น การใช้งาน Token-counting endpoint ไม่มีค่าใช้จ่าย และจะคำนวณด้วย Tokenizer ของโมเดลที่คุณระบุ ดังนั้นควรระบุชื่อโมเดลที่คุณวางแผนจะใช้งานจริง Opus 4.7 และรุ่นที่ใหม่กว่า รวมถึง Fable 5 และ Sonnet 5 ใช้ Tokenizer รุ่นใหม่ซึ่ง "สร้าง Token มากกว่าเดิมประมาณ 30% สำหรับข้อความชุดเดิม" ดังนั้นการกำหนดงบประมาณจากโมเดลรุ่นเก่าจะทำให้ค่าที่ได้ต่ำกว่าความเป็นจริงเมื่อใช้กับโมเดลรุ่นใหม่ แม้ว่าอัตราค่าบริการต่อ Token จะเท่าเดิมก็ตาม

จากนั้นให้ตรวจสอบผลลัพธ์ที่ได้รับ ค่า input_tokens คือส่วนที่เหลือซึ่งไม่ได้ใช้ Cache ดังนั้นขนาด Prompt ที่แท้จริงคือค่าในฟิลด์นั้นบวกกับ cache_creation_input_tokens และ cache_read_input_tokens การสร้าง Claude API app บน VPS ตัวแรก เป็นวิธีที่ง่ายที่สุดในการวัดค่าดังกล่าว และ การเลือก Claude plan ให้เหมาะกับการใช้งาน เป็นการตัดสินใจแยกต่างหากว่าคุณจะเลือกชำระเงินตามจำนวน Token หรือไม่

FAQ

Claude model ใดเหมาะสำหรับการเขียนโปรแกรมที่สุด?

Claude Opus 4.8 เป็นจุดเริ่มต้นที่แนะนำสำหรับการเขียนโปรแกรมแบบ agentic ที่มีความซับซ้อน โดยมีราคา $5 ต่อหนึ่งล้าน input tokens และ $25 ต่อหนึ่งล้าน output tokens ณ เดือนกรกฎาคม 2026 ส่วน Claude Sonnet 5 เป็นรุ่นที่ผสมผสานความเร็วและความฉลาดได้ดีที่สุด โดยมีราคา $2 / $10 จนถึงวันที่ 31 สิงหาคม 2026 ซึ่งมีราคาถูกกว่าครึ่งหนึ่ง ให้ทดสอบงานเดียวกันบนทั้งสองรุ่น โดยกำหนดค่าการคิด (thinking configuration) ให้คงที่ แล้วเปรียบเทียบค่าใช้จ่าย token ทั้งหมดจาก response.usage

Claude Haiku 4.5 มีราคาถูกพอที่จะใช้แทน Sonnet 5 หรือไม่?

หากพิจารณาจากราคาต่อ token ถือว่าถูกกว่าอย่างชัดเจน โดยมีราคา $1 / $5 เทียบกับ $2 / $10 สำหรับ Sonnet 5 ในช่วงราคาแนะนำ หรือ $3 / $15 ตั้งแต่วันที่ 1 กันยายน 2026 อย่างไรก็ตาม ข้อจำกัดด้านเทคนิคคือปัจจัยตัดสิน เนื่องจาก Haiku 4.5 มี context window ขนาด 200K token แทนที่จะเป็น 1M, มี output สูงสุด 64K บน synchronous Messages API, มีความรู้ล่าสุดถึงเดือนกุมภาพันธ์ 2025, ไม่รองรับ output_config.effort และมีขั้นต่ำสำหรับ prompt ที่ทำ cache ได้คือ 4,096 token ซึ่งจะปิดการทำงานของ cache ในระบบ prompt ขนาดสั้นโดยอัตโนมัติ

การเปลี่ยนไปใช้ Claude model ที่ราคาถูกกว่าระหว่างเซสชันช่วยประหยัดเงินหรือไม่?

ช่วยประหยัดได้น้อยกว่าที่คาดไว้ Anthropic ระบุว่าตัวทำให้ cache สิ้นสุดอายุ (cache invalidators) ได้แก่ การเปลี่ยนแปลงใน prefix ของ tools, system หรือ messages, การเปลี่ยนแปลงการตั้งค่าการคิด (thinking configuration) และการเปลี่ยนแปลงใน output_config.effort เนื่องจากไม่มีข้อมูลระบุว่าการเปลี่ยน model ส่งผลอย่างไรต่อ cache เดิม จึงควรถือว่าไม่สามารถคาดการณ์ได้ และควรตรวจสอบ cache_read_input_tokens ในการเรียกใช้งานครั้งแรกหลังจากนั้น ประเด็นที่ควรทราบคือ หากใช้ prefix ของ Opus 4.8 ขนาด 150,000 token การอ่าน cache จะมีค่าใช้จ่ายประมาณ $0.08 ในขณะที่การเขียนใหม่จะมีค่าใช้จ่ายประมาณ $0.94 ซึ่งสูงกว่าส่วนต่างราคาต่อ token ที่ประหยัดได้จากการสนทนาหลายรอบ ควรเปลี่ยนรุ่นระหว่างการทำงานคนละอย่างกัน หลังจาก /clear ใน Claude Code เนื่องจาก cache จะถูกลบทิ้งอยู่แล้ว

output_config.effort ส่งผลต่อค่าใช้จ่ายอย่างไร?

ค่านี้เปลี่ยนจำนวน token ที่ model ใช้ในการสร้าง text, การเรียกใช้ tool และการคิด (thinking) การตั้งค่า effort ต่ำจะทำให้มีการเรียกใช้ tool น้อยลง ซึ่งจะส่งผลกระทบต่อเนื่องใน agentic loops เนื่องจากผลลัพธ์จาก tool ทุกตัวจะถูกส่งซ้ำในการสนทนารอบถัดไป ระดับของค่านี้ประกอบด้วย low, medium, high, xhigh และ max โดยมี high เป็นค่าเริ่มต้น Anthropic ไม่ได้ระบุตัวคูณราคาต่อระดับ เนื่องจากมองว่า effort คือสัญญาณเชิงพฤติกรรมไม่ใช่การกำหนดงบประมาณ token ดังนั้นควรทดสอบวัดผลด้วยงานของคุณเอง

Claude Batches API ช่วยประหยัดเงินได้เท่าใด?

ประหยัดได้ 50% ทั้ง input และ output tokens แลกกับการส่งข้อมูลแบบ asynchronous ณ เดือนกรกฎาคม 2026 ทำให้ Opus 4.8 มีราคา $2.50 (in) / $12.50 (out), Sonnet 5 มีราคา $1 / $5 ในช่วงราคาแนะนำ และ Haiku 4.5 มีราคา $0.50 / $2.50 ข้อสังเกตที่สำคัญคือความคุ้มค่าระหว่างระดับรุ่น: งาน Opus 4.8 แบบ batch มีราคาถูกกว่างาน Sonnet 5 แบบ synchronous ในอัตราปกติ ตั้งแต่วันที่ 1 กันยายน 2026 ดังนั้นการใช้ batch จึงช่วยให้ใช้งาน model ที่มีประสิทธิภาพสูงกว่าได้ในงบประมาณที่เท่ากัน