วิธีควบคุมค่าใช้จ่าย AI Agent บน VPS ไม่ให้งบบานปลาย

วิธีควบคุมค่าใช้จ่ายสำหรับ AI agent ที่ทำงานตลอดเวลา

การควบคุมค่าใช้จ่ายของ AI agent บน VPS (virtual private server) คือการกำหนดเพดานค่าใช้จ่ายไว้ก่อนที่ agent จะเริ่มทำงาน เนื่องจากไม่มีใครคอยเฝ้าดูมิเตอร์ในขณะที่ระบบทำงานอยู่ ให้จำกัดจำนวน token ในทุกการตอบกลับด้วย max_tokens, กำหนดขอบเขตจำนวนรอบการทำงาน (loop iterations) ในโค้ดของคุณเอง, ทำแคช (cache) ส่วนของ prompt ที่ไม่มีการเปลี่ยนแปลง และบันทึกจำนวนการใช้งานของทุกการตอบกลับเพื่อตรวจสอบว่างานใดเป็นตัวสร้างค่าใช้จ่าย ค่าเช่าเซิร์ฟเวอร์เป็นราคาคงที่รายเดือน แต่ API ของโมเดลจะคิดค่าใช้จ่ายตามจำนวน token ซึ่งการปล่อยให้ loop ทำงานโดยไม่มีผู้ดูแลนั้นสามารถใช้ token ไปได้อย่างรวดเร็วโดยที่คุณไม่รู้ตัว

เนื้อหานี้ตั้งอยู่บนสมมติฐานว่าคุณมี agent อยู่แล้วและมีการเรียกใช้งาน Messages API จากเซิร์ฟเวอร์ที่คุณเป็นเจ้าของ สำหรับ การสร้าง AI agent ด้วย Claude บน VPS จะครอบคลุมถึงกลไกการทำงานในส่วนนั้น

เหตุใด unattended agent จึงมีโครงสร้างต้นทุนที่แตกต่างออกไป

เซสชันแบบโต้ตอบ (interactive session) มีมนุษย์คอยควบคุม เมื่อโมเดลทำงานผิดพลาดหรือต้องอ่าน log ขนาด 40,000 บรรทัด ผู้ที่เฝ้าดูจะสั่งหยุดการทำงานได้ทันที แต่ unattended agent ไม่มีกลไกหยุดยั้งเช่นนั้น มันจะทำงานไปจนกว่าลูปจะสิ้นสุด จากนั้นตัวตั้งเวลาจะเริ่มการทำงานใหม่อีกครั้ง

ความถี่คือตัวคูณที่หลายคนมองข้าม งานที่ตั้งตารางเวลาไว้ทุก 5 นาทีจะทำงาน 288 ครั้งต่อวัน และประมาณ 8,640 ครั้งต่อเดือน ต้นทุนต่อการรันหนึ่งครั้งคือตัวเลขที่คุณต้องนำไปคูณ เอเจนต์แบบ "always-on" หลายตัวไม่จำเป็นต้องเปิดทิ้งไว้ตลอดเวลา สิ่งที่ต้องการคือการตอบสนองภายในระยะเวลาที่กำหนด ซึ่งสามารถจัดการได้ด้วยการตั้งตารางเวลา

นอกจากนี้ เอเจนต์ยังมีต้นทุนในส่วนที่หน้าต่างแชททั่วไปไม่มี

