วิธีลดค่าใช้จ่าย Claude API (Opus 4.8 และ Fable 5)

ค่าใช้จ่าย Claude ของคุณส่วนใหญ่มาจากโทเค็นอินพุต ไม่ใช่เอาต์พุต API เป็นแบบ stateless ดังนั้นทุกครั้งที่คุณส่งประวัติการสนทนาทั้งหมดซ้ำไปใหม่: system prompt, คำจำกัดความเครื่องมือ, เอกสารที่คุณวางลงไป, และข้อความก่อนหน้าทั้งหมด ใน agent loop ที่ยาวนานหรือในเซสชัน Claude Code บริบทที่ถูกส่งซ้ำเหล่านี้จะสะสมอย่างรวดเร็ว และคุณต้องจ่ายเงินสำหรับมันในการร้องขอทุกครั้ง ส่วนเอาต์พุตนั้นเป็นเพียงส่วนเล็กน้อยของใบแจ้งหนี้

ดังนั้น กลไกที่ช่วยลดค่าใช้จ่ายของคุณได้จริงคือสิ่งที่จะช่วยลดขนาดสิ่งที่คุณส่งไป, ลดอัตราค่าบริการต่อโทเค็น, หรือหยุดคุณจากการส่งบริบทที่ไม่จำเป็นซ้ำไปใหม่ คู่มือนี้จะแนะนำวิธีการที่เป็นรูปธรรม เริ่มจากวิธีของบุคคลที่หนึ่งก่อน, จากนั้นเป็น proxy ของบุคคลที่สาม (pxpipe) ที่ใช้วิธีการที่แตกต่างออกไป, และสุดท้ายคือตำแหน่งที่ mock API มีประโยชน์ในขณะที่คุณกำลังพัฒนา

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

กลไกที่ 1: การแคช Prompt

การแคช Prompt เป็นการเปลี่ยนแปลงที่ให้ผลตอบแทนสูงสุดสำหรับ agent workloads ส่วนใหญ่ คุณทำเครื่องหมาย prefix ที่เสถียร (system prompt, คำจำกัดความเครื่องมือ, เอกสารอ้างอิงยาวๆ) ให้สามารถแคชได้ และ Claude จะจัดเก็บมันไว้ ในการร้องขอครั้งต่อไปที่เริ่มต้นด้วยไบต์เดียวกัน คุณจะอ่านจากแคชแทนที่จะจ่ายค่าอินพุตเต็มราคาเพื่อประมวลผลใหม่

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

ข้อควรระวังคือการแคชเป็นการจับคู่ prefix ในระดับไบต์ การเปลี่ยนแปลงใดๆ ภายในพื้นที่ที่แคชไว้จะทำให้มันไม่ถูกต้องและบังคับให้มีการเขียนใหม่เต็มราคา ผู้ร้ายที่พบบ่อยคือตัวแปรที่แอบเข้าไปในส่วนที่ "เสถียร": timestamp ใน system prompt, session ID, request counter, รายการเครื่องมือที่เรียงลำดับใหม่ มันดูเสถียรสำหรับคุณ แต่ถูกอ่านเป็นไบต์ใหม่สำหรับแคช

ตรวจสอบว่าการแคชทำงานจริงหรือไม่ อ่านค่า usage.cache_read_input_tokens ในการตอบกลับของคุณ สำหรับการร้องขอซ้ำๆ ที่ใช้ prefix ร่วมกัน ตัวเลขนั้นควรมีค่ามากและไม่เป็นศูนย์ หากมันติดอยู่ที่ศูนย์ แสดงว่ามีบางอย่างใน prefix ของคุณเปลี่ยนแปลงไปในการเรียกใช้แต่ละครั้ง และคุณกำลังจ่ายเต็มราคาในขณะที่คิดว่าคุณกำลังใช้แคชอยู่ สำหรับกลไกของการแคชคืออะไรและทำงานอย่างไร โปรดดู prompt caching คืออะไรและทำงานอย่างไร

กลไกที่ 2: เลือกขนาดโมเดลให้เหมาะสม

