# 코딩 에이전트 작업에 엄격한 지출 한도를 어떻게 설정하나요? > 엄격한 지출 한도는 작업 예산을 소유한 게이트웨이가 모든 모델 또는 유료 도구 호출 전에 집행해야 합니다. 최대 비용을 예약하고 실제 사용량을 정산하며, 남은 예산에 맞지 않는 호출을 거부하고 유용한 체크포인트를 남긴 채 에이전트를 종료하세요. # 코딩 에이전트 작업에 엄격한 지출 한도를 어떻게 설정하나요? 엄격한 예산은 승인 제어 문제입니다. 과금 호출 전에 신뢰할 수 있는 게이트웨이가 허용된 최대 비용이 남은 잔액에 들어가는지 증명해야 합니다. 사후 알림은 이미 발생한 초과 지출을 막지 못합니다. 입력, 최대 출력, 재시도, 폴백, 하위 에이전트, 임베딩, 검색, sandbox, 모든 유료 도구를 포함하세요. ## 엄격한 한도와 유연한 목표 구분하기 세 값을 사용합니다. | 제어 | 목적 | 동작 | |---|---|---| | 목표 | 예상 비용 | 경고하거나 더 저렴한 계획 선택 | | 소프트 한도 | 승격 기준 | 승인을 요청하거나 품질 축소 | | 하드 한도 | 최대 승인 지출 | 다음 호출 전에 거부 | 예를 들어 목표 $0.60, $0.90에서 승인 요청, $1.00에서 중지할 수 있습니다. 하드 한도는 프롬프트만이 아니라 서버에 있어야 합니다. ## 모든 유료 동작을 한 게이트웨이로 통과시키기 에이전트에는 자체 게이트웨이만 호출하는 단기 자격 증명을 줍니다. 게이트웨이는 `task_id`를 붙이고 예산을 조회하며 다음 동작을 추정한 뒤 예약하거나 거부합니다. 회계를 우회할 수 있는 제공자 키를 노출하지 마세요. 검색, sandbox, 코드 실행, 유료 검색에도 같은 규칙을 적용합니다. ## 호출 전에 예약하고 나중에 정산하기 알려진 입력 token과 최대 출력으로 상한을 계산하세요. 원자적으로 예약하고 호출한 뒤 실제 사용량으로 교체합니다. ```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) ``` 원자 예약은 두 하위 에이전트가 같은 잔액을 쓰는 것을 막습니다. ## 버전이 있는 요율표 사용하기 각 추정에 사용한 가격을 이벤트와 함께 저장하세요. 가격과 규칙은 바뀌므로 과거 사용량을 오늘 요율로 재계산하지 않습니다. 제공자가 최종 비용을 반환하면 추정치와 함께 보존합니다. token만 반환하면 호출 전에 선택한 요율표를 사용합니다. 불확실한 도구에는 보수적 여유를 두고 최대 비용을 정할 수 없는 호출은 거부하세요. ## 스트리밍을 안전하게 만들기 스트림을 열기 전에 허용된 전체 출력 비용을 예약하세요. 사용량을 정산하되 클라이언트 연결 종료가 즉시 과금을 멈춘다고 가정하지 마세요. 취소는 최적화이지 집행 경계가 아닙니다. 호출별 출력 한도와 timeout을 두세요. 작업 한도는 모든 스트림, 재시도, 폴백의 합을 포함합니다. ## 재시도와 하위 에이전트 포함하기 모든 시도를 같은 상위 원장에서 차감합니다. 재시도 때 새 예산을 열면 한도가 무효가 됩니다. 계층 예산을 사용할 수 있습니다. | 원장 | 한도 | 규칙 | |---|---:|---| | 상위 작업 | $1.00 | 절대 상한 | | 구현 하위 에이전트 | $0.55 | 상위 잔액을 넘지 않음 | | 테스트 분석 | $0.25 | 미사용 예약 반환 | | 최종 검토 | $0.20 | 잔액이 있을 때만 실행 | 하위 한도는 배분이지 추가 자금이 아닙니다. ## 유용한 체크포인트로 중지하기 다음 동작이 예산에 맞지 않으면 오케스트레이터가 이해하는 타입 오류를 반환하고 거부된 호출을 반복하지 마세요. 기존 컨텍스트로 다음을 포함한 체크포인트를 만듭니다. * 완료된 변경과 테스트. * 남은 작업과 차단된 동작. * 현재 저장소 상태. * 필요한 추가 예산 추정치. * 재개 token 또는 작업 ID. 이렇게 하면 예산 중지가 통제된 인계가 됩니다. ## 제공자 제어를 보조 방어로 사용하기 계정 한도는 영향 범위를 줄이지만 작업별로 정밀하지 않은 경우가 많습니다. 여러 저장소를 합치거나 반영이 늦거나 도구 비용을 누락할 수 있습니다. Atlas Cloud 같은 멀티모델 게이트웨이에서도 권위 있는 작업 원장은 자체 오케스트레이션에 두고 정산용 사용량 ID를 기록하세요. 모델이 바뀌어도 한도는 유지됩니다. ## 재무 통제처럼 한도 시험하기 동시 호출, 긴 스트림, timeout, 사용량 누락, 재시도, 폴백, 원장 장애를 시험하세요. 예산 서비스 장애 시 기본 거부하고 확정 비용과 예약의 합이 한도를 넘지 않는지 검증합니다. ## 결론 진짜 하드 한도는 지출 전에 원자 예약과 모든 과금 동작을 포함하는 하나의 원장으로 집행됩니다. 사용 후 경고만 한다면 엄격한 한도가 아니라 모니터링입니다. ## FAQ ### max_tokens는 금액 기준의 엄격한 한도인가요? 아니요. 한 응답의 길이만 제한하며 총 작업 비용, 입력 token, 재시도, 모델 변경, 유료 도구는 제한하지 않습니다. 금액 한도에는 모든 과금 동작을 감싸는 예산 원장이 필요합니다. ### 에이전트 예산은 어디서 집행해야 하나요? 모든 모델 및 유료 도구 호출이 통과하는 서버 측 게이트웨이나 오케스트레이션 계층에서 집행하세요. 클라이언트 카운터는 우회되거나 동시성 경쟁이 생길 수 있습니다. ### 스트리밍 응답의 예산은 어떻게 잡나요? 스트림을 열기 전에 허용된 최대 출력 비용을 예약하고 종료 후 보고된 사용량으로 정산하세요. 제공자가 지원하면 취소하되 취소에만 의존하지 마세요. ### 재시도는 원래 작업 예산을 공유하나요? 예. 재시도, 폴백, 하위 에이전트, 평가 호출은 별도 예산이 명시적으로 승인되지 않는 한 같은 작업 원장에서 차감해야 합니다. ### 남은 예산이 부족하면 어떻게 하나요? 다음 과금 호출을 거부하고 이미 있는 컨텍스트로 체크포인트를 만들게 하세요. 완료된 작업, 미해결 항목, 계속하는 데 필요한 추가 예산을 포함합니다. ### 제공자 계정 한도로 작업별 한도를 대신할 수 있나요? 보통은 아닙니다. 계정 전체를 보호하며 반영이 비동기일 수 있습니다. 작업별 게이트웨이로 즉시 격리하고 계정 한도는 추가 방어로 사용하세요.