• คำจำกัดความของเครื่องมือ (Tool definitions) จะถูกส่งไปพร้อมกับทุกคำขอ ระบบ prompt สำหรับการใช้งานเครื่องมือมีต้นทุน 290 tokens บน Claude Opus 4.8 โดยใช้ tool_choice ของ auto หรือ none และ 410 tokens หากใช้ any หรือ tool ส่วน bash tool จะเพิ่มเข้าไปอีก 325 tokens ทุก MCP server ที่คุณเชื่อมต่อ จะเพิ่ม schema เข้าไปในน้ำหนักของคำขอนั้น โดย MCP ย่อมาจาก model context protocol
• ผลลัพธ์จากเครื่องมือถือเป็น input tokens คำสั่งที่แสดงผลลัพธ์ 8,000 บรรทัด จะนำข้อมูล 8,000 บรรทัดนั้นเข้าสู่คำขอถัดไป และรวมอยู่ในทุกคำขอหลังจากนั้นในรอบการทำงานเดียวกัน
• หน้าเว็บที่ดึงข้อมูลมาถือเป็น input tokens หน้าเว็บขนาดเฉลี่ย 10 kB คิดเป็นประมาณ 2,500 tokens และไฟล์วิจัย PDF ขนาด 500 kB คิดเป็นประมาณ 125,000 tokens โดย max_content_tokens จะตัดทอนเฉพาะเนื้อหาที่เป็นข้อความเท่านั้น เนื่องจาก "มีผลกับเนื้อหาที่เป็นข้อความ ไม่ใช่เนื้อหาที่เป็นไบนารี เช่น ไฟล์ PDF" ให้จำกัดขอบเขตของ PDF ด้วย max_uses และ allowed_domains แทน
• การค้นหาบนเว็บมีราคาต่อการค้นหา อยู่ที่ $10 ต่อ 1,000 ครั้ง ไม่ว่าจะมีผลลัพธ์กลับมาจำนวนเท่าใดก็ตาม การค้นหาที่เกิดข้อผิดพลาดจะไม่ถูกเรียกเก็บเงิน

ต้นทุนเหล่านี้อาจไม่สูงหากเกิดขึ้นเพียงครั้งเดียว แต่จะกลายเป็นค่าใช้จ่ายมหาศาลเมื่อเกิดขึ้นถึง 8,640 ครั้ง

เพดานแบบแข็งและเพดานแบบอ่อนแก้ปัญหาที่แตกต่างกัน

max_tokens มีการบังคับใช้จริง เป็นการจำกัดปริมาณผลลัพธ์รวมของหนึ่งคำขอแบบเด็ดขาด โดยนับรวมทั้งส่วนการคิดและข้อความตอบกลับ Claude จะไม่สร้างเนื้อหาเกินขีดจำกัดนี้ และตัวโมเดลเองไม่สามารถมองเห็นตัวเลขดังกล่าวได้ หากถึงขีดจำกัดจะได้รับ stop_reason: "max_tokens" และคำตอบที่ถูกตัดทอน ข้อควรระวังสำหรับเอเจนต์คือ: ทุกคำขอในลูปการใช้เครื่องมือจะมี max_tokens ของตัวเอง ดังนั้นจึงเป็นการจำกัดเฉพาะการตอบกลับหนึ่งครั้ง ไม่ใช่จำกัดทั้งงาน การเรียกใช้เครื่องมือ 10 ครั้งที่ 4,000 โทเค็น จะเท่ากับเพดาน 40,000 โทเค็นต่อรอบการทำงาน

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

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"งบประมาณของงานเป็นเพียงคำแนะนำแบบอ่อน ไม่ใช่เพดานแบบแข็ง" Claude อาจใช้เกินงบกลางคันได้ และขีดจำกัดที่บังคับใช้จริงสำหรับผลลัพธ์ยังคงเป็น max_tokens "การนับถอยหลังจะมองเห็นได้เฉพาะโมเดลเท่านั้น" และการตอบกลับจะไม่มีฟิลด์ระบุงบประมาณที่เหลืออยู่ task_budget.total ขั้นต่ำที่ยอมรับได้คือ 20,000 โทเค็น หากน้อยกว่านั้นจะส่งคืนข้อผิดพลาด 400 งบประมาณที่น้อยเกินไปสำหรับงานจะทำให้เกิดพฤติกรรมคล้ายการปฏิเสธงาน ดังนั้นโมเดลจะลดขอบเขตของงานลงหรือหยุดทำงานก่อนกำหนด

รายละเอียดหนึ่งประการที่ทำให้เสียค่าใช้จ่ายเพิ่มแทนที่จะประหยัด หากไคลเอนต์ของคุณลดค่า task_budget.remaining ในทุกคำขอติดตามผล ค่าที่เปลี่ยนไปจะทำให้ prefix ที่แคชไว้ทั้งหมดซึ่งมีค่านั้นอยู่ใช้งานไม่ได้ ให้ตั้งค่าเพียงครั้งเดียวในคำขอแรกเท่านั้น

