Claude Code는 프롬프트를 읽기 전 3.3만 토큰, OpenCode는 7천 토큰을 전송함

 (systima.ai)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 동일한 모델·머신·작업에서 API 경계를 측정한 결과, Sonnet 4.5 첫 요청의 고정 오버헤드는 Claude Code 약 32,800토큰, OpenCode 약 6,900토큰으로 4.7배 차이 났으며 Fable 5에서는 약 3.3배로 줄어듦
  • 격차의 대부분은 도구 스키마에서 발생함. Claude Code는 27개 도구 정의에 약 24,000토큰, OpenCode는 10개 도구에 약 4,800토큰을 사용했고, 도구를 모두 꺼도 시스템 프롬프트가 각각 약 6,500토큰과 2,000토큰이었음
  • 실제 설정에서는 72KB 명령 파일이 요청마다 약 20,000토큰, 소형 MCP 서버 하나가 약 1,000~1,400토큰을 추가해 첫 요청만 75,000~90,817토큰에 이를 수 있음
  • Claude Code는 동일한 파일 요약 작업에서 OpenCode보다 캐시 쓰기를 5.9~54배 많이 발생시켰고, 두 하위 에이전트로 작업을 분산하자 직접 실행 시 121,000토큰이던 사용량이 513,000토큰으로 4.2배 늘어남
  • 고정 오버헤드만으로 전체 비용을 판단할 수는 없음. 다단계 작업에서는 Claude Code가 도구 호출을 병렬 배치해 3회 요청으로 약 121,000토큰을 쓴 반면, OpenCode는 직렬 호출 9회로 약 132,000토큰을 사용함

API 경계에서 측정한 방법

  • Claude Code와 OpenCode 사이에 로깅 프록시를 배치해 하네스가 보낸 정확한 JSON 요청과 API가 반환한 사용량 블록을 기록함
    • 요청 본문에는 시스템 블록, 도구 스키마, 메시지가 포함됨
    • 사용량에는 입력 토큰, 캐시 쓰기·읽기, 출력 토큰이 포함됨
    • 캡처한 요청 본문은 실제 전송 내용, API 사용량 블록은 실제 과금량의 기준으로 사용함
  • 기본 비교에는 Claude Code 2.1.207과 OpenCode 1.17.18을 사용하고, 둘 다 2026년 7월 기준 claude-sonnet-4-5에 고정함
    • 고정 오버헤드, 캐시 작업, 다단계 작업의 일부는 claude-fable-5로 다시 실행함
    • 새 설정 디렉터리, MCP 서버·사용자 설정·메모리가 없는 상태, 명령 파일이 없는 빈 작업 공간에서 기본값을 격리함
  • 세 가지 작업으로 서로 다른 비용 구조를 측정함
    • T1은 Reply with exactly: OK로 고정 오버헤드를 분리했으며 하네스마다 3회 실행함
    • T2는 미리 준비한 파일을 읽고 요약하게 함
    • T3는 FizzBuzz와 검사 스크립트를 대상으로 작성·실행·테스트·수정 절차를 수행함
  • 도구 스키마를 제외한 시스템 프롬프트를 비교하기 위해 Claude Code에는 --tools "", OpenCode에는 "tools": {"*": false}를 적용함
  • 로컬 LLM 게이트웨이가 요청마다 약 6,200토큰의 고정 봉투를 추가해 이를 보정한 뒤 계측값에서 제외함
    • 구성요소별 수치는 게이트웨이가 바꿀 수 없는 캡처 요청 본문에서 계산함
    • 문자·토큰 변환에는 콜드 캐시 기준으로 측정한 하네스별 4.1~4.4자당 1토큰 비율을 사용함

