<!-- Canonical URL: https://ask.atlascloud.ai/th/set-hard-spending-limit-coding-agent-task -->

# จะตั้งวงเงินใช้จ่ายแบบตายตัวสำหรับงานของเอเจนต์เขียนโค้ดได้อย่างไร?

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

<!-- Canonical URL: https://ask.atlascloud.ai/set-hard-spending-limit-coding-agent-task -->

# จะตั้งวงเงินใช้จ่ายแบบตายตัวสำหรับงานของเอเจนต์เขียนโค้ดได้อย่างไร?

งบงานแบบตายตัวเป็นปัญหา admission control ก่อนเริ่มการเรียกโมเดลหรือเครื่องมือที่คิดเงิน Gateway ที่เชื่อถือได้ต้องพิสูจน์ว่าต้นทุนสูงสุดที่อนุญาตยังอยู่ในยอดคงเหลือของงาน การแจ้งเตือนและรายงานหลังรันมีประโยชน์ แต่หยุดยอดเกินที่เกิดไปแล้วไม่ได้

การออกแบบควรครอบคลุม input token, output สูงสุด, retry, fallback, เอเจนต์ย่อย, embeddings, search, sandbox และเครื่องมือเสียเงินอื่นทั้งหมด

## แยกวงเงินตายตัวจากเป้าหมายแบบอ่อน

ใช้สามค่า:

| ตัวควบคุม | จุดประสงค์ | พฤติกรรม |
|---|---|---|
| เป้าหมาย | ต้นทุนที่คาด | เตือนหรือเลือกแผนราคาต่ำกว่า |
| วงเงินอ่อน | เกณฑ์ยกระดับ | ขออนุมัติหรือลดคุณภาพ |
| วงเงินตายตัว | ค่าใช้จ่ายสูงสุดที่อนุญาต | ปฏิเสธ call ถัดไปก่อนเริ่ม |

ตัวอย่างเช่น งานอาจตั้งเป้า $0.60 ขออนุมัติที่ $0.90 และหยุดที่ $1.00 วงเงินตายตัวต้องอยู่ฝั่งเซิร์ฟเวอร์ ไม่ใช่เฉพาะในพรอมต์

## วางทุกกิจกรรมที่คิดเงินไว้หลัง gateway เดียว

ให้ credential งานอายุสั้นที่เรียกได้เฉพาะ gateway ของคุณ Gateway เพิ่ม `task_id` อ่านงบ ประเมินกิจกรรมถัดไป และสำรองเงินหรือปฏิเสธ

อย่าเปิดเผย key ผู้ให้บริการที่ทำให้เอเจนต์ข้ามบัญชีได้ ใช้กฎเดียวกันกับ web search, hosted sandbox, การรันโค้ด และบริการ retrieval เสียเงิน

## สำรองก่อนเรียกและกระทบยอดภายหลัง

สำหรับ model call ให้ประเมินขอบบนจาก input token ที่ทราบบวก output สูงสุดที่ตั้งไว้ สำรองแบบ atomic ส่ง request แล้วแทนยอดสำรองด้วยการใช้จริง

```text
remaining = hard_limit - committed_cost - open_reservations
worst_case = input_cost + max_output_cost + tool_allowance

if worst_case > remaining:
    reject("task_budget_exceeded")
else:
    reserve(worst_case)
    call_provider()
    reconcile(actual_cost)
```

การสำรองแบบ atomic ป้องกันเอเจนต์ย่อยสองตัวพร้อมกันใช้ยอดคงเหลือเดียวกัน

## กำหนดราคาด้วย rate card ที่มีเวอร์ชัน

เก็บราคาที่ใช้ประเมินแต่ละครั้งไว้กับเหตุการณ์ ราคาโมเดลและกฎการคิดเงินเปลี่ยนได้ รายงานภายหลังจึงไม่ควรคำนวณการใช้เก่าด้วยราคาวันนี้

เมื่อผู้ให้บริการส่งต้นทุนที่เป็นทางการ ให้เก็บทั้งค่าประมาณและค่าจริง หากส่งเพียง token ให้คำนวณจากเวอร์ชัน rate card ที่เลือกก่อน call เพิ่มส่วนเผื่อแบบระมัดระวังสำหรับค่าเครื่องมือที่ไม่รู้ หรือปฏิเสธ call ที่จำกัดต้นทุนสูงสุดไม่ได้

## ทำให้ streaming ปลอดภัย

สำรองต้นทุนเต็มที่อนุญาตก่อนเปิด stream นับ usage ที่ได้รับเมื่อมี แต่อย่าสมมติว่าปิดการเชื่อมต่อ client แล้วผู้ให้บริการหยุดคิดเงินทันที การยกเลิกเป็นการปรับให้ดีขึ้น ไม่ใช่ขอบเขตการบังคับ

ตั้ง output limit ต่อ call และ wall-clock timeout วงเงินงานยังครอบคลุมยอดรวมของ stream, retry และ fallback ทั้งหมด

## รวม retry และเอเจนต์ย่อย

ทุกความพยายามหักจาก ledger งานหลักเดียวกัน นโยบาย retry ที่เปิดงบใหม่เงียบๆ ทำให้วงเงินไม่มีผล