งบประมาณของงานอยู่ในสถานะเบต้าบน Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5.5 และ Claude Haiku 5.5 ส่วน Claude Sonnet 5 และ Claude Haiku 4.5 ถูกระบุว่าเป็น Not supported และงบประมาณของงานไม่มีผลกับ Claude Code ดังนั้นการ เซสชัน Claude Code ที่แยกออกมาใน tmux จึงขึ้นอยู่กับการจัดการเซสชันให้สะอาดแทน

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

การเลือกโมเดลในแต่ละงาน และสิ่งที่ส่งผลต่อความพยายามจริง

การเลือกโมเดลเป็นการตัดสินใจในแต่ละงาน ณ เดือนตุลาคม 2026 ราคาต่อล้านโทเค็น (ขาเข้าและขาออก) มีดังนี้: Claude Fable 5.1 และ Fable 5 ราคา $10 และ $50, Claude Opus 5.5 ราคา $4 และ $20, Claude Opus 5, Opus 4.8 และ Opus 4.7 ราคา $5 และ $25, Claude Sonnet 5.5 และ Sonnet 5 ราคา $2 และ $10, Claude Haiku 5.5 ราคา $0.10 และ $0.50 สำหรับพรอมต์ไม่เกิน 100,000 โทเค็น ($0.50 และ $2.50 สำหรับส่วนที่เกิน โดยนับรวมโทเค็นที่อยู่ในแคช) และ Claude Haiku 4.5 ราคา $1 และ $5 Anthropic เคยขาย Sonnet 5 ในราคานี้เป็นราคาช่วงแนะนำ ก่อนจะปรับเป็นราคามาตรฐานและยกเลิกแผนการขึ้นราคาเป็น $3 และ $15 งานที่ทำหน้าที่เพียงจำแนกบรรทัดใน log ไม่จำเป็นต้องใช้ Opus

อย่าพึ่งพาการใช้งานฟรีเพื่อรองรับตารางงานที่หนาแน่น นอกเหนือจาก เครดิตจำนวนเล็กน้อยที่ Claude API มอบให้เมื่อสมัครใช้งาน สิทธิ์การใช้งานที่ได้รับเป็นประจำมีเพียงเครดิต API รายเดือนที่รวมอยู่ในแผน Claude Max และ Team เท่านั้น ได้แก่ $100 สำหรับ Max 5x, $200 สำหรับ Max 20x และสูงสุด $500 สำหรับแผน Team แบบรวมกลุ่ม ซึ่งจะรีเฟรชในทุกรอบบิล คุณสามารถกดรับสิทธิ์ได้หลังจากใช้งานแผนที่เข้าเงื่อนไขครบ 7 วัน โดยไม่จำเป็นต้องเพิ่มวิธีการชำระเงิน เครดิตนี้ครอบคลุม Claude API, Managed Agents, Agent SDK และ playground แต่ไม่รวม Claude Code และเครดิตจะหมดอายุเมื่อสิ้นสุดรอบบิลโดยไม่ทบยอด การใช้เครดิตนี้จะถูกนับรวมในเพดานการใช้จ่าย (spend cap) และเมื่อเครดิตหมดลง คำขอจะหยุดทำงานทันทีเว้นแต่ว่าองค์กรจะมีเครดิตที่ซื้อไว้รองรับ

ความพยายาม (effort) เป็นปัจจัยที่สอง output_config.effort รองรับ low, medium, high, xhigh และ max แม้ว่าไม่ใช่ทุกโมเดลจะรองรับทุกระดับ ค่าเริ่มต้นคือ high ในโมเดลส่วนใหญ่ และ medium ใน Claude Opus 5.5 และ Claude Haiku 5.5 การตั้งค่าระดับความพยายามของโมเดลให้ตรงกับค่าเริ่มต้นนั้นให้ผลลัพธ์เหมือนกับการไม่ระบุค่า การลดระดับความพยายามไม่ได้ส่งผลแค่ความยาวในการใช้เหตุผลเท่านั้น เอกสารระบุว่ามันทำให้ Claude เรียกใช้เครื่องมือ (tool calls) น้อยลงและรวมการดำเนินการหลายอย่างเข้าเป็นการเรียกใช้เพียงครั้งเดียว ในกรณีของ agent นี่คือการประหยัดที่สำคัญกว่า เพราะการหลีกเลี่ยงการเรียกใช้เครื่องมือหมายถึงการลดจำนวนคำขอทั้งหมดที่ไม่จำเป็นต้องเกิดขึ้น