기본 오버헤드를 키우는 도구 스키마

  • 22자짜리 T1 프롬프트의 첫 요청에서 Claude Code는 약 32,800토큰, OpenCode는 약 6,900토큰을 전송함
    • Claude Code 시스템 프롬프트는 3개 블록, 27,344자였고 OpenCode는 1개 블록, 9,324자였음
    • Claude Code의 27개 도구 스키마는 99,778자, OpenCode의 10개 도구는 20,856자였음
    • Claude Code는 실제 프롬프트 앞에 에이전트 유형, 사용 가능한 스킬, 사용자 컨텍스트를 담은 <system-reminder> 블록 7,997자를 삽입함
    • OpenCode는 별도의 첫 메시지 스캐폴딩 없이 시스템 블록, 10개 코딩 도구, 사용자 프롬프트를 보냄
  • 양쪽 모두 도구 정의가 가장 큰 비중을 차지함
    • Claude Code의 약 33,000토큰 중 약 24,000토큰이 도구 정의임
    • OpenCode의 약 6,900토큰 중 약 4,800토큰이 도구 정의임
    • Claude Code 도구에는 코딩 기능뿐 아니라 CronCreate, Monitor, Task 계열, 작업 트리 관리, 푸시 알림 등 백그라운드 에이전트·오케스트레이션 기능이 포함됨
  • 도구를 전부 제거하면 Claude Code 시스템 프롬프트는 26,891자, 약 6,500토큰이고 OpenCode는 8,811자, 약 2,000토큰임
    • 두 하네스 모두 도구가 비활성화되면 프롬프트가 조금 줄어듦
    • 남은 차이는 어조, 안전 지침, 작업 관리 규칙, 환경 정보 등 행동 지침에서 발생함
  • Fable 5에서는 Claude Code가 모델에 따라 프롬프트를 줄여 격차가 약 3.3배로 축소됨
    • 시스템 지침은 Sonnet의 27,787자에서 Fable의 10,526자로 감소함
    • 같은 27개 도구를 유지하면서 스키마도 99,778자에서 82,283자로 줄어듦
    • OpenCode 요청은 두 모델에서 바이트 단위로 동일했음

작업 형태에 따라 달라지는 전체 사용량

  • 파일 하나를 읽고 요약한 T2에서는 두 하네스 모두 정확한 결과를 냈지만 요청 구조가 달랐음
    • Claude Code는 HTTP 요청 6회와 누적 입력 약 199,000토큰을 사용함
    • OpenCode는 요청 4회와 약 41,000토큰을 사용하고 세션 제목 생성을 위한 Haiku 호출 1회를 추가함
    • 사용량 대부분은 입력 가격의 10분의 1로 과금되는 캐시 읽기였음
  • 캐시 할인이 있어도 첫 요청의 캐시 쓰기, 매 턴의 캐시 읽기, 컨텍스트 창 점유는 페이로드 크기에 따라 증가함
    • 33,000토큰 기준선은 코드가 들어오기 전부터 200,000토큰 창의 약 6분의 1을 차지함
  • 작성·실행·테스트·수정 작업인 T3에서는 도구 호출 방식이 기본 오버헤드 차이를 상쇄함
    • Claude Code는 파일 쓰기 2회와 스크립트 실행 2회를 하나의 병렬 도구 왕복으로 배치해 모델 요청 3회, 누적 입력 약 121,000토큰을 기록함
    • OpenCode는 턴마다 도구 하나만 호출해 9회 요청과 제목 호출 1회, 누적 입력 약 132,000토큰을 기록함
    • 전체 입력은 대략 요청당 기준선과 요청 횟수의 곱에 대화 증가분을 더한 값으로 결정됨
  • 대화가 진행되면서 Claude Code는 <system-reminder>를 첫 턴의 3개에서 첫 도구 왕복 시점의 4개로 늘림
  • OpenCode의 턴별 추가 페이로드는 약 400~2,200자로, 대화 내용만 증가함

