개요
Codex에서 저렴한 모델(Luna)을 서브에이전트로 붙이는 구성이 오히려 비싸다는 커뮤니티 비교가 나왔다. 핵심은 서브에이전트 자체 비용이 아니라, Astra가 서브에이전트 상태를 확인하면서 소모하는 Astra 입력 토큰이다. 같은 주제의 7연쓰레드(@glitter_ai_factory)가 Astra=팀장·Luna=실무자 운용 패턴과 완화 규칙까지 제시한다.
게시물 요지
- @appcast: Luna를 서브에이전트로 붙이면 겉보기엔 저렴하지만 실제 측정에서는 Astra 토큰 소모가 크게 늘어난다는 비교 데이터(X @0x3_dev 인용)를 소개한다. 싼 모델을 섞는다고 비용이 무조건 줄지 않으며, 오케스트레이션 구조에 따라 고성능 모델 사용량이 오히려 는다는 주장이다.
- @glitter_ai_factory 2/7: Reddit 화제 사례로, Astra 밑에 Luna 워커를 붙였더니 Astra가 “Luna 끝났나?” 확인 과정에서 context를 반복 읽기했고, Astra 입력 토큰의 상당 부분이 실제 작업이 아닌 상태 확인에서 발생했다고 전한다.
- 완화 규칙(3/7): “작업 끝날 때까지 불필요하게 상태 확인하지 말 것”, “결과는 핵심 변경사항만 반환”처럼 중간 대화를 Astra에 올리지 않는 구조가 중요하다.
- 권장 배치(4–6/7): Astra는 처음(문제 정의·전략·설계)과 마지막(검토·의사결정)에만 쓰고, 중간 제작·반복 수정·테스트는 Luna/Sol에 맡긴다. 값싼 모델이 먼저 인수인계 문서(파일 구조·구현·제약·문제점)를 만들어 Astra에 넘기면, Astra는 자료 탐색이 아니라 판단에 추론을 쓴다.
- @black_bear_dev: Sol High보다 Astra Low가 낫다는 주장과 함께 “모델 기준으론 Astra가 더 쓰지만 목표 완수 기준으론 Astra가 덜 쓴다”는 검수 기준을 덧붙인다.
반론과 한계
- @ryunsu.sung: Luna 토큰 소모량이 훨씬 높고 단가가 낮으므로 토큰수 합계 비교는 무의미하다는 반론.
- @iminu5323: 같은 테스트에서 비슷한 결과가 나왔으나 “클로드로 오케스트라를 하면 좀 다른 결과가 나온다”고 밝혀 하네스 의존성을 시사.
- @larrabee.kor: 토큰량이 아니라 비용으로 봐야 한다는 지적.
- 모두 커뮤니티 자가 측정으로, 동일 태스크·동일 측정 조건의 재현 가능한 벤치마크는 아니다. 수치 그래프 원문(X 게시물)은 이 노트에서 직접 검증하지 않았다.
관련 위키
검증
- Threads 저장 페이지와 개별 게시물 3건을 ego-browser로 2026-09-10에 직접 렌더링해 본문·댓글을 캡처했다.
- 원문은
raw/articles/2026-09-10-threads-astra-subagent-tokens.md에 보존했고 SHA-256을 기록했다.