การใช้จ่ายเกินตัวที่พบบ่อยที่สุดคือการใช้โมเดลที่ใหญ่เกินกว่าที่งานต้องการ Claude มีระดับราคาที่ชัดเจน และการกำหนดเส้นทางตามงานแทนที่จะใช้โมเดลเดียวเป็นค่าเริ่มต้น มักจะเป็นการลดค่าใช้จ่ายที่สำคัญที่สุดที่คุณจะได้รับ

ข้อสังเกตบางประการจากตารางนั้น Fable 5 มีค่าใช้จ่าย 2 เท่าของ Opus 4.8 ทั้งอินพุตและเอาต์พุต ทำให้เป็นโมเดลที่แพงที่สุดที่เปิดตัวอย่างกว้างขวาง Opus 4.8 มีหน้าต่างบริบทขนาด 1M โทเค็นเต็มรูปแบบโดยไม่มีค่าพรีเมียมสำหรับบริบทที่ยาวนาน ดังนั้นคุณจึงไม่ต้องจ่ายเพิ่มสำหรับการป้อนโค้ดเบสขนาดใหญ่ Sonnet 5 ทำงานในราคาแนะนำ $2/$10 จนถึง 31 สิงหาคม 2026 จากนั้นจะย้ายไปที่ $3/$15 Haiku 4.5 เป็นราคาต่ำสุดที่ $1/$5 พร้อมหน้าต่างขนาดเล็กกว่า 200K

จับคู่โมเดลกับงาน:

• Fable 5 สำหรับการใช้เหตุผลที่ซับซ้อนและยาวนานที่สุด ซึ่งความสามารถพิเศษจะเปลี่ยนแปลงผลลัพธ์ได้อย่างแท้จริง การใช้ Fable เป็นค่าเริ่มต้นในขณะที่ Opus ก็สามารถทำงานนั้นได้ เป็นวิธีที่พบบ่อยที่สุดที่ทีมงานเพิ่มค่าใช้จ่ายเป็นสองเท่าโดยไม่มีเหตุผล
• Opus 4.8 สำหรับงาน agentic และงานโค้ดดิ้งส่วนใหญ่ เป็นค่าเริ่มต้นที่เหมาะสมสำหรับ Claude Code และ loops ที่มีการใช้เครื่องมืออย่างหนัก
• Sonnet 5 สำหรับปริมาณการใช้งานในระบบการผลิตจำนวนมากที่คุณต้องการคุณภาพที่ดีในอัตราที่ต่ำกว่า
• Haiku 4.5 สำหรับงานที่เรียบง่ายหรือต้องการความเร็วสูง: การจัดหมวดหมู่, การสกัดข้อมูล, การกำหนดเส้นทาง, การตอบกลับสั้นๆ

รายละเอียดการเรียกเก็บเงินของ Fable 5: หากตัวจำแนกความปลอดภัยปฏิเสธคำขอ พารามิเตอร์เบต้า fallbacks สามารถเปลี่ยนเส้นทางรอบนั้นไปยัง Opus 4.8 ได้ และรอบที่ถูกเปลี่ยนเส้นทางจะถูกเรียกเก็บเงินในอัตราของ Opus โดยปกติแล้วนี่คือส่วนลด ไม่ใช่ค่าใช้จ่ายที่น่าประหลาดใจ แต่ก็ควรทราบว่าการใช้งาน Fable ของคุณอาจแสดงรายการราคาแบบ Opus ได้

สำหรับรายละเอียดค่าใช้จ่ายเพิ่มเติมสำหรับโมเดลสองระดับราคาสูง โปรดดู ราคา Opus 4.8, ราคา Fable 5, และการเปรียบเทียบ Fable 5 กับ Opus 4.8 ว่าเมื่อไหร่ที่ค่าใช้จ่าย 2 เท่าคุ้มค่า หากคุณต้องการทดลองใช้โมเดลระดับสูงสุดโดยมีค่าใช้จ่ายน้อยหรือไม่มีเลยในขณะที่คุณกำลังประเมิน เรามีข้อมูลเกี่ยวกับการ ใช้ Opus 4.8 ฟรี และการ เรียกใช้ Fable 5 API โดยตรง