실제 설정이 추가하는 토큰

  • 프로덕션 저장소의 72KB AGENTS.md를 추가하자 두 하네스 모두 요청마다 20,000토큰 이상 증가함
    • OpenCode 계측값은 13,152토큰에서 33,336토큰으로 증가함
    • Claude Code는 39,005토큰에서 59,243토큰으로 늘어남
    • Claude Code 2.1.207은 AGENTS.md를 무시했으며, CLAUDE.md로 이름을 바꿔야 첫 사용자 메시지에 삽입함
    • OpenCode는 두 파일명을 모두 읽어 시스템 프롬프트에 삽입함
    • 하네스가 실제로 인식하는 파일명을 확인하지 않으면 명령 파일이 조용히 무시될 수 있음
  • 공개형 소형 MCP 서버는 서버 하나당 요청마다 약 1,000~1,400토큰을 추가함
    • 서버 5개는 Claude Code 페이로드에 4,900토큰, OpenCode 계측값에 6,967토큰을 더함
    • 도구 수는 Claude Code에서 27개에서 69개, OpenCode에서 10개에서 52개로 늘어남
    • 풍부한 API를 가진 프로덕션 서버는 더 큰 스키마를 보낼 수 있음
    • Claude Code의 print 모드는 명시적인 --mcp-config가 없으면 프로젝트 범위 .mcp.json을 조용히 무시했으므로 API 경계에서 연결 여부를 확인해야 함
  • BMAD 같은 스토리 기반 워크플로 프레임워크는 페르소나·프로토콜·체크리스트를 담은 큰 템플릿을 슬래시 명령으로 확장함
    • 실험의 8,405자 템플릿 자체는 약 2,100토큰이지만 대화 기록에 들어가 이후 모든 요청에서 다시 전송됨
    • 요청 9회인 세션에서는 같은 템플릿이 9회 실리므로 비용은 템플릿 크기 × 요청 수로 증가함
  • 실제 구성의 첫 요청은 기본 오버헤드보다 훨씬 커졌음
    • OpenCode는 이메일·캘린더, 작업 관리, 참고문헌 관리, 제품 분석 등을 위한 MCP 서버 11개와 72KB 명령 파일을 사용해 179개 도구와 277KB 스키마, 콜드 캐시 쓰기 90,817토큰을 기록함
    • Claude Code는 MCP 서버 4개, 설치된 플러그인, 같은 명령 파일로 118개 도구와 311KB 페이로드, 약 75,000토큰을 기록함
    • OpenCode 구성은 게이트웨이 봉투를 제외하면 약 7,000토큰인 기본값의 약 12배였음

하위 에이전트와 확장 사고의 비용

  • Claude Code가 작업을 두 하위 에이전트에 병렬 분산하자 직접 실행의 121,000토큰이 513,000토큰으로 늘어 4.2배가 됨
    • 주 세션, 하위 에이전트 호출 등 세 가지 요청 유형에서 총 9회의 모델 요청이 발생함
    • 하위 에이전트 호출 5회는 각각 3,554자 시스템 프롬프트와 기본 27개 중 24개 도구로 자체 부트스트랩함
    • 각 하위 에이전트가 초기 비용을 부담하고 그 실행 기록을 부모가 다시 읽는 구조임
  • OpenCode 하위 에이전트는 1,379자 시스템 프롬프트와 도구 5개만 사용하는 축소 프로필을 전송함
    • 게이트웨이를 통한 실행이 정상 완료되지 않아 OpenCode의 전체 하위 에이전트 사용량은 수치화하지 않음
    • 캡처한 페이로드에서 확인된 설계 차이만 비교함
  • 확장 사고 출력은 입력 단가의 5배인 출력 단가로 과금되며, 추론 블록이 대화 기록에 포함돼 이후 요청에서 다시 전송됨
    • 게이트웨이 자체 사고 정책 때문에 두 하네스의 설정이 실제로 적용됐는지 확인할 수 없어 측정 수치는 공개하지 않음
    • 추론 블록이 기록에 합류하는 비용 구조만 확인 대상으로 남김

프롬프트 캐시의 경제성과 안정성

  • 두 하네스 모두 캐시 중단점을 올바르게 설정함. 페이로드는 5분 TTL 기준 기본 입력 가격의 1.25배로 한 번 쓰이고 이후 10분의 1 가격으로 읽힘
  • 캐시로 줄지 않는 비용은 세 가지임
    • 5분 이상 중단되면 전체 스택을 다시 써야 하므로 회의나 식사 같은 휴지 뒤에는 쓰기 비용이 재발함
    • 캐시 읽기도 요청 횟수만큼 반복되므로 직렬 도구 루프와 하위 에이전트 분산이 비용을 늘림
    • 컨텍스트 창 점유는 캐시 할인의 영향을 받지 않아 85,000토큰 부트스트랩이 200,000토큰 창의 40% 이상을 차지하고, 압축이 시작되면 요약 비용도 추가됨
  • OpenCode는 캡처한 모든 요청과 실행에서 바이트 단위로 동일한 접두부를 유지함
    • 세 번의 T1 세션에서 도구, 시스템, 메시지 바이트가 동일했고 반복 실행의 캐시 쓰기는 0이었음
    • 9개 요청으로 구성된 T3 세션도 하나의 안정된 접두부를 유지함
  • Claude Code는 세션마다 워밍업 탐색, 주 대화, 하위 에이전트 호출이라는 서로 다른 요청 유형과 캐시 항목을 만듦
    • 같은 작업 공간에서도 시스템 바이트와 첫 메시지 스캐폴딩이 실행별로 달라짐
    • 동일한 파일 요약 작업에서 5개 요청에 걸쳐 53,839 캐시 토큰을 썼고, 약 43,000토큰 접두부 전체를 작업 중간에 한 번 다시 씀
    • OpenCode의 같은 작업 캐시 쓰기는 1,003토큰이었음
  • Claude Code의 대규모 중간 캐시 재쓰기는 반복 실험에서도 나타남
    • 첫 두 실행에서 각각 43,342토큰과 36,899토큰을 다시 썼고, 새로 예열한 캐시를 사용한 세 번째 실행에서는 거의 쓰지 않음
    • Fable 5에서도 캐시 읽기 없이 50,053토큰을 다시 써 Sonnet의 54배와 비슷한 52배 격차가 발생함
    • 캐시 온도에 따라 Claude Code의 캐시 쓰기량은 OpenCode의 5.9~54배였음
    • 캐시 쓰기 단가는 5분 계층에서 기본의 1.25배, 1시간 계층에서 2배임
  • 단일 캐시 누락은 게이트웨이의 축출 때문일 수도 있으나, 여러 실행에서 재현됐고 요청 전 캡처 바이트에서도 접두부 불안정성이 확인됨
    • 접두부가 크고 종류가 많으며 재쓰기가 반복되고 하위 에이전트까지 더해지면 Claude Code 사용량 계기판이 더 빠르게 증가할 수 있음