ข้อควรระวังคือระดับความพยายามจะขัดแย้งกับแคช การเปลี่ยนค่าระดับบนสุดระหว่างคำขอจะทำให้ prompt caching เป็นโมฆะ ในตัวอย่างที่ระบุไว้ในเอกสารของ Claude Opus 5.5 คำขอที่ 2 รายงานค่า cache_read_input_tokens: 3546 คำขอที่ 3 เปลี่ยนระดับความพยายามจาก medium ซึ่งเป็นค่าเริ่มต้นของโมเดลนั้น ไปเป็น low และรายงานค่า cache_creation_input_tokens จาก 3546 และ cache_read_input_tokens จาก 0 ดังนั้นควรปรับระดับความพยายามในระดับบนสุดตามภาระงานเท่านั้น ห้ามปรับภายในบทสนทนาที่แคชไว้ มีสองวิธีในการเปลี่ยนความลึกโดยไม่ทำลายแคช ในโมเดล Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 และ Haiku 5.5 การเปลี่ยนระดับความพยายามต่อข้อความ (สถานะเบต้า, header mid-conversation-output-config-2026-07-01) จะเป็นการกำหนดระดับใหม่โดยไม่กระทบต่อส่วน prefix ที่แคชไว้ ในโมเดลใดก็ตาม คุณสามารถควบคุมผ่านพรอมต์แทนได้ เช่น การเพิ่มบรรทัด "ตอบโดยตรงโดยไม่ต้องใช้เวลาคิด" ในข้อความล่าสุดของผู้ใช้ จะช่วยให้จุดแบ่ง (breakpoints) ก่อนหน้ายังคงอยู่ อย่างไรก็ตาม ใน Claude Haiku 5.5 วลีดังกล่าวอาจไม่ช่วยลดการใช้เหตุผลได้อย่างน่าเชื่อถือ

โทเค็นที่ใช้ในการคิด (thinking tokens) จะถูกเรียกเก็บเงินในอัตราขาออกและนับรวมใน max_tokens ซึ่งเป็นเหตุผลว่าทำไมคำตอบที่ถูกตัดทอนมักหมายถึงการที่กระบวนการคิดใช้โควตาจนหมด อ่าน usage.output_tokens_details.thinking_tokens สำหรับตัวเลขดังกล่าว สิ่งที่ประกอบเป็นบิลค่าโทเค็นของ Claude จะอธิบายรายละเอียดการวัดผลทั้งหมด

แคชส่วน prefix ที่คงที่ และหยุดทำลายมันโดยไม่ตั้งใจ

การเขียนแคชมีค่าใช้จ่าย 1.25 เท่าของราคา input พื้นฐานสำหรับแคชระยะเวลา 5 นาที และ 2 เท่าสำหรับแคชระยะเวลา 1 ชั่วโมง ในโมเดลส่วนใหญ่ การอ่านแคชมีค่าใช้จ่าย 0.1 เท่า ดังนั้น "การใช้แคชจะคุ้มทุนหลังจากการอ่าน 1 ครั้งสำหรับระยะเวลา 5 นาที (เขียน 1.25 เท่า) หรือหลังจากการอ่าน 2 ครั้งสำหรับระยะเวลา 1 ชั่วโมง (เขียน 2 เท่า)" การอ่านมีราคาถูกลงไปอีกในโมเดลรุ่นใหม่ล่าสุด คือ 0.05 เท่าใน Claude Opus 5.5 และ Claude Sonnet 5.5 และ 0.025 เท่าใน Claude Fable 5.1

