저는 Gearbox라고 불리는 작은 Claude Code 라우팅 계층(routing layer)을 구축했습니다.
목표는 기본적으로 모든 요청을 비용이 많이 드는 모델로 보내는 것을 방지하는 것입니다. 각 서브에이전트(subagent) 위임은 해당 작업을 처리할 수 있는 가장 저렴한 모델 티어(tier)로 라우팅됩니다.
의도된 계층 구조는 다음과 같습니다:

scout → Haiku, 읽기 전용 탐색
grunt → Haiku, 단순한 기계적 편집, 로직 변경 없음
builder → Sonnet, 범위가 지정된 구현
architect → Opus, 어려운 추론 및 디버깅
verifier → 결과가 수락되기 전 차이점(diffs) 확인

저는 6월 12일부터 6월 25일까지 13일 동안 제 실제 프로젝트에 이를 실행했습니다.
실제 사용 현황:

155회의 위임(delegations)
8개의 프로젝트
23개의 세션

모델 분할:

Haiku: 48회 위임, 31.0%
Sonnet: 77회 위임, 49.7%
Opus: 9회 위임, 5.8%
모델 미기록: 21회 위임, 13.5%

따라서 표면적으로는 라우팅이 꽤 잘 작동했습니다.
전체 작업의 약 1/3이 Haiku로 전달되었고, Opus는 6% 미만으로 유지되었습니다.
하지만 현재 버전에는 꽤 큰 결함이 있습니다.
위임의 48.4%만이 지정된 Gearbox 티어 에이전트(tier agents)로 전달되었습니다.
나머지 51.6%는 일반 범용 에이전트(generic general-purpose agent) 또는 내장된 Explore 프록시(proxy)로 전달되었습니다.
이것이 중요한 이유는 안전 규칙(safety rules)이 지정된 에이전트 파일 내에 있기 때문입니다. 작업이 일반 에이전트로 전달되면, 반드시 읽기 전용 scout 규칙이나 grunt 제한 사항, 또는 예상된 verifier 경로를 따르는 것은 아닙니다.
따라서 실제 결론은 다음과 같습니다:

"Gearbox가 모델 라우팅 문제를 해결했다."
가 아니라,

"Gearbox가 이미 비용이 많이 드는 모델 사용량을 줄이고 있지만, 트래픽의 절반은 여전히 의도된 티어 계층을 벗어나고 있다."
입니다.
짜증 나는 부분은 아직 그 이유를 증명할 수 없다는 점입니다.
다음 중 하나일 수 있습니다:

지정된 에이전트를 사용할 수 없을 때 나의 폴백 경로(fallback path)가 작동함
Claude Code가 스스로 일반 에이전트를 선택함
위임(delegations)을 기록하는 방식에서 메타데이터가 누락됨
이 세 가지가 모두 혼합됨

현재 로그는 라우팅 결정(routing decision)은 기록하지만, 그 결과(outcome)에 대해서는 충분히 기록하지 못하고 있습니다.

따라서 v0.2에는 다음 항목들이 추가되어야 합니다:

fallback reason (폴백 이유)
selected agent (선택된 에이전트)
intended agent (의도된 에이전트)
escalation event (에스컬레이션 이벤트)
verifier verdict (검증기 판정)
whether the diff was accepted or rejected (diff 수락 또는 거부 여부)

분석기(analyzer)는 다음 리포지토리(repo)에 포함되어 있습니다:
bench/analyze-log.py
이 도구는 사용자의 gearbox-log.jsonl 파일을 읽어 결과를 출력하기 전에 어설션(assertions)을 통해 독립적인 재집계를 수행합니다.
리포지토리: github.com/Adityaraj0421/gearbox

다른 분들은 Claude Code의 서브에이전트 라우팅(subagent routing)을 어떻게 처리하고 계신지 궁금합니다. 오케스트레이터(orchestrator)가 에이전트를 자유롭게 선택하도록 두시나요, 아니면 지정된 에이전트를 더 엄격하게 강제하시나요?
submitted by /u/Known-Delay-9689
[link] [comments]