결과 품질과 감사 로그

  • 두 하네스는 평가 대상 작업을 모두 정확히 완료함
    • 파일 요약 결과는 모두 정확했음
    • 다단계 작업은 각 하네스가 작성한 검증 스크립트를 통과하고 정상 종료함
    • 이 범위에서는 같은 결과를 얻는 데 필요한 토큰 비용 차이를 비교할 수 있었음
  • 더 어려운 실제 엔지니어링 작업에서 Claude Code의 백그라운드 에이전트, 스킬, 오케스트레이션이 추가 비용만큼 품질을 높이는지는 측정하지 않음
    • 이를 판단하려면 적절한 테스트 모음, 충분한 반복 실행, 통과율 평가가 별도로 필요함
  • 품질과 무관한 낭비도 확인됨
    • 바이트가 같은 캐시 접두부를 세션 중간에 다시 쓰는 것은 같은 내용을 프리미엄 가격으로 재구매하는 셈임
    • 하네스가 명령 파일을 조용히 무시하면 해당 파일에서 어떤 효용도 얻을 수 없음
  • 캡처한 요청·응답 185개 기록을 오픈소스 라이브러리 @systima/aiact-audit-log로 SHA-256 해시 체인에 기록함
    • 체인은 중단 없이 끝까지 검증됐으며 무결성 결과는 VALID였음
    • 같은 구조로 전송·응답 내용을 재구성하고 제3자에게 무결성 자료를 제공할 수 있음
    • 이는 EU AI Act Article 12 로깅에 제공되는 구조화 기록 방식과 동일함