ประโยคเดียวที่อธิบายว่าทำไมสิ่งนี้จึงเหมาะกับ agent ที่ทำงานตลอดเวลา: "แคชจะถูกรีเฟรชโดยไม่มีค่าใช้จ่ายเพิ่มเติมทุกครั้งที่มีการใช้งานเนื้อหาที่แคชไว้" งานที่ทำงานทุกๆ 2 นาทีโดยใช้แคชระยะเวลา 5 นาที จะช่วยรักษา prefix ให้พร้อมใช้งานได้ตลอดทั้งวันด้วยการเขียนเพียงครั้งเดียว

3 วิธีที่ทำให้เสียแคชไปโดยไม่รู้ตัว

prefix ที่มีการเปลี่ยนแปลง "prefix ของแคชจะถูกสร้างขึ้นตามลำดับดังนี้: tools, system จากนั้น messages" การเปลี่ยนแปลงของไบต์ใดๆ ที่อยู่ก่อนหน้าในลำดับดังกล่าวจะทำให้ข้อมูลทั้งหมดที่ตามมาเป็นโมฆะ และการแก้ไขนิยามของเครื่องมือ (tool definitions) จะทำให้แคชทั้งหมดเป็นโมฆะ ความผิดพลาดที่พบบ่อยคือการใส่ timestamp หรือ run id ไว้ใน system prompt: ส่งผลให้ทุกคำขอมี prefix ที่แตกต่างกัน ทำให้ต้องเขียนข้อมูลใหม่ที่ราคา 1.25 เท่า และไม่สามารถอ่านข้อมูลเดิมกลับมาได้ สัญญาณเตือนคือค่า usage.cache_read_input_tokens ที่เป็น 0 ในขณะที่คำขอมีลักษณะเหมือนกันทุกประการ ให้ย้ายข้อความที่มีการเปลี่ยนแปลงบ่อยไปไว้ในข้อความของผู้ใช้ (user message) ล่าสุดแทน

prefix ที่สั้นเกินไป โมเดลแต่ละรุ่นมีความยาวขั้นต่ำที่สามารถแคชได้ หากสั้นกว่านั้น คำขอจะถูกประมวลผลโดยไม่มีการแคชและ "ไม่มีการส่งข้อความแสดงข้อผิดพลาดกลับมา" ตัวเลขดังกล่าวรวมถึง 512 tokens ใน Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5 และ Haiku 5.5, 1,024 ใน Claude Opus 4.8 และ Claude Sonnet 5 และ 4,096 ใน Claude Haiku 4.5 ดังนั้นการย้ายงานจาก Sonnet 5 ไปยัง Haiku 4.5 อาจทำให้การแคชถูกปิดไปโดยไม่แจ้งเตือน

บทสนทนาที่ยาวเกินกว่าหน้าต่างการตรวจสอบ (lookback) "หน้าต่างการตรวจสอบคือ 20 บล็อก" ระบบจะตรวจสอบตำแหน่งสูงสุด 20 ตำแหน่งต่อจุดพัก (breakpoint) แล้วหยุดทำงาน ในตัวอย่างที่ระบุไว้ การสนทนาที่มี 35 บล็อกโดยมีจุดพักที่บล็อก 35 จะตรวจสอบบล็อกที่ 35 ลงไปถึง 16 และรายการของรอบก่อนหน้าที่บล็อก 15 จะอยู่นอกหน้าต่างการตรวจสอบ ส่งผลให้ไม่มีการพบข้อมูล (no hit) agent ที่เพิ่มบล็อกการใช้เครื่องมือและผลลัพธ์ของเครื่องมือหลายบล็อกต่อรอบ จะข้ามขีดจำกัด 20 บล็อกภายใน 2 หรือ 3 รอบ คุณสามารถใช้จุดพักได้ 4 จุดต่อคำขอ ดังนั้นควรแบ่ง 1 จุดไว้สำหรับข้อความล่าสุด

ส่งงานที่รอได้ไปยัง Batches API