กลไกที่ 3: Batch API (ลด 50%)

หากงานของคุณไม่จำเป็นต้องได้รับคำตอบแบบเรียลไทม์ Batch API จะลดราคาโทเค็นทั้งหมดลงครึ่งหนึ่ง คุณส่งงานไปยัง /v1/messages/batches ซึ่งจะทำงานแบบ asynchronous และคุณจะได้รับผลลัพธ์กลับมา แบตช์ส่วนใหญ่จะเสร็จสิ้นภายในหนึ่งชั่วโมง; เพดานสูงสุดคือ 24 ชั่วโมง ส่วนลด 50% นี้ใช้ได้กับโทเค็นทั้งหมดที่ใช้ในแบตช์ ทั้งอินพุตและเอาต์พุต

การใช้งานอาจเฉพาะเจาะจงแต่มีค่า Batch เหมาะสำหรับงานที่คุณสามารถรอได้:

• การรันการประเมินผลทั่วทั้งชุดทดสอบ
• การจัดหมวดหมู่หรือการสกัดข้อมูลจำนวนมากจากข้อมูลที่ค้างอยู่
• การเติมข้อมูลย้อนหลังสำหรับสรุป, แท็ก, หรือข้อมูลเมตาที่เกี่ยวข้องกับการฝังตัวสำหรับระเบียนที่มีอยู่แล้ว
• งานออฟไลน์ขนาดใหญ่ใดๆ ที่การหน่วงเวลาไม่กี่นาทีไม่มีผลกระทบต่อคุณ

หากครึ่งหนึ่งของค่าใช้จ่าย Claude ของคุณคือการประมวลผลตอนกลางคืนที่คุณกำลังรันผ่าน synchronous endpoint การย้ายไปใช้ Batch จะเป็นการลดค่าใช้จ่ายส่วนนั้นลง 50% โดยตรงโดยไม่ส่งผลต่อคุณภาพ เป็นวิธีที่ประหยัดที่สุดในรายการนี้ เพราะข้อแลกเปลี่ยนเพียงอย่างเดียวคือความหน่วงที่คุณไม่ได้ใช้ประโยชน์อยู่แล้ว

กลไกที่ 4: ปรับ Effort, max_tokens และ count_tokens

การตั้งค่าสามอย่างนี้ควบคุมค่าใช้จ่ายในการร้องขอแต่ละครั้ง และการตั้งค่าอย่างรอบคอบจะช่วยป้องกันไม่ให้ค่าใช้จ่ายเพิ่มขึ้น

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

max_tokens. นี่คือเพดานสูงสุดของเอาต์พุต มันไม่ได้ช่วยลดค่าใช้จ่ายของการตอบกลับที่สั้นอยู่แล้ว แต่มันช่วยจำกัดกรณีที่โมเดลให้คำตอบยาวเกินไป เช่น โมเดลตัดสินใจเขียนบทความ 4,000 โทเค็น ทั้งที่คุณต้องการเพียง JSON object ตั้งค่านี้ให้เหมาะสมกับงาน เพื่อป้องกันไม่ให้การตอบกลับที่ยืดยาวเพียงครั้งเดียวเพิ่มค่าใช้จ่ายของคุณอย่างมหาศาล

count_tokens. ประมาณค่าใช้จ่ายก่อนที่คุณจะส่งคำขอ endpoint count_tokens จะบอกคุณอย่างแม่นยำว่าคำขอจะถูกเรียกเก็บเงินกี่โทเค็นอินพุต โดยใช้ tokenizer ของ Claude เอง อย่าใช้ tiktoken สำหรับสิ่งนี้ Tiktoken เป็น tokenizer ของ OpenAI ซึ่งนับโทเค็นของ Claude ต่ำกว่าความเป็นจริงประมาณ 15 ถึง 20% ดังนั้นการตั้งงบประมาณจากมันหมายความว่าบิลจริงของคุณจะสูงกว่าที่ประเมินไว้อย่างมีนัยสำคัญ หากคุณกำลังทำงานใกล้กับงบประมาณต่อคำขอ count_tokens คือวิธีที่คุณจะตรวจจับ prompt ที่มีขนาดใหญ่เกินไปก่อนที่จะเสียค่าใช้จ่าย

