429 usage_limit_exceeded: COST limit exceeded. "$100/일"이 게이트웨이 키의 하드 리밋이며, 취소된 시도의 지출도 한도에 포함됨을 처음 확인260827 방법론 감사(F1~F7)에서 확정된 F3(writer 지침 통일)·F4(30s 고정 청킹) 수정 코드로 sonnet p1(blind/textlog/frames/rf-v2/rf-v3
5전략)을 job 98728로 제출했다. 재측정 자체는 별도 카드(260828-v1final_rf_remeasure.html, flash 결과)로 다루고,
이 카드는 sonnet 재제출 과정에서 연달아 발생한 두 건의 인프라 사고를 기록한다 — 둘 다 실험 결과가 아니라
eval 파이프라인·게이트웨이 운영상의 결함이라 별도 engineering 카드로 분리.
sonnet p1(job 98728)이 시작 10분 만에 15/100편이 완료된 것을 이상 신호로 포착. 조사 결과, 어제 취소된 job 97369의
구 체크포인트 8편(구 rf-v2 프롬프트·세그먼트 청킹, rf-v3 행 자체가 없는 버전)을 러너가 그대로 복원해 해당 편을 전부
skip한 것으로 확인됐다. 원인은 러너의 체크포인트 복원 로직이 전략 집합·프롬프트 버전을 검증하지 않는 것 —
partial_*.json 파일이 존재하면 그 편을 무조건 완료로 간주하고 skip한다.
재제출된 job 99206이 81/100편 지점에서 4샤드가 동시에 종료 — 원인은 429 usage_limit_exceeded: COST limit exceeded.
"$100/일"이 게이트웨이 키에 걸린 하드 리밋이라는 사실을 이번에 처음 확인했다. 당일(UTC 8/27) 지출 내역을
역산하면:
| 항목 | 비용 | 비고 |
|---|---|---|
| rf-v3 카나리아 | $0.15 | 1편 샘플 |
| 취소된 flash rf-v3 런 #1 (job 98727) | ≈$3 | F1(54s 프레임 누출) 발견으로 취소 |
| 취소된 flash rf-v3 런 #2 (job 98734) | ≈$14 | 94/100편, F3/F4 미적용이라 취소 |
| flash rf-v2+rf-v3 재측정 (job 98820) | $29.75 | 완주 — 별도 카드 참조 |
| sonnet p1 81/100편 (job 99206) | ≈$45 | 81편 지점에서 강제 종료 |
| 합계 | ≈$92+ | 한도 도달 |
00:02 UTC 8/28 프로브에서도 여전히 429가 반환돼, 정산 경계가 UTC 자정이 아님을 확인했다. 10분 간격 프로브(Monitor)로 해제 시각을 측정 중이다. 체크포인트 81편은 신 코드 기준으로 유효하므로, 한도 해제 즉시 같은 명령으로 재제출해 나머지 19편(≈$11)만 계산하면 된다.
두 사고 모두 실험 결과 자체보다 eval 파이프라인 신뢰성에 대한 교훈이다. (1) 체크포인트 재사용은 반복 실행 비용을 아끼는 데는 유용하지만, 버전 검증 없이는 "빠르게 끝난 것처럼 보이는 오염"을 자동으로 만들어낸다 — 오늘처럼 사용자가 우연히 이상 속도를 포착하지 못했다면 구 프롬프트 결과가 신 결과에 섞여 들어갈 뻔했다. (2) "$100/일" 게이트웨이 캡은 성공한 호출만 누적되는 게 아니라 실패·취소된 실행도 포함한다 — 재측정 계획을 세울 때 성공 예상 비용만 합산하면 실제로는 초과하기 쉽다.
체크포인트 파일에 prompt_version·strategies 지문을 넣고 불일치 시 자동 무시하는 방어 로직은
아직 구현되지 않았다 — 이번엔 사용자가 수동으로 포착했지만, 다음 프롬프트/청킹 변경 때 같은 실수가 재발할 수 있음.
게이트웨이 COST 한도의 정확한 해제 시각(정산 경계)도 아직 확정되지 않아 다음날 새벽 작업 스케줄링에 여유가 필요.
COST 한도 해제 확인 즉시 sonnet p1 잔여 19편(≈$11) 재제출. 체크포인트 버전 지문 검증 로직을 러너에 추가(우선순위 중).
향후 하루 실험 계획 상한을 $80 이하로 재조정하고, 게이트웨이 데일리 캡 정보를 letsur-gateway-daily-cost-cap 메모리에 기록해 재계획 시 참조.