"การใช้งานทั้งหมดจะถูกคิดค่าบริการที่ 50% ของราคา API มาตรฐาน" ทั้งในส่วนของ input และ output การประมวลผลแบบ batch เป็นแบบอะซิงโครนัส (asynchronous) โดย "batch ส่วนใหญ่จะเสร็จสิ้นภายในเวลาไม่เกิน 1 ชั่วโมง" และจะได้รับผลลัพธ์เมื่อคำขอทั้งหมดประมวลผลเสร็จสิ้น หรือเมื่อครบกำหนด 24 ชั่วโมง แล้วแต่ว่าเหตุการณ์ใดจะเกิดขึ้นก่อน ซึ่งนี่เป็นเพียงค่าเฉลี่ยทั่วไป ไม่ใช่การรับประกัน

ให้ทำการ poll processing_status จนกว่าสถานะจะเปลี่ยนเป็น ended คำขอที่ส่งผลลัพธ์กลับมาเป็น errored, canceled หรือ expired จะไม่มีการคิดค่าบริการ ข้อควรระวังหากคุณมีการตั้งค่าเพดานการใช้จ่าย (spend cap) คือ "batch อาจมีการใช้จ่ายเกินขีดจำกัดที่กำหนดไว้ใน Workspace ของคุณไปบ้างเล็กน้อย"

ส่วนลดต่างๆ สามารถนำมาใช้ร่วมกันได้ และเนื่องจาก batch อาจใช้เวลาประมวลผลนานกว่า 5 นาที เอกสารจึงแนะนำให้ใช้ cache ระยะเวลา 1 ชั่วโมงสำหรับ batch ที่มีการแชร์ context ร่วมกัน ดังนั้นควรแบ่งแยกงานให้ชัดเจน: งานใดที่ผู้ใช้หรือ webhook ต้องรอผลลัพธ์ให้คงไว้ในเส้นทางปกติ (live path) ส่วนงานประเภทสรุปผลรายคืนหรือการจำแนกประเภท log ของเมื่อวาน ให้ส่งเข้าสู่ระบบ batch เพื่อรับส่วนลดครึ่งราคา

บันทึกฟิลด์การใช้งานของทุกการตอบกลับลงในที่จัดเก็บของคุณเอง

คุณไม่สามารถระบุค่าใช้จ่ายที่คุณไม่ได้บันทึกไว้ได้ ทุกการตอบกลับจะแจ้งให้คุณทราบว่ามีค่าใช้จ่ายเท่าใด

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

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

มีฟิลด์หนึ่งที่เข้าใจผิดได้ง่าย input_tokens จะนับเฉพาะโทเค็นที่อยู่หลังจุดพักแคช (cache breakpoint) ล่าสุดเท่านั้น ดังนั้นขนาดของพรอมต์ที่แท้จริงคือ total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens เอเจนต์ที่รายงานค่า input_tokens: 400 สำหรับพรอมต์ขนาดใหญ่ไม่ได้หมายความว่ามีราคาถูก เพราะส่วนที่เหลือมาจากแคช

ให้นับจำนวนก่อนส่ง การนับโทเค็นไม่มีค่าใช้จ่ายและมีขีดจำกัดอัตรา (rate limit) แยกต่างหากจากการสร้างข้อความ ดังนั้นให้ใช้ count_tokens เพื่อปฏิเสธไฟล์แนบที่มีขนาดใหญ่เกินไป แทนที่จะต้องจ่ายเงินเพื่อพบว่ามันใหญ่เกินไป ผลลัพธ์ที่ได้เป็นเพียงการประมาณการ ดังนั้นควรวัดผลใหม่ตามแต่ละโมเดลและห้ามนำจำนวนที่นับจากตัวตัดคำ (tokenizer) ของผู้ให้บริการรายอื่นมาใช้ซ้ำ โมเดล Claude 4.7 ขึ้นไป รวมถึง Claude Fable 5 และ Claude Sonnet 5 ใช้ตัวตัดคำรุ่นใหม่ที่ "สร้างโทเค็นเพิ่มขึ้นประมาณ 30% สำหรับข้อความเดียวกัน" ส่วน Claude Sonnet 4.6 และรุ่นก่อนหน้า รวมถึง Claude Haiku 4.5 จะใช้ตัวตัดคำรุ่นเดิม