กลไกที่ 5: ตัดบริบทที่คุณส่งซ้ำ

เนื่องจาก API เป็นแบบ stateless, agent loop ที่ยาวนานจะส่งประวัติทั้งหมดซ้ำไปใหม่ในทุกรอบ และประวัติส่วนใหญ่นั้นเป็นภาระที่ไม่จำเป็นเมื่อถึงรอบที่ 30: เอาต์พุตของเครื่องมือที่คุณดำเนินการไปแล้ว, การสำรวจที่คุณผ่านไปแล้ว, ไฟล์ที่คุณอ่านไปแล้วครั้งเดียว คุณยังคงจ่ายค่าอินพุตเต็มราคาเพื่อส่งทั้งหมดนั้นซ้ำไปใหม่

ฟีเจอร์ฝั่งเซิร์ฟเวอร์สองอย่างที่จะช่วยตัดทอนให้คุณ:

• การแก้ไขบริบท (clear_tool_uses_20250919) จะทิ้งผลลัพธ์เครื่องมือที่ล้าสมัยออกจากบริบทที่ถูกส่งซ้ำ ดังนั้นการเรียกใช้เครื่องมือเก่าจะไม่ถูกเรียกเก็บเงินในทุกๆ รอบต่อๆ ไป
• การย่อบริบท (compact_20260112) จะสรุปประวัติเก่าๆ ให้อยู่ในรูปแบบที่สั้นลง เพื่อให้การสนทนาที่ยาวนานไม่ต้องแบกรับประวัติการถอดความดิบทั้งหมดไปข้างหน้า

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

ไปให้ไกลกว่านั้น: แปลงบริบทเป็นรูปภาพด้วย pxpipe

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

มันคืออะไร. pxpipe คือ local proxy (ลิขสิทธิ์ MIT, เขียนด้วย TypeScript) ที่อยู่ระหว่างไคลเอ็นต์ของคุณและ Anthropic API คุณชี้ ANTHROPIC_BASE_URL ไปที่มัน และมันจะตรวจสอบคำขอแต่ละรายการเมื่อออกจากระบบของคุณ

มันช่วยลดค่าใช้จ่ายได้อย่างไร. ข้อความที่หนาแน่นมีราคาแพงต่อโทเค็น pxpipe จะเขียนส่วนที่ใหญ่และเสถียรของคำขอใหม่ (system prompt, เอกสารเครื่องมือ, ประวัติเก่าๆ) ให้เป็นรูปภาพ PNG ขนาดกะทัดรัดก่อนที่คำขอจะออกจากเครื่องของคุณ เนื้อหาที่หนาแน่นมีประมาณ 3.1 ตัวอักษรต่อ image-token เทียบกับประมาณ 1 ตัวอักษรต่อ text-token ดังนั้นการแปลงเนื้อหานั้นเป็นรูปภาพสามารถลดโทเค็นอินพุตได้มาก โครงการนี้รายงานตัวอย่าง system prompt และเอกสารเครื่องมือที่มีประมาณ 48,000 ตัวอักษร เหลือเพียงประมาณ 2,700 image tokens เทียบกับประมาณ 25,000 โทเค็นในรูปแบบข้อความ ที่สำคัญคือ มันใช้เกณฑ์ความคุ้มค่า: มันจะแปลงเฉพาะเนื้อหาที่การคำนวณโทเค็นชนะเท่านั้น และข้อความที่กระจัดกระจายจะถูกส่งผ่านเป็นข้อความโดยไม่เปลี่ยนแปลง

ติดตั้งและรัน. สองคำสั่ง:

npx pxpipe-proxy

