에이전트의 오버헤드와 캐싱은 효율성에 있어서 상당히 중요한 것 같습니다. 제가 만들고 있는 에이전트(https://github.com/kirinonakar/TxtAIEditor)는 모든 토큰을 투명하게 보이게 하고 있습니다. 오버헤드는 로컬 모델에서는 2k, 클라우드 모델에서는 tool catalog를 추가해서 4.2k로 하고 있고 skill, mcp는 필요할 때만 수동으로 추가할 수 있고 평소에는 격리됩니다. ComfyUI, browser/computer use 플러그인의 경우 2-3k 정도로 무시못할 크기이므로 쓰지 않을때는 격리하는 것이 경제적이라고 생각합니다. 물론 그렇게 하면 완전히 에이전트에 맞겨서 자동화하기는 어렵겠지만 저는 일단은 모든 것을 투명하게 볼 수 있고 경제적으로 통제할 수 있는 방향으로 하고 있습니다. 개인적으로 그런 에이전트를 하나쯤 가지고 있는 것도 나쁘지 않다고 생각합니다.

토큰을 정말 많이 태우는 건 하위 에이전트임. Claude Code에 큰 작업을 맡겼더니 곧바로 하위 에이전트 7개를 띄웠고, 하나도 끝나기 전에 예산을 소진함. 5시간 뒤 다시 시도해도 같았음
주 에이전트가 같은 작업을 순차적으로 수행하게 하면 전혀 문제없었음. 통신과 조율 비용 때문에 이렇게 비효율적인 건지, 아니면 하위 에이전트 사용자가 대개 대기업 계정으로 토큰당 비용을 내므로 Anthropic이 매출을 늘리려는 건지는 모르겠음

반대로 복잡한 프로젝트의 탐색·계획 단계에서는 Fable의 호기심 많은 동작이 정확히 필요할 수 있음. 조율 에이전트가 프롬프트를 여러 탐색 관점으로 나누는 데 그치지 않고, 각 하위 에이전트가 해당 관점으로 코드베이스를 조사하며 새 단서를 재귀적으로 확장하게 하려면 모든 단계에서 Fable을 쓰는 게 합리적임
반면 잘 계획된 작업을 여러 대상에 병렬 적용하려는 것이라면, 하위 에이전트가 호기심이 덜한 모델로 단계를 낮추도록 명시해야 함. 결과물의 일관성도 더 좋아질 수 있음

하위 에이전트마다 작업에 필요한 맥락을 얻으려고 코드베이스 일부를 다시 읽어야 함. 작업이 길어지면 조율 에이전트의 맥락도 캐시에서 사라져, 하위 에이전트가 끝난 뒤 다시 전체 비용을 내게 됨
순차 실행하면 파일을 대략 한 번씩만 읽고 모든 요청이 동일한 접두사 캐시를 활용함

고객이 문제를 우회하려고 더 비싼 요금제를 택하게 된다면, 회사에는 그 문제를 고칠 부정적 유인이 생김. 해결책을 가진 엔지니어가 몇 명 있더라도 다수의 무관심, 일부의 방해, 때로는 관리 계층 어딘가의 적극적인 적대에 부딪힐 수 있음
이런 환경에서는 최상위 요금제에 새 기능을 먼저 넣고 비용을 회수한 뒤 하위 요금제로 내리거나, 경쟁사가 따라오기 어렵게 사다리를 걷어차는 전략이 최선일 수 있음

하위 에이전트마다 약 3만 토큰짜리 시스템 프롬프트를 동일하게 전송함. Fable/Opus를 쓰면 7개가 작업을 시작하기도 전에 5시간 사용 한도의 30%를 쉽게 소비함

이 요령을 익힌 뒤 Fable 하위 에이전트를 명시적으로 금지하고 있음. 어제 대규모 리팩터링 뒤 복잡한 코드를 검토하려고 먼저 검토 계획을 요청했더니, 첫 단계에서 Fable 에이전트 8개와 결과 검증용 1개를 제안해 승인함
그런데 검증 단계에서 Fable 검증 에이전트 41개를 띄우려 했음. 어떻게든 우회로를 찾아냄

Claude Code가 토큰을 많이 쓰는 건 Anthropic이 더 많은 돈을 벌고 사용자를 구독제로 몰아넣기 위해서라고 봄. 구독 권한을 다른 코딩 에이전트에서 쓰지 못하게 하는 정책도 이를 뒷받침함. 나는 pi를 사용함

Anthropic을 토큰 판매업자로 보고 나니 여러 결정이 이해되기 시작함. 사용자가 반발하거나 안전장치를 요구하지 않는 한, 자사 경로로 더 많은 토큰을 쓰게 할 이유를 계속 만들어냄

기업공개 관련 서류에 따르면 구독 매출은 약 5%로 매우 작다고 본 적이 있음. 다만 5%는 개인용 Claude 구독이고, Claude Code 구독 대부분은 기업 부문에 포함됐을 가능성이 큼 API·엔터프라이즈는 전체 매출의 7585%, 기업 구독은 약 1015%, 개인 구독은 약 5%임

오히려 반대 논리임. 구독자는 고정 월정액을 내므로 Anthropic에는 Claude Code가 토큰을 적게 쓰게 할 유인이 있음

반면 이런 동작은 정액 요금에 포함된 일반 구독자의 토큰 소비도 늘림. 악의라기보다 무능에 가까워 보임

PUSH_AX의 타당한 비유처럼, 이는 시공업체 A가 3만3천 달러를 요구하고 B가 7천 달러를 요구한 상황과 같아서 우리가 올바른 대상을 측정하고 있는지 따져봐야 함
이에 따라 글에 더 심층적인 작업, 정성적 결과 비교, 가능한 한 빠른 입력·출력 재현 자료를 추가할 예정임

Opus가 주석의 오타 하나를 고친 뒤 테스트와 린트 등 실행할 수 있는 모든 것을 돌리면 짜증남. 모든 테스트가 원래 통과했는지 선제적으로 확인하려고 현재 변경 사항부터 임시 보관하기도 함
규칙에 모든 변경을 테스트로 검증하라고 써둔 내 책임도 있지만, AI의 I를 그렇게 강조한다면 과일 샐러드에 토마토를 넣지 않을 정도의 판단력은 기대하게 됨

“Hey”나 “commit”처럼 모호한 프롬프트를 받으면 원하는 작업을 추론하려고 과거 대화와 다른 맥락을 뒤지느라 도구 호출이 늘어남. 더 명확한 프롬프트가 나음

커밋 정도는 LLM에 맡기지 않고 직접 할 수 있지 않나?

Claude를 6개월 사용한 뒤 최근 Codex로 전환함. Codex가 더 개방적이고 모델의 작업 과정을 따라가기 쉬우며, 승인 흐름의 사용자 경험도 더 좋음. 전반적으로 투명성이 높고, 전환 비용은 거의 0이었음
Claude가 2월 무렵부터 시스템 프롬프트를 포함해 더 불투명해진 건 마음에 들지 않으며, 3만3천 토큰은 지나치게 많아 보임

지금은 둘 다 쓰는데 사실상 서로 바꿔 써도 될 정도임. Codex가 오픈 소스이고 OpenAI가 구독 권한을 다른 에이전트에서 써도 된다고 명시한 점도 좋음
최근 OpenAI가 훨씬 소비자 친화적으로 바뀜

이런 미니멀리즘과 관련이 있을 수 있지만, Pi에는 LLM이 효율적이고 효과적으로 작동하는 데 필요한 도구가 대부분 빠져 있음. 빈 바탕에 원하는 것을 추가하는 철학은 이해하지만, 내 기준에는 지나치게 비어 있음

시스템 프롬프트를 호출할 때마다 날짜와 cmd를 설정하면 캐시가 무효화되는지 궁금함
날짜나 루트 디렉터리가 바뀔 때만 무효화된다면 실제로는 충분히 드문 일이긴 함

대폭 맞춤화할 최소 에이전트가 필요하다면, “최소” pi-coder 패키지에 전이 의존성 130개 이상을 끌어오기보다 직접 만드는 편이 나음. 어렵지 않고 많이 배울 수 있으며, 시작 단계는 다른 LLM에 도움을 요청해도 됨

결국 중요한 건 원시 프롬프트 크기가 아님. 그렇다면 Pi와 그 변형들이 비용이 가장 낮아야 함. 핵심은 프롬프트의 효율성이며, 프롬프트 미니멀리즘과 효율성은 자주 혼동됨. 그래도 Claude Code는 하는 일에 비해 비대해 보임
그보다 더 중요한 건 도구의 품질임. 나쁘거나 버그가 있는 도구는 왕복 호출을 크게 늘려, 초기에 아끼려던 이점을 모두 지워버림
몇 달 전 8개 작업에서 에이전트 7개를 전체 벤치마크했으며, https://github.com/dirac-run/dirac에 데이터와 추적 기록이 있음. 그중 하나와 직접 연관돼 있어 중립성을 주장할 수는 없지만 재현 가능한 자료임. 작업 대부분이 리팩터링과 관련돼 있어 해시 앵커링과 추상 구문 트리 분석이 강점을 보이는 Dirac이 큰 차이로 이김

경쟁자가 많고 경쟁이 매우 치열하므로 개선 여지가 있다면 누군가 실현할 것이고, 이후 다른 제품에도 빠르게 확산될 가능성이 큼

직장에서 Claude Code를 강제로 써야 하지만 --system-prompt ""를 사용하면 간단히 해결됨. 다른 실행 환경도 허용해 주면 좋겠음

--system-prompt ""로 비우면 모델이 사용 가능한 도구를 이해할 기본 시스템 프롬프트조차 없어지는 것 아닌가?

오래전부터 이렇게 사용해 왔는데 왜 모두가 쓰지 않는지 모르겠음

이 옵션을 몰랐음. 적용 전후의 실제 효율을 분석한 자료나 현실 사용 환경의 성능 차트가 있다면 보고 싶음

이 옵션으로 Claude를 시작하는 건지, 아니면 프롬프트를 보낼 때마다 함께 전달하는 건지 궁금함

로컬 모델을 처음 실험할 때 Claude Code에 연결하니 매우 잘 작동했지만 속도가 느렸음
Claude의 도움을 받아 mitmproxy를 설정하고 Claude Code의 최초 시스템 프롬프트 전체를 캡처했더니, 재확인 결과 JSON 162KB였음. 이를 계기로 Pi, OpenCode, Hermes를 실험하기 시작함

지금 Claude Code의 새 세션에서 /context를 실행하면 Opus 4.8의 100만 토큰 맥락 중 2만3천 토큰만 사용함. 시스템 프롬프트 3.9천, 시스템 도구 13.9천, 사용자 정의 에이전트 235, 메모리 파일 28, 기능 4.9천, 메시지 8, 압축 버퍼 3천 토큰으로 표시됨 시스템 프롬프트 4천 토큰은 약 15~20KB임. 캡처한 내용을 Gist에 올려달라고 하고 싶지만 민감한 데이터가 있을 수 있고, 보이는 162KB가 시스템 프롬프트만은 아닐 가능성이 큼