สำหรับข้อมูลที่เชื่อถือได้ Admin API จะรายงานการใช้งานที่ https://api.anthropic.com/v1/organizations/usage_report/messages และค่าใช้จ่ายที่ https://api.anthropic.com/v1/organizations/cost_report ทั้งสองส่วนต้องใช้คีย์ผู้ดูแลระบบ (sk-ant-admin01-...) ในรูปแบบ x-api-key: $ANTHROPIC_ADMIN_KEY ร่วมกับ anthropic-version: 2023-06-01 รายงานการใช้งานรองรับ bucket_width=1d, group_by[]=model และ api_key_ids[]= ส่วนรายงานค่าใช้จ่ายจะเป็นแบบรายวันเท่านั้นและจัดกลุ่มตาม workspace_id หรือ description ข้อจำกัดประการหนึ่งคือ "Admin API ไม่สามารถใช้งานได้สำหรับบัญชีส่วนบุคคล"

พารามิเตอร์ api_key_ids[] เป็นเทคนิคการระบุแหล่งที่มาที่มีต้นทุนต่ำ: ให้แต่ละงานใช้คีย์ API ของตนเอง กรองรายงานการใช้งานด้วย api_key_ids[] และแยกรายงานตามคีย์ด้วย group_by[]=api_key_id ตัวกรองสามารถระบุได้หลายรายการ แต่การจัดกลุ่มมิติข้อมูลทำได้เพียงรายการเดียว ให้เก็บคีย์ไว้ใน environment แทนที่จะเก็บไว้ในโค้ด ตามแนวทางที่ แอป Claude API ตัวแรกบน VPS ใช้งาน

จำกัดขอบเขตของลูป เพราะไม่มีกลไกอื่นมาจัดการให้

การกำหนดจำนวนรอบการวนซ้ำที่ชัดเจนเป็นสิ่งที่จำเป็นในกรณีนี้ เนื่องจากเป็นลูปที่คุณเขียนขึ้นเอง คุณจึงต้องเป็นผู้กำหนดตัวนับด้วยตนเอง:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

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

ให้ติดตั้งเบรกชั้นที่สองไว้ภายนอกกระบวนการทำงาน โดยรันงานผ่าน systemd timer แทนที่จะใช้กระบวนการที่ทำงานค้างไว้ตลอดเวลา และกำหนดระยะเวลาสูงสุด (wall-clock cap) ให้กับ service unit ของคุณ งานที่รันผ่าน timer มักจะเป็น Type=oneshot และเนื่องจาก RuntimeMaxSec= "ไม่มีผลกับบริการประเภท Type=oneshot" ดังนั้นให้กำหนด TimeoutStartSec=600 แทน ให้ใช้ RuntimeMaxSec=600 เฉพาะกับ unit ประเภท Type=simple เท่านั้น ไม่ว่าจะใช้วิธีใด การทำงานที่ค้างอยู่จะถูกสั่งยุติหลังจากผ่านไป 10 นาที แทนที่จะปล่อยให้ทำงานวนไปเรื่อยๆ จนกว่าคุณจะสังเกตเห็น การรันโปรแกรมในรูปแบบ systemd service และ timer อธิบายรายละเอียดเกี่ยวกับ unit files ไว้แล้ว คุณสามารถตรวจสอบผลการทำงานได้ด้วย journalctl -u triage-agent.service --since "1 hour ago"

นอกจากนี้ ควรจำกัดจำนวนครั้งในการลองใหม่ (retry) ด้วย เพราะตัวจัดการที่พยายามลองใหม่ตลอดไปจะทำให้เกิดค่าใช้จ่ายในทุกความพยายาม ข้อผิดพลาดระดับ 429 หรือ 500 ควรลองใหม่ได้เพียงไม่กี่ครั้งโดยใช้กลยุทธ์ backoff แต่สำหรับข้อผิดพลาดระดับ 400 ไม่ควรลองใหม่เลย เนื่องจากคำขอเดิมจะล้มเหลวด้วยสาเหตุเดิมเสมอ

การควบคุมค่าใช้จ่ายของ AI agent เริ่มต้นจากการอ่านตัวเลขของคุณเอง

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