นี่จะเริ่ม proxy ที่ 127.0.0.1:47821 จากนั้นชี้ Claude Code ไปที่มัน:

ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude

การรองรับโมเดล. โดยค่าเริ่มต้น pxpipe จะแปลงคำขอสำหรับ claude-fable-5 และ GPT 5.6 เป็นรูปภาพ ส่วน Opus 4.7/4.8 และ GPT 5.5 เป็นแบบเลือกเปิดใช้งาน เนื่องจากโครงการรายงานว่าโมเดลเหล่านี้อ่านบริบทที่เป็นรูปภาพได้แย่กว่าอย่างเห็นได้ชัด คุณสามารถเปิดใช้งานได้ด้วยตัวแปรสภาพแวดล้อม PXPIPE_MODELS (หรือจากแดชบอร์ดที่ URL ของ proxy) ส่วนโมเดลอื่นๆ จะถูกส่งผ่านโดยไม่เปลี่ยนแปลง

การประหยัดที่รายงาน. ตัวเลขเหล่านี้เป็นตัวเลขที่โครงการรายงานและทดสอบเอง ไม่ใช่ตัวเลขที่เราตรวจสอบอย่างอิสระ pxpipe รายงานภาพรวมของการประหยัด 59% ในการใช้งานจริง โดยค่าใช้จ่าย $100 ลดลงเหลือประมาณ $41 จากการร้องขอ 13,709 ครั้ง และโครงการนำร่อง SWE-bench Lite ที่มีขนาดคำขอลดลง -65% ให้ถือว่าตัวเลขเหล่านี้เป็นข้อมูลอ้างอิงจากผู้ขาย และยืนยันด้วยการใช้งานจริงของคุณเอง

ข้อแลกเปลี่ยนที่ซื่อสัตย์. การแปลงเป็นรูปภาพไม่ใช่เงินฟรี

• มันมีปฏิสัมพันธ์กับการแคช prompt. การแปลงเป็นรูปภาพจะเปลี่ยนไบต์ของคำขอ และ prefix ที่แคชไว้ของคุณคือการจับคู่ไบต์ การแคชและการแปลงเป็นรูปภาพต่างก็มุ่งเป้าไปที่ค่าใช้จ่ายโทเค็นอินพุตเดียวกัน ดังนั้นพวกมันสามารถขัดแย้งกันได้: การเปลี่ยนแปลงที่ทำให้การแปลงเป็นรูปภาพมีประสิทธิภาพ อาจเป็นการเปลี่ยนแปลงที่ทำให้พื้นที่แคชของคุณเปลี่ยนไป วิธีการใดที่จะประหยัดได้มากกว่าขึ้นอยู่กับ prefix และรูปแบบการนำกลับมาใช้ซ้ำเฉพาะของคุณ วัดผลทั้งสองวิธีใน workload ของคุณเอง แทนที่จะสันนิษฐานว่าพวกมันจะทำงานร่วมกันได้
• โมเดลอ่านบริบทที่เป็นรูปภาพผ่านการมองเห็น. โครงการเองก็ชี้ให้เห็นว่าสตริงที่หนาแน่น (เช่น hex ID ที่ยาว, โทเค็นที่แม่นยำ) อาจถูกอ่านผิดพลาดได้ และการพลาดนั้นจะไม่แสดงเป็นข้อผิดพลาด ตรวจสอบคุณภาพของเอาต์พุตในงานของคุณเองก่อนที่จะเชื่อถือการประหยัดที่ได้
• เป็น proxy ของบุคคลที่สามที่จัดการการรับส่งข้อมูลของคุณ. มันทำงานในเครื่องของคุณ ซึ่งเป็นสิ่งที่ดี แต่ก็ยังอยู่ในเส้นทางการร้องขอของคุณ ประเมินมันตามนโยบายความปลอดภัยของคุณเองก่อนที่จะนำการรับส่งข้อมูลในระบบการผลิตมาใช้งานผ่านมัน

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

ลดโทเค็นสำหรับการพัฒนาและทดสอบที่คุณสูญเสียไประหว่างการสร้าง

