โดย วิธีคุมค่าใช้จ่าย AI agent บน VPS ไม่ให้บานปลาย
ป้องกันงบประมาณบานปลายจาก unattended agent ด้วยการตั้ง Hard caps กำหนด Task budgets และใช้ Prompt caching เพื่อลดจำนวน token ที่ต้องจ่ายจริง
วิธีควบคุมค่าใช้จ่ายของ AI agent ที่ทำงานตลอดเวลาไม่ให้บานปลาย
การควบคุมค่าใช้จ่ายของ AI agent บน VPS (virtual private server) คือการกำหนดเพดานการใช้งานก่อนเริ่มทำงาน เนื่องจากไม่มีผู้คอยตรวจสอบการใช้งานขณะระบบกำลังทำงาน ควรจำกัดจำนวนการตอบกลับด้วย max_tokens กำหนดจำนวนรอบการทำงาน (loop iterations) ใน code ของคุณเอง ทำการ cache ส่วนของ prompt ที่ไม่มีการเปลี่ยนแปลง และบันทึกข้อมูลการใช้งาน (usage numbers) ของทุกการตอบกลับเพื่อตรวจสอบว่างานใดใช้จ่ายสูง ค่าเช่า server เป็นราคาคงที่ต่อเดือน แต่ค่า model API จะคิดตามจำนวน token ที่ใช้จริง และการทำงานแบบ loop ที่ไม่มีผู้ควบคุมสามารถใช้ token จำนวนมากได้อย่างรวดเร็ว
ข้อมูลนี้ใช้สำหรับ AI agent ที่มีอยู่แล้วและเรียกใช้งาน Messages API จากเครื่องที่คุณเป็นเจ้าของ การสร้าง AI agent ด้วย Claude บน VPS จะอธิบายถึงกลไกการทำงานของระบบดังกล่าว
ทำไม unattended agent จึงมีรูปแบบต้นทุนที่แตกต่างออกไป
Interactive session มีมนุษย์ควบคุมอยู่ เมื่อ model ทำงานผิดพลาดหรืออ่าน log ที่มีความยาว 40,000 บรรทัด ผู้ที่เฝ้าดูอยู่จะสั่งหยุดการทำงาน แต่ unattended agent ไม่มีระบบหยุดเช่นนี้ มันจะทำงานจนกว่า loop จะสิ้นสุดลง จากนั้น timer จะเริ่มทำงานใหม่อีกครั้ง
ความถี่คือตัวคูณที่คนมักมองข้าม งานที่ตั้งเวลาทุก 5 นาที จะทำงาน 288 ครั้งต่อวัน หรือประมาณ 8,640 ครั้งต่อเดือน ต้นทุนต่อการทำงานหนึ่งครั้งจะถูกนำไปคูณด้วยจำนวนครั้งดังกล่าว Agent แบบ "always-on" หลายตัวไม่จำเป็นต้องเปิดทิ้งไว้ตลอดเวลา แต่ต้องการการตอบสนองภายในเวลาที่กำหนด ซึ่งถือเป็นรูปแบบการทำงานตามตารางเวลา
Agent ยังมีค่าใช้จ่ายในส่วนที่ chat window ไม่มี
- Tool definitions จะถูกส่งไปพร้อมกับทุก request ระบบ tool-use system 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 - ผลลัพธ์จาก tool คือ input tokens คำสั่งที่แสดงผล 8,000 บรรทัด จะส่งข้อมูล 8,000 บรรทัดนั้นเข้าไปใน request ถัดไป และในทุก request ที่ตามมาใน turn นั้น
- หน้าที่ที่ดึงข้อมูลมา (Fetched pages) คือ input tokens หน้าเว็บขนาด 10 kB โดยเฉลี่ย จะมีค่าประมาณ 2,500 tokens และไฟล์ PDF งานวิจัยขนาด 500 kB จะมีค่าประมาณ 125,000 tokens
max_content_tokensจะตัดข้อความ (truncate) เฉพาะข้อมูลที่เป็น text เท่านั้น เนื่องจาก "ใช้กับเนื้อหาที่เป็น text ไม่ใช่เนื้อหาที่เป็น binary เช่น PDF" หากต้องการจัดการ PDF ให้ใช้max_usesและallowed_domainsแทน - Web search คิดราคาต่อการค้นหา อยู่ที่ $10 ต่อ 1,000 การค้นหา ไม่ว่าจะได้รับผลลัพธ์จำนวนเท่าใดก็ตาม หากการค้นหาเกิดข้อผิดพลาด (error) จะไม่มีการเรียกเก็บเงิน
ค่าใช้จ่ายเหล่านี้ไม่ได้สูงเมื่อพิจารณาจากการทำงานเพียงครั้งเดียว แต่จะสูงมากเมื่อต้องทำงานถึง 8,640 ครั้ง
Hard ceilings และ soft ceilings แก้ไขปัญหาที่แตกต่างกัน
มีการบังคับใช้ max_tokens นี่คือขีดจำกัดสูงสุด (hard cap) ของผลลัพธ์รวมต่อหนึ่ง request ซึ่งนับรวมทั้งข้อความส่วนการคิด (thinking) และข้อความตอบกลับ (response) Claude จะไม่สร้างข้อความเกินขีดจำกัดนี้ และโมเดลไม่สามารถรับรู้ค่าตัวเลขนี้ได้ หากใช้งานจนถึงขีดจำกัดจะเกิด stop_reason: "max_tokens" และคำตอบจะถูกตัดตอน (truncated) ข้อควรระวังสำหรับ agent คือ ทุก request ใน tool-use loop จะมี max_tokens เป็นของตัวเอง ดังนั้นขีดจำกัดนี้จึงใช้ควบคุมเพียงหนึ่งการตอบกลับ ไม่ใช่ทั้งงาน (task) ตัวอย่างเช่น การเรียกใช้ tool 10 ครั้ง ครั้งละ 4,000 tokens จะทำให้เพดานรวมของรอบนั้นคือ 40,000 tokens
Task budget คือคำแนะนำ task_budget ทำงานอยู่ภายใต้ output_config เพื่อบอกโมเดลว่ามีจำนวน token เท่าใดสำหรับทั้ง agentic loop โดยนับรวมทั้งการคิด, การเรียกใช้ tool, ผลลัพธ์จาก tool และผลลัพธ์การตอบกลับ
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,
)"Task budgets เป็นเพียงคำแนะนำแบบ soft hint ไม่ใช่ขีดจำกัดแบบ hard cap" Claude อาจใช้งานเกินกำหนดในระหว่างการทำงานบางขั้นตอน แต่ขีดจำกัดการส่งออก (output) ที่ถูกบังคับใช้ยังคงเป็น max_tokens "โมเดลเท่านั้นที่มองเห็นการนับถอยหลัง" และการตอบกลับจะไม่มีฟิลด์แสดงงบประมาณที่เหลืออยู่ ค่า task_budget.total ขั้นต่ำที่ยอมรับได้คือ 20,000 tokens หากน้อยกว่านี้จะส่งคืน error 400 หากงบประมาณน้อยเกินไปสำหรับงานที่ได้รับ จะทำให้โมเดลมีพฤติกรรมคล้ายกับการปฏิเสธงาน โดยโมเดลจะลดขอบเขตของงานลงหรือหยุดทำงานก่อนกำหนด
รายละเอียดหนึ่งอย่างที่ส่งผลต่อค่าใช้จ่ายแทนที่จะเป็นการประหยัด หาก client ของคุณทำการลดค่า task_budget.remaining ในทุก request ที่ส่งตามไป ค่าที่เปลี่ยนไปจะทำให้ prefix ที่ถูก cache ไว้ซึ่งมีค่านั้นอยู่กลายเป็นโมฆะ ควรตั้งค่าเพียงครั้งเดียวในการ request ครั้งแรก
Task budgets อยู่ในสถานะ beta บน Claude Fable 5, Claude Opus 4.8 และ Claude Opus 4.7 สำหรับ Claude Sonnet 5 และ Claude Haiku 4.5 ถูกระบุว่าเป็น Not supported และ task budgets ไม่สามารถใช้กับ Claude Code ดังนั้น Claude Code session detached in tmux จึงต้องอาศัยการจัดการ session ที่ดีแทน
ขีดจำกัดที่สามอยู่ใน Claude Console: ให้ agent มี workspace ของตัวเอง จากนั้นจึงตั้งค่าจำกัดการใช้จ่ายรายเดือน (monthly spend limit) และจำกัดอัตราการใช้งานต่อนาที (per-minute rate limits) "คุณไม่สามารถตั้งค่าขีดจำกัดใน Default Workspace ได้" และ "ขีดจำกัดระดับ Organization-wide จะมีผลเสมอ แม้ว่าขีดจำกัดของ workspace รวมกันแล้วจะมากกว่าก็ตาม" ควรเพิ่มการแจ้งเตือนการใช้จ่าย (spend notifications) เพื่อให้มีการแจ้งเตือนเมื่อถึงเกณฑ์ที่กำหนดก่อนที่ขีดจำกัดจะถูกบังคับใช้
การเลือกโมเดลตามลักษณะงาน และปัจจัยที่มีผลต่อค่าใช้จ่าย
การเลือกโมเดลต้องพิจารณาเป็นรายงาน (per-job) ข้อมูล ณ เดือน July 2026 สำหรับราคาต่อหนึ่งล้าน token (input และ output) คือ: Claude Fable 5 ราคา $10 และ $50, Claude Opus 4.8 และ Opus 4.7 ราคา $5 และ $25, Claude Sonnet 5 ราคา $3 และ $15, และ Claude Haiku 4.5 ราคา $1 และ $5 ปัจจุบันราคาของ Sonnet 5 ต่ำกว่าราคาปกติ เนื่องจาก "Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026" งานที่ใช้เพียงการจำแนกประเภท log lines ไม่จำเป็นต้องใช้ Opus
Effort คือปัจจัยที่สองในการควบคุมค่าใช้จ่าย output_config.effort รองรับค่า low, medium, high, xhigh และ max โดยมีค่าเริ่มต้นคือ high ดังนั้นการกำหนดค่า high ไว้ล่วงหน้าจึงมีผลเท่ากับการไม่กำหนดค่า การลดระดับ effort ช่วยประหยัดค่าใช้จ่ายได้มากกว่าเพียงแค่การลดความยาวของ reasoning ตามเอกสารระบุว่าการลด effort จะทำให้ Claude ใช้จำนวน tool calls น้อยลง และรวมการทำงานหลายอย่างเข้าเป็นหนึ่งเดียว สำหรับการใช้งานแบบ agent สิ่งนี้จะช่วยประหยัดค่าใช้จ่ายได้มาก เนื่องจาก tool call ที่ถูกยกเลิกไปจะช่วยลดจำนวน request ทั้งหมดที่ต้องเกิดขึ้น
ข้อควรระวังคือการใช้ effort ที่ขัดแย้งกับการทำงานของ cache การเปลี่ยนค่าระหว่าง request จะทำให้ prompt caching สิ้นสุดลง ในตัวอย่างที่ระบุไว้ request ที่ 2 รายงานค่า cache_read_input_tokens: 3546 ส่วน request ที่ 3 ซึ่งมีการเปลี่ยน effort จาก high เป็น medium รายงานค่า cache_creation_input_tokens เท่ากับ 3546 และ cache_read_input_tokens เท่ากับ 0 ดังนั้นควรเปลี่ยนค่า effort ตามลักษณะของ workload และไม่ควรเปลี่ยนค่าภายในบทสนทนาที่มีการใช้ cache หากต้องการควบคุมความลึกของคำตอบโดยไม่ทำให้ cache เสียไป ให้ใช้วิธีระบุใน prompt เช่น การเพิ่มข้อความ "Answer directly without deliberating." ลงใน user message ล่าสุด เพื่อรักษา breakpoint ก่อนหน้าไว้
Thinking tokens จะถูกคิดราคาในอัตราเดียวกับ output และนับรวมใน max_tokens ซึ่งเป็นสาเหตุที่คำตอบที่ถูกตัดตอน (truncated answer) มักเกิดจากการที่กระบวนการ thinking ใช้ budget จนหมด สามารถอ่านรายละเอียดเพิ่มเติมได้ที่ usage.output_tokens_details.thinking_tokens สำหรับจำนวนที่แน่นอน หรือดู ปัจจัยที่ทำให้ค่าใช้จ่าย Claude token สูงขึ้น เพื่อทำความเข้าใจรายละเอียดเชิงลึก
การทำ Cache สำหรับ stable prefix เพื่อป้องกันความผิดพลาดโดยไม่ตั้งใจ
การเขียนข้อมูลลง cache มีค่าใช้จ่ายเป็น 1.25 เท่าของราคา input พื้นฐานสำหรับ cache แบบ 5 นาที และเป็น 2 เท่าสำหรับ cache แบบ 1 ชั่วโมง ส่วนการอ่านข้อมูลจาก cache มีค่าใช้จ่ายเพียง 0.1 เท่า ดังนั้น "การทำ cache จะคุ้มค่าหลังจากอ่านข้อมูลเพียง 1 ครั้งสำหรับระยะเวลา 5 นาที (เขียน 1.25x) หรือหลังจากอ่านข้อมูล 2 ครั้งสำหรับระยะเวลา 1 ชั่วโมง (เขียน 2x)"
เหตุผลที่วิธีนี้เหมาะสำหรับ agent ที่ทำงานตลอดเวลาคือ "cache จะถูก refresh โดยไม่มีค่าใช้จ่ายเพิ่มเติมในทุกครั้งที่มีการใช้งานเนื้อหาที่ถูก cache ไว้" หากมี job ทำงานทุก 2 นาทีกับ cache แบบ 5 นาที จะสามารถรักษา prefix ให้ warm ได้ตลอดทั้งวันโดยเสียค่าเขียนเพียงครั้งเดียว
3 วิธีที่ทำให้สูญเสีย cache โดยไม่รู้ตัว
Prefix ที่มีการเปลี่ยนแปลง "Cache prefixes ถูกสร้างขึ้นตามลำดับดังนี้: tools, system, และ messages" หากมีการเปลี่ยนแปลงข้อมูลแม้เพียง 1 byte ในลำดับก่อนหน้า จะทำให้ข้อมูลที่ตามมาทั้งหมดใช้งานไม่ได้ และการแก้ไข tool definitions จะทำให้ cache ทั้งหมดใช้งานไม่ได้ สาเหตุที่พบบ่อยคือการใส่ timestamp หรือ run id ไว้ใน system prompt ซึ่งจะทำให้ทุก request มี prefix ที่ต่างกัน ส่งผลให้ต้องเขียนข้อมูลใหม่ที่ราคา 1.25x และไม่สามารถอ่านข้อมูลเดิมได้ วิธีสังเกตคือค่า usage.cache_read_input_tokens จะเป็น 0 แม้จะเป็นการเรียกใช้งานที่ดูเหมือนกัน ให้ย้ายข้อความที่มีการเปลี่ยนแปลงบ่อยไปไว้ใน user message ล่าสุดแทน
Prefix ที่สั้นเกินไป โมเดลแต่ละรุ่นมีกำหนดความยาวขั้นต่ำที่สามารถทำ cache ได้ หากสั้นกว่านั้น request จะถูกประมวลผลโดยไม่มีการทำ cache และ "ไม่มี error ใดๆ ถูกส่งกลับมา" ตัวอย่างเช่น Claude Opus 4.8 และ Claude Sonnet 5 กำหนดไว้ที่ 1,024 tokens ส่วน Claude Haiku 4.5 กำหนดไว้ที่ 4,096 tokens ดังนั้นการเปลี่ยน job จาก Sonnet ไปเป็น Haiku อาจทำให้การทำ caching ถูกปิดใช้งานโดยไม่ทราบสาเหตุ
บทสนทนาที่มีความยาวเกินช่วง lookback "Lookback window คือ 20 blocks" ระบบจะตรวจสอบตำแหน่งสูงสุด 20 ตำแหน่งต่อหนึ่ง breakpoint แล้วหยุดทำงาน จากตัวอย่างที่ระบุไว้ หาก turn หนึ่งมี 35 blocks และมี breakpoint ที่ block 35 ระบบจะตรวจสอบตั้งแต่ block 35 ลงไปถึง block 16 ทำให้ entry ของ turn ก่อนหน้า ณ block 15 อยู่นอกช่วง window จึงไม่เกิด cache hit หาก agent มีการเพิ่ม tool-use และ tool-result blocks หลาย blocks ต่อหนึ่ง turn จะทำให้จำนวน block เกิน 20 ภายใน 2 หรือ 3 turn เนื่องจากแต่ละ request มี 4 breakpoints จึงควรใช้หนึ่ง breakpoint สำหรับข้อความล่าสุด
ส่งข้อมูลที่ไม่ต้องใช้การตอบสนองทันทีไปยัง Batches API
การใช้งานทั้งหมดจะถูกคิดค่าบริการที่ 50% ของราคา API มาตรฐาน ทั้งในส่วนของ input และ output การประมวลผลแบบ Batch เป็นแบบ asynchronous โดย "batch ส่วนใหญ่จะเสร็จสิ้นภายในเวลาไม่ถึง 1 ชั่วโมง" ผลลัพธ์จะพร้อมใช้งานเมื่อทุก request ทำงานเสร็จสิ้น หรือหลังจากผ่านไป 24 ชั่วโมง แล้วแต่ว่าเหตุการณ์ใดจะเกิดขึ้นก่อน ข้อมูลนี้เป็นค่าโดยประมาณ ไม่ใช่การรับประกัน
ตรวจสอบสถานะ processing_status จนกว่าจะอ่านค่าได้เป็น ended Request ที่ส่งคืนค่า errored, canceled หรือ expired จะไม่มีการคิดค่าบริการ ข้อควรระวังหากคุณมีการจำกัดวงเงินการใช้งาน: "batch อาจมีการใช้งานเกินวงเงินที่กำหนดไว้ใน Workspace ของคุณเล็กน้อย"
ส่วนลดนี้สามารถใช้ร่วมกันได้ และเนื่องจาก batch อาจใช้เวลามากกว่า 5 นาที เอกสารจึงแนะนำให้ใช้ cache ระยะเวลา 1 ชั่วโมงสำหรับ batch ที่ใช้ context ร่วมกัน ดังนั้นควรแบ่งลักษณะงาน: งานใดก็ตามที่ผู้ใช้งานหรือ webhook ต้องรอคำตอบให้ใช้การประมวลผลแบบปกติ ส่วนงานประเภทสรุปผลประจำวันหรือการจำแนก log ของเมื่อวาน ให้ส่งเข้า batch เพื่อประหยัดค่าใช้จ่ายลงครึ่งหนึ่ง
บันทึกข้อมูลการใช้งานของทุก response ลงใน store ของคุณเอง
คุณไม่สามารถระบุค่าใช้จ่ายได้หากไม่มีการบันทึกข้อมูล ทุก response จะระบุต้นทุนที่เกิดขึ้น
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 โดยระบุชื่อ job กำกับไว้ เมื่อผ่านไปหนึ่งสัปดาห์ คุณจะสามารถระบุได้ว่า job ใดมีการใช้จ่ายจริง และ job ใดที่มีเพียงกิจกรรมที่ดูเหมือนยุ่งแต่ไม่มีค่าใช้จ่าย โปรดตรวจสอบ cache_read: คอลัมน์ที่มีค่าเป็นศูนย์คือข้อผิดพลาดด้านต้นทุนที่พบบ่อยที่สุดใน self-hosted agent
มีฟิลด์หนึ่งที่อาจอ่านค่าผิดได้ง่าย input_tokens จะนับเฉพาะ token ที่อยู่หลังจุดพัก cache ล่าสุด ดังนั้นขนาด prompt ที่แท้จริงคือ total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens หาก agent รายงานค่า input_tokens: 400 สำหรับ prompt ขนาดใหญ่ แสดงว่าไม่ได้มีราคาถูกอย่างที่คิด เนื่องจากส่วนที่เหลือมาจาก cache
ควรคำนวณจำนวน token ก่อนส่ง การนับ token ไม่มีค่าใช้จ่ายและมี rate limits แยกจากการสร้าง message ดังนั้นควรใช้ count_tokens เพื่อปฏิเสธไฟล์แนบที่มีขนาดใหญ่เกินไป แทนที่จะต้องจ่ายเงินเพื่อตรวจสอบ ผลลัพธ์ที่ได้คือค่าประมาณ ดังนั้นควรวัดผลใหม่ตามแต่ละ model และห้ามใช้ค่าที่ได้จาก tokenizer ของ vendor รายอื่น Claude Opus 4.7 และ model Opus รุ่นที่ใหม่กว่า, Claude Fable 5 และ Claude Sonnet 5 ใช้ tokenizer รุ่นใหม่ซึ่ง "สร้าง token มากกว่าเดิมประมาณ 30% สำหรับข้อความชุดเดิม" ส่วน Claude Sonnet 4.6 และรุ่นที่เก่ากว่า รวมถึง Claude Haiku 4.5 ใช้ tokenizer รุ่นก่อนหน้า
สำหรับการตรวจสอบข้อมูลที่ถูกต้องที่สุด Admin API จะรายงานการใช้งานที่ https://api.anthropic.com/v1/organizations/usage_report/messages และรายงานต้นทุนที่ https://api.anthropic.com/v1/organizations/cost_report ทั้งคู่ต้องใช้ admin key (sk-ant-admin01-...) เป็น x-api-key: $ANTHROPIC_ADMIN_KEY พร้อมกับ anthropic-version: 2023-06-01 และรองรับ bucket_width=1d, group_by[]=model และ api_key_ids[]= ข้อจำกัดหนึ่งประการคือ "Admin API ไม่สามารถใช้งานได้สำหรับบัญชีบุคคลธรรมดา (individual accounts)"
พารามิเตอร์สุดท้ายคือเทคนิคการระบุที่มาที่ประหยัดค่าใช้จ่าย: ให้แต่ละ job ใช้ API key ของตัวเอง จากนั้นกรองด้วย api_key_ids[] และแยกรายงานตาม key ด้วย group_by[]=api_key_id ตัวกรอง (filter) เป็นพหูพจน์ แต่ตัวมิติในการจัดกลุ่ม (grouping dimension) เป็นเอกพจน์ ควรเก็บ key ไว้ใน environment แทนที่จะเก็บไว้ใน code เช่นเดียวกับวิธีที่ a first Claude API app on a VPS ใช้งาน
Bound the loop, because nothing else will
A bounded iteration count is not optional here. The loop is yours, so the counter is yours:
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)Neither ceiling above does it for you: max_tokens caps one response, and the model is only advised of a task budget.
Put a second brake outside the process. Run the job from a systemd timer instead of a permanent process, and set RuntimeMaxSec= on its service unit. With RuntimeMaxSec=600, a hung run is killed after ten minutes instead of spinning until you notice. Running a program as a systemd service and timer covers the unit files themselves. Read what a run did with journalctl -u triage-agent.service --since "1 hour ago".
Cap retries as well, because a handler that retries forever bills every attempt. A 429 or a 500 deserves a few tries with backoff. A 400 deserves none, since the same request fails the same way.
การควบคุมค่าใช้จ่าย AI agent เริ่มต้นจากการตรวจสอบตัวเลขของคุณเอง
ไม่มีใครสามารถระบุค่าใช้จ่ายของ agent ที่ทำงานตลอดเวลาได้ เนื่องจากค่าใช้จ่ายคำนวณจากจำนวน tokens ต่อการรันหนึ่งครั้ง คูณด้วยจำนวนครั้งที่รันต่อวัน ซึ่งข้อมูลทั้งสองส่วนเป็นข้อมูลส่วนบุคคลของคุณ ให้ลองรันระบบหนึ่งครั้ง แล้วอ่านค่าการใช้งานที่บันทึกไว้ จากนั้นนำไปคูณกับตารางเวลาการทำงานของคุณ เมื่อผ่านไปสองวัน ให้ตรวจสอบรายงานค่าใช้จ่ายเทียบกับผลคำนวณดังกล่าว หากตัวเลขไม่ตรงกัน สาเหตุเกือบทั้งหมดเกิดจาก cache ทำงานผิดพลาด หรือเกิด loop ที่ทำงานนานกว่าที่คาดการณ์ไว้
ข้อมูลนี้อ้างอิงจากการใช้ API key เนื่องจาก agent คือโปรแกรมของคุณที่เรียกใช้งาน Messages API สำหรับการใช้งานแบบ interactive ส่วนบุคคล แผน Claude แบบใดที่เหมาะกับรูปแบบการทำงานของคุณ จะให้ข้อมูลในด้านการสมัครสมาชิก ราคาและข้อจำกัดทั้งหมดในที่นี้ได้รับการตรวจสอบกับเอกสารของ Anthropic เมื่อเดือน July 2026 ดังนั้นโปรดอ่านหน้า pricing อีกครั้งก่อนจัดทำงบประมาณ
FAQ
ค่าใช้จ่ายในการรัน AI agent แบบ always-on บน VPS คือเท่าใด?
มีค่าใช้จ่ายสองส่วนและมีเพียงส่วนเดียวที่คาดการณ์ได้ ค่าเซิร์ฟเวอร์เป็นราคาคงที่ต่อเดือน ส่วน Model API จะคิดค่าบริการตามจำนวน token ดังนั้นค่าใช้จ่ายจึงขึ้นอยู่กับจำนวนที่ใช้ต่อการรันหนึ่งครั้งคูณด้วยความถี่ในการรัน Anthropic ไม่ได้ระบุตัวเลขสำหรับ self-hosted always-on agent ดังนั้นให้ถือว่าตัวเลขใดก็ตามที่ระบุไว้เป็นเพียงการคาดเดา ให้ตรวจสอบ Log usage จากการใช้งานจริงหนึ่งครั้งแล้วคูณด้วยความถี่ตามตารางเวลาของคุณ
max_tokens และ task budget แตกต่างกันอย่างไร?
max_tokens เป็นการบังคับใช้และโมเดลจะไม่ทราบค่านี้ โดยจะจำกัดจำนวน output ของการเรียกใช้งานหนึ่งครั้งรวมถึงการคิด (thinking) หากใช้งานจนเต็มขีดจำกัดจะเกิด stop_reason: "max_tokens" ส่วน task budget มีลักษณะตรงกันข้าม คือโมเดลจะได้รับทราบจำนวนดังกล่าวและใช้ควบคุมรอบการทำงานของ agent แต่ "Task budgets are a soft hint, not a hard cap" และขีดจำกัดที่บังคับใช้จริงยังคงเป็น max_tokens
ทำไม cache_read_input_tokens ถึงเป็นศูนย์เสมอสำหรับ agent ของฉัน?
เนื่องจาก prefix เปลี่ยนแปลงไปในแต่ละการเรียกใช้งาน หรือมีความยาวไม่เพียงพอที่จะทำ cache สาเหตุทั่วไปคือการใส่ timestamp หรือ run id ลงใน system prompt เนื่องจาก cache ใช้ prefix เป็นคีย์หลัก ดังนั้นการเปลี่ยนแปลงเพียงหนึ่ง byte จะทำให้ข้อมูลหลังจากนั้นทั้งหมดใช้งานไม่ได้ การเปลี่ยน tool definitions หรือค่า effort ก็ส่งผลเช่นเดียวกัน นอกจากนี้อาจเกิดจากขนาดของ prompt เนื่องจาก prompt ที่สั้นเกินไปจะไม่ถูกเก็บใน cache และจะไม่มีการแจ้งเตือน error ใดๆ
ฉันจะหยุด AI agent ไม่ให้ทำงานวนลูปไม่สิ้นสุดได้อย่างไร?
ให้ทำการนับจำนวน iteration ใน loop code และหยุดเมื่อถึงค่าสูงสุดที่กำหนด เนื่องจาก max_tokens จำกัดเพียงหนึ่งการตอบสนอง แต่ agent จะมีการเรียกใช้งานหลายครั้ง ให้เพิ่มการจำกัดเวลา (wall-clock limit) นอกกระบวนการทำงาน เช่น เริ่มงานด้วย systemd timer ที่ตั้งค่า RuntimeMaxSec= ไว้ เพื่อให้ระบบสั่งปิดการทำงานที่ค้างอยู่ตามกำหนดเวลา นอกจากนี้ควรจำกัดจำนวนการ retry เนื่องจาก loop การ retry จะทำให้เกิดค่าใช้จ่ายในทุกความพยายาม
ฉันสามารถตั้งค่าจำกัดการใช้จ่าย (spending limit) สำหรับ Claude API key เพียงอันเดียวได้หรือไม่?
การจำกัดการใช้จ่ายตามเอกสารระบุว่าเป็นแบบต่อ workspace ไม่ใช่ต่อ key ดังนั้นควรสร้าง workspace แยกต่างหากให้ agent และจำกัดการใช้จ่ายรายเดือนที่นั่น "You cannot set limits on the Default Workspace" ควรตั้งค่าการแจ้งเตือนการใช้จ่ายเพื่อให้ระบบแจ้งเตือนเมื่อถึงเกณฑ์ที่กำหนด สำหรับการระบุแหล่งที่มา ให้สร้าง key แยกสำหรับแต่ละงาน แล้วจึงรวบรวมรายงานการใช้งานด้วย group_by[]=api_key_id