ข้อมูลนี้ตั้งอยู่บนสมมติฐานว่าคุณใช้ API key เนื่องจาก agent คือโปรแกรมของคุณเองที่เรียกใช้งาน Messages API สำหรับการทำงานเชิงโต้ตอบของคุณเอง แผนการใช้งาน Claude แบบใดที่เหมาะกับวิธีการทำงานของคุณ จะครอบคลุมในส่วนของค่าสมาชิก ราคาและขีดจำกัดทั้งหมดในที่นี้ได้รับการตรวจสอบกับเอกสารของ Anthropic ในเดือนตุลาคม 2026 แล้ว ดังนั้นโปรดอ่านหน้าแสดงราคาอีกครั้งก่อนที่คุณจะจัดทำงบประมาณ

FAQ

การรัน AI agent แบบเปิดตลอดเวลาบน VPS มีค่าใช้จ่ายเท่าไร?

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

max_tokens กับ task budget ต่างกันอย่างไร?

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

ทำไม cache_read_input_tokens ถึงเป็นศูนย์เสมอสำหรับ agent ของฉัน?

เพราะส่วนนำ (prefix) มีการเปลี่ยนแปลงระหว่างการเรียกใช้งาน หรือสั้นเกินกว่าที่จะแคชได้ สาเหตุทั่วไปคือการแทรก timestamp หรือ run id ลงใน system prompt เนื่องจากแคชจะอ้างอิงจากส่วนนำ ดังนั้นการเปลี่ยนแปลงเพียงหนึ่งไบต์จะทำให้ข้อมูลหลังจากนั้นทั้งหมดไม่สามารถใช้แคชได้ การเปลี่ยนคำจำกัดความของเครื่องมือ (tool definitions) หรือค่า effort ในระดับบนสุดก็ส่งผลเช่นเดียวกัน นอกจากนี้ยังขึ้นอยู่กับขนาด เพราะ prompt ที่สั้นเกินไปจะไม่ถูกแคชและไม่มีข้อความแจ้งเตือนความผิดพลาดส่งกลับมา

จะหยุดไม่ให้ AI agent ทำงานวนซ้ำไม่รู้จบได้อย่างไร?

ให้เขียนโค้ดนับจำนวนรอบการทำงานและหยุดเมื่อถึงค่าสูงสุดที่กำหนดไว้ เนื่องจาก max_tokens จำกัดเพียงการตอบกลับครั้งเดียว แต่ agent หนึ่งตัวอาจมีการทำงานหลายครั้ง ให้เพิ่มการจำกัดเวลาแบบ wall-clock ไว้ภายนอกกระบวนการ โดยเริ่มงานจาก systemd timer และตั้งค่า TimeoutStartSec= สำหรับ unit แบบ oneshot หรือ RuntimeMaxSec= สำหรับแบบ simple เพื่อให้การทำงานที่ค้างอยู่ถูกยกเลิกตามกำหนดเวลา และควรจำกัดจำนวนครั้งในการลองใหม่ (retry) ด้วย เพราะการวนซ้ำเพื่อลองใหม่จะถูกคิดค่าใช้จ่ายทุกครั้งที่ทำ

ฉันสามารถตั้งค่าจำกัดการใช้จ่ายสำหรับ Claude API key เพียงคีย์เดียวได้หรือไม่?

ขีดจำกัดการใช้จ่ายที่ระบุไว้ในเอกสารเป็นแบบต่อ workspace ไม่ใช่ต่อคีย์ ดังนั้นควรสร้าง workspace แยกสำหรับ agent และตั้งค่าจำกัดการใช้จ่ายรายเดือนไว้ที่นั่น "คุณไม่สามารถตั้งค่าขีดจำกัดบน Default Workspace ได้" ให้เพิ่มการแจ้งเตือนการใช้จ่ายเพื่อให้ระบบแจ้งเตือนเมื่อถึงเกณฑ์ที่กำหนด สำหรับการติดตามการใช้งาน ให้สร้างคีย์แยกสำหรับแต่ละงาน แล้วจัดกลุ่มรายงานการใช้งานด้วย group_by[]=api_key_id