ไม่มีสิ่งใดที่กล่าวมาข้างต้นเปลี่ยนแปลงความจริงที่ว่าคุณยังคงใช้โทเค็นจริงที่ต้องจ่ายเงินในขณะที่คุณกำลังสร้าง integration Apidog จะไม่ลดค่าใช้จ่าย Claude ในการผลิตของคุณ และก็ไม่ได้แสร้งทำเป็นว่าทำได้ สิ่งที่ช่วยคุณประหยัดเงินคือ loop การพัฒนาและการทดสอบ

ทุกครั้งที่คุณรัน integration ของคุณเทียบกับ Anthropic API จริงระหว่างการพัฒนา แต่ละครั้งจะเสียโทเค็นจริง: การรันที่ล้มเหลว, การลองใหม่, CI job ที่ทำงานทุกครั้งที่มีการ push ค่าใช้จ่ายนั้นจะสะสมเมื่อคุณกำลังปรับแต่งรูปแบบ prompt, ตรรกะการแยกวิเคราะห์ และการจัดการข้อผิดพลาด ซึ่งสิ่งเหล่านี้ไม่จำเป็นต้องใช้โมเดลจริงในการตรวจสอบความถูกต้อง

ให้ Mock การตอบกลับของ Anthropic ใน Apidog แทน กำหนดสัญญาการร้องขอและการตอบกลับสำหรับ Claude endpoint ที่คุณกำลังเรียกใช้ จากนั้นชี้การทดสอบและ CI ของคุณไปยัง mock นั้น Loop ของคุณจะทำงานกับสิ่งจำลองที่กำหนดไว้ล่วงหน้าซึ่งส่งคืนรูปร่างที่คุณคาดหวัง และคุณจะไม่เสียโทเค็นในการตรวจสอบการทำงาน คุณยังสามารถออกแบบและจัดทำเอกสารสัญญาการร้องขอ/การตอบกลับในที่เดียวกัน เพื่อให้ทีมของคุณเห็นด้วยกับอินเทอร์เฟซก่อนที่ใครจะเสียโทเค็นไปกับมัน สิ่งนี้จะช่วยลดโทเค็นสำหรับการพัฒนาและการทดสอบที่คุณสูญเสียไประหว่างการสร้าง ไม่ใช่บิลการผลิตของคุณ นั่นคือขอบเขตที่ซื่อสัตย์

รวมกลไกต่างๆ เข้าด้วยกัน

สิ่งเหล่านี้ไม่ใช่ทางเลือกใดทางเลือกหนึ่ง การลดค่าใช้จ่ายที่ใหญ่ที่สุดมาจากการรวมกัน:

1. แคช prefix ที่เสถียร. System prompt, เครื่องมือ, เอกสาร ตรวจสอบว่า cache_read_input_tokens ไม่เป็นศูนย์
2. กำหนดเส้นทางตามงาน. Opus 4.8 เป็นค่าเริ่มต้น, Fable 5 ใช้เฉพาะเมื่อมันเปลี่ยนแปลงผลลัพธ์, Sonnet 5 สำหรับปริมาณงาน, Haiku 4.5 สำหรับงานที่เรียบง่าย
3. ประมวลผลงานออฟไลน์แบบแบตช์. อะไรก็ตามที่ไม่ไวต่อความหน่วงเวลา ให้ส่งไปที่ /v1/messages/batches เพื่อรับส่วนลด 50%
4. จำกัดแต่ละคำขอ. ปรับขนาด effort ให้เหมาะสม, กำหนดขีดจำกัด max_tokens, ประมาณการด้วย count_tokens
5. ตัดส่วนที่ส่งซ้ำ. การแก้ไขบริบทและการย่อ เพื่อให้ loops ที่ยาวนานหยุดจ่ายเงินสำหรับประวัติที่ไม่จำเป็นอีกต่อไป
6. ทดสอบว่าการแปลงเป็นรูปภาพช่วยได้หรือไม่. หากบริบทของคุณมีขนาดใหญ่และหนาแน่น ให้เปรียบเทียบ pxpipe กับการแคชบน prefix ของคุณเอง
7. จำลอง (Mock) ในขณะที่กำลังสร้าง. ทำให้ loop การพัฒนาและการทดสอบอยู่นอกมิเตอร์ที่ต้องจ่ายเงิน

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

