사용량 제한에 대해 그만 좀 떠드세요. 워크플로우를 고치세요

무시하세요. 모든 개발자는 자기 프로젝트와 설정에 눈이 멀어 있어서, 프로젝트의 복잡도나 실력 차이 때문에 그 조언이 거의 안 먹히거든요.

어떤 모델을 쓰는지, 추론 수준은 어떤지, 프로젝트와 작업의 복잡도는 어느 정도인지, 그리고 단순히 '배포'에 대해 떠드는 게 아니라 실제로 얼마나 배포하고 있는지 말하지도 않으면서 이런 소리를 한다면 들을 가치도 없습니다.

프롬프트를 공개하지 않으면 다 시간 낭비일 뿐이죠.

여기서 숙련된 개발자라고 주장하던 사람이 프롬프트 하나로 사용량을 다 날려 먹었는데, 결국 공유하라고 압박하니 Fable 에이전트한테 '너 뭐 잘못한 거 없는지 확실해?'라고 물어본 게 드러났죠.

물론 이전 대화를 이어가는 중이라 캐시가 비어있긴 했지만, 그 사람은 이 프롬프트가 왜 문제인지, 에이전트가 모든 걸 읽고 확인하느라 토큰을 얼마나 태우게 될지 전혀 이해하지 못하더군요...

5 버전 모델들이 4.8 같은 모델보다 토큰을 더 많이 잡아먹는 것 같음. Fable을 쓰고 Sonnet 에이전트 여러 개로 구현하게 하는 게 토큰 엄청 아껴주고 잘 돌아가더라. 솔직히 Opus랑 Sonnet 구현 에이전트 조합도 괜찮긴 한데, 긴 작업 돌릴 때는 Fable이 Opus보다 막히는 부분 해결을 잘해서 밤새 긴 작업 돌려놓기 좋음.

문제 원인이 사용자 쪽에 있을 땐 도움이 될 수도 있겠지. 내 프로젝트는 이미 에이전트 및 작업 제어 기능이 있고, 에이전트 실행 시간이나 팬아웃 크기 제한 같은 것도 다 설정해 뒀음.

근데 그렇다고 해서 사용자가 어쩔 수 없는 사용량 버그가 존재한다는 사실이 바뀌진 않음. 이번 주에 있었던 캐시 버그 때문에 Fable 프롬프트 하나가 내 최대 계획 사용량 전체랑 주간 사용량의 20%를 잡아먹었음. 과거에도 사용량 관련 버그는 많았고.

대부분의 사용자가 사용량 제한 때문에 골머리 앓고 사용자 경험까지 망치고 있다면. 출처가 어디임? '대부분'의 Claude 사용자가 그런 경험을 하고 있다는 걸 증명하는 데이터가 있다면 보고 싶네.