측정의 한계와 재현 방법

  • 결과는 한 대의 머신, 두 하네스 버전, 작은 표본을 사용한 2026년 7월 스냅샷임
    • T1과 T2는 각각 3회, 각 구성 배수 조건은 1회 실행함
    • 기본값과 캐시 조건은 Sonnet 4.5와 Fable 5를 사용하고, 구성 배수 조건은 한 모델만 사용함
    • 하네스 프롬프트는 자주 바뀌므로 개별 수치보다 API 경계 측정 방법이 더 오래 유지됨
  • 로컬 게이트웨이가 측정 경로에 있었음
    • 구성요소 수치는 게이트웨이가 바꿀 수 없는 요청 본문을 사용함
    • 계측값은 콜드 캐시 기준점으로 고정 봉투를 보정했으며, 원인을 구분할 수 없는 웜 실행 수치는 제외함
    • 게이트웨이가 고정한 모델보다 새로운 스냅샷으로 조용히 교체한 사례가 있어 실제 응답 모델도 경계에서 확인해야 함
    • Fable 경로에서는 오래된 서버 세션 재개와 호스트 측 도구 실행이 발생해 Claude Code의 Fable 다단계 결과를 제외함
  • T3의 비용 수렴은 한 가지 작업 형태에서 나온 한 번의 관측임
    • 순차 실행이 필수인 작업에서는 Claude Code 요청 횟수와 전체 사용량이 다시 증가할 수 있음
    • OpenCode의 도구 제거 및 하위 에이전트 조건은 게이트웨이에서 잘못된 스트림을 반환해 캡처 페이로드 크기만 사용함
    • 실제 구성 수치는 한 사용자의 설정이며 다른 환경에서는 달라질 수 있음
  • 재현 장치는 약 200줄의 Node 코드로 구성된 HTTP 프록시임
    • 모델 엔드포인트로 요청을 전달하면서 요청 본문과 응답 사용량 블록을 디스크와 감사 체인에 기록함
    • ANTHROPIC_BASE_URL을 프록시로 지정하고 새 설정 디렉터리와 빈 작업 공간에서 기본값을 측정한 뒤 명령 파일, MCP 서버, 워크플로를 하나씩 추가함
    • 게이트웨이를 사용한다면 먼저 최소 요청으로 자체 봉투를 측정하고 실제로 어떤 모델이 응답하는지 확인해야 함
    • 프로덕션 에이전트가 특정 시점에 모델로 보낸 정확한 내용을 재구성할 수 있도록 API 경계 로깅을 갖추면 토큰 회계도 함께 확보할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 토큰을 정말 많이 태우는 건 하위 에이전트임. 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·엔터프라이즈는 전체 매출의 75~85%, 기업 구독은 약 10~15%, 개인 구독은 약 5%임
    • 오히려 반대 논리임. 구독자는 고정 월정액을 내므로 Anthropic에는 Claude Code가 토큰을 적게 쓰게 할 유인이 있음
    • 반면 이런 동작은 정액 요금에 포함된 일반 구독자의 토큰 소비도 늘림. 악의라기보다 무능에 가까워 보임

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

    • 3만3천 토큰 중 상당 부분이 최근 대화 같은 맥락 데이터인지 궁금함

  • 큰 시스템 프롬프트만의 문제가 아님. 코딩 에이전트 실행 환경도 사소한 요청에조차 도구를 더 공격적으로 사용하고 있음. 테스트에서는 “Hey”나 “commit” 같은 프롬프트가 때때로 30회가 넘는 도구 호출을 일으켰음
    https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
    간단한 작업이 소비하는 토큰 수가 계속 늘어나는 토큰 인플레이션은 실제로 보임

    • Opus가 주석의 오타 하나를 고친 뒤 테스트와 린트 등 실행할 수 있는 모든 것을 돌리면 짜증남. 모든 테스트가 원래 통과했는지 선제적으로 확인하려고 현재 변경 사항부터 임시 보관하기도 함
      규칙에 모든 변경을 테스트로 검증하라고 써둔 내 책임도 있지만, AI의 I를 그렇게 강조한다면 과일 샐러드에 토마토를 넣지 않을 정도의 판단력은 기대하게 됨
    • “Hey”나 “commit”처럼 모호한 프롬프트를 받으면 원하는 작업을 추론하려고 과거 대화와 다른 맥락을 뒤지느라 도구 호출이 늘어남. 더 명확한 프롬프트가 나음
    • 커밋 정도는 LLM에 맡기지 않고 직접 할 수 있지 않나?

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

    • 지금은 둘 다 쓰는데 사실상 서로 바꿔 써도 될 정도임. Codex가 오픈 소스이고 OpenAI가 구독 권한을 다른 에이전트에서 써도 된다고 명시한 점도 좋음
      최근 OpenAI가 훨씬 소비자 친화적으로 바뀜
    • 더 불투명해진 뒤 어떤 설정들을 시도했는지 궁금함. 지금은 설정 항목이 훨씬 많아짐

  • pi 에이전트는 시스템 프롬프트가 더 작으며, 전체 내용은 여기서 볼 수 있음
    https://github.com/earendil-works/pi/blob/main/packages%2Fco...

    • 이런 미니멀리즘과 관련이 있을 수 있지만, 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가 시스템 프롬프트만은 아닐 가능성이 큼

  • 내가 만든 것은 더 적게 전송함: https://maki.sh

    • 맥락이 너무 길어지면 maki가 이미지와 추론 블록을 제거하고 이전 대화를 요약해 기록을 자동 압축한다고 함
      하지만 이전 대화 요약은 사실상 맥락 캐시를 무효화해, 토큰은 덜 쓰더라도 더 비싼 토큰을 소비하게 되는 것 아닌가?
답변달기