คำถามที่พบบ่อย

โทเค็นอินพุตหรือเอาต์พุตมีค่าใช้จ่ายมากกว่ากันในบิล Claude ของฉัน? เมื่อเทียบต่อโทเค็น เอาต์พุตมีค่าใช้จ่ายมากกว่าอินพุตในทุกโมเดล แต่สำหรับงาน agent และงานโค้ดดิ้ง ส่วนอินพุตมักจะเป็นส่วนที่มีค่าใช้จ่ายมากกว่า เนื่องจาก API เป็นแบบ stateless ทำให้คุณต้องส่งประวัติการสนทนาทั้งหมดซ้ำไปใหม่ในทุกๆ รอบ นั่นคือเหตุผลว่าทำไมกลไกที่ใหญ่ที่สุดจึงมุ่งเป้าไปที่โทเค็นอินพุต

การแคช prompt หรือ Batch API ประหยัดได้มากกว่ากัน? ขึ้นอยู่กับ workload ของคุณ การแคชช่วยประหยัดได้ถึง ~90% สำหรับ prefix ที่ซ้ำกันของการใช้งานแบบโต้ตอบ ดังนั้นจึงเหมาะสำหรับแชทและ agent loops ที่ใช้ system prompt ซ้ำ Batch ลดค่าใช้จ่ายลง 50% สำหรับทุกอย่าง แต่ใช้ได้เฉพาะกับงานที่คุณสามารถรันแบบ asynchronous ได้ หลายทีมใช้ทั้งสองวิธี: แคชเส้นทางการโต้ตอบ, ประมวลผลงานออฟไลน์แบบแบตช์

ฉันควรตั้งค่าทุกอย่างเป็น Fable 5 เป็นค่าเริ่มต้นหรือไม่? ไม่ Fable 5 มีค่าใช้จ่าย 2 เท่าของ Opus 4.8 และออกแบบมาสำหรับการใช้เหตุผลที่ซับซ้อนและยาวนานที่สุด สำหรับงาน agentic และงานโค้ดดิ้งส่วนใหญ่ Opus 4.8 ให้ผลลัพธ์เดียวกันในอัตราอินพุตและเอาต์พุตที่ถูกกว่าครึ่ง การใช้ Fable เป็นค่าเริ่มต้นในขณะที่ Opus ก็สามารถทำงานนั้นได้ เป็นการใช้จ่ายเกินตัวที่พบบ่อยที่สุด

pxpipe สามารถทำงานร่วมกับการแคช prompt ได้หรือไม่? ไม่ได้ทำงานร่วมกันอย่างราบรื่น การแปลงเป็นรูปภาพจะเปลี่ยนไบต์ของคำขอ และการแคชเป็นการจับคู่ prefix ในระดับไบต์ ดังนั้นทั้งสองจึงมุ่งเป้าไปที่ค่าใช้จ่ายโทเค็นอินพุตเดียวกันและสามารถขัดแย้งกันได้ ทดสอบทั้งสองวิธีบน prefix จริงของคุณและวัดว่าวิธีใดช่วยประหยัดได้มากกว่า; อย่าสันนิษฐานว่าพวกมันจะรวมกันได้

Apidog ช่วยลดค่าใช้จ่าย Claude ในการผลิตของฉันได้หรือไม่? ไม่ Apidog จำลอง Anthropic API เพื่อให้การทดสอบและ CI ของคุณเรียกใช้สิ่งจำลองแทนการใช้โทเค็นที่ต้องจ่ายเงินในขณะที่คุณกำลังสร้าง สิ่งนั้นจะช่วยลดค่าใช้จ่ายในการพัฒนาและการทดสอบของคุณ ไม่ใช่บิลการผลิตของคุณ