ใช้งบแบบลำดับชั้นเมื่อมอบหมาย:

| Ledger | วงเงิน | กฎ |
|---|---:|---|
| งานหลัก | $1.00 | เพดานสูงสุด |
| เอเจนต์ย่อย implementation | $0.55 | ห้ามเกินยอดคงเหลืองานหลัก |
| เอเจนต์ย่อยวิเคราะห์ test | $0.25 | คืนเงินสำรองที่ไม่ใช้ |
| ตรวจสุดท้าย | $0.20 | รันเมื่อมีเงินเหลือเท่านั้น |

วงเงินย่อยเป็นการจัดสรร ไม่ใช่เงินเพิ่ม

## หยุดพร้อม checkpoint ที่ใช้ได้

เมื่อกิจกรรมถัดไปไม่พอดี ให้คืน error แบบมีชนิดที่ orchestrator เข้าใจ เอเจนต์ไม่ควร retry call ที่ถูกปฏิเสธซ้ำๆ

ให้สร้าง checkpoint ที่ไม่เสียเงินจากบริบทปัจจุบัน ซึ่งประกอบด้วย:

* การเปลี่ยนที่เสร็จและผล test;
* งานที่เหลือและกิจกรรมที่ถูกบล็อก;
* สถานะ repository ปัจจุบัน;
* งบเพิ่มเติมโดยประมาณ;
* resume token หรือ ID งาน

วิธีนี้เปลี่ยนการหยุดเพราะงบให้เป็นการส่งต่องานที่ควบคุมได้ แทนงานค้างที่เสียหาย

## ใช้การควบคุมของผู้ให้บริการเป็นตัวป้องกันสำรอง

วงเงินบัญชีผู้ให้บริการและ gateway ลดขอบเขตความเสียหายได้ แต่มักไม่แม่นยำต่องาน อาจรวมหลาย repository อัปเดตแบบ asynchronous หรือไม่รวมค่าเครื่องมือ

เมื่อใช้ gateway หลายโมเดล เช่น Atlas Cloud ให้เก็บ ledger งานที่เป็นทางการใน orchestration และบันทึก ID usage ของ gateway เพื่อกระทบยอด ขอบเขตตายตัวจะยังคงอยู่เมื่อเปลี่ยนโมเดล

## ทดสอบวงเงินเหมือนการควบคุมการเงิน

ทดสอบ call พร้อมกัน stream ยาว timeout ของผู้ให้บริการ ฟิลด์ usage ที่หาย retry, model fallback และ ledger failure ให้ปฏิเสธเป็นค่าเริ่มต้นเมื่อบริการงบใช้ไม่ได้ ตรวจว่ายอดใช้ที่ยืนยันแล้วบวกยอดสำรองเปิดไม่เกินวงเงินตายตัว

## สรุป

วงเงินใช้จ่ายแบบตายตัวที่แท้จริงต้องบังคับก่อนใช้เงิน ด้วยการสำรองแบบ atomic และ ledger เดียวสำหรับทุกกิจกรรมที่คิดเงิน หากระบบเพียงเตือนหลัง usage เข้ามา นั่นคือ monitoring ไม่ใช่วงเงินตายตัว

## FAQ

### max_tokens เป็นวงเงินแบบตายตัวหรือไม่?

ไม่ใช่ มันจำกัดความยาวของคำตอบหนึ่งครั้ง ไม่ได้จำกัดต้นทุนรวม token ขาเข้า การลองใหม่ การเปลี่ยนโมเดล หรือเครื่องมือเสียเงิน วงเงินต้องมี ledger ครอบทุกกิจกรรมที่คิดค่าใช้จ่าย

### ควรบังคับใช้งบประมาณเอเจนต์เขียนโค้ดที่ใด?

บังคับที่ gateway ฝั่งเซิร์ฟเวอร์หรือชั้น orchestration ที่ทุกการเรียกโมเดลและเครื่องมือเสียเงินต้องผ่าน ตัวนับฝั่ง client อาจถูกข้ามหรือเกิด race เมื่อทำงานพร้อมกัน

### จะกำหนดงบสำหรับ streaming response อย่างไร?

สำรองต้นทุน output สูงสุดที่อนุญาตก่อนเปิด stream แล้วกระทบยอดกับการใช้งานที่รายงานเมื่อจบ ยกเลิกที่ผู้ให้บริการได้เมื่อรองรับ แต่อย่าพึ่งการยกเลิกเพียงอย่างเดียว

### การลองใหม่ควรใช้งบประมาณงานเดิมหรือไม่?

ควร การลองใหม่ fallback เอเจนต์ย่อย และการประเมินต้องหักจาก ledger เดียวกัน เว้นแต่ผู้ใช้อนุมัติงบแยกอย่างชัดเจน

### ควรเกิดอะไรขึ้นเมื่อเงินคงเหลือไม่พอ?

ปฏิเสธกิจกรรมที่คิดค่าใช้จ่ายรายการถัดไป และให้เอเจนต์สร้าง checkpoint จากบริบทที่มี โดยระบุงานที่เสร็จ สิ่งที่ค้าง และงบเพิ่มเติมที่ต้องใช้

### วงเงินบัญชีของผู้ให้บริการแทนวงเงินต่องานได้หรือไม่?

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