할일 줄 끝에 `model:haiku` 같은 걸 달아 둔 적이 있다. second 레포 todo에는 실제로 이런 줄이 남아 있다.
- [x] **Agent model:haiku 검증** — docs/에 `haiku-test.md` 파일 생성, 내용: "실행 모델: haiku". `auto` `model:haiku`파일 하나 만들고 문자열 넣는 일에 비싼 모델을 쓸 이유가 없다. 반대로 설계·본문 품질이 중요한 일은 등급을 올린다. 한 모델로 전부 돌리지 않는 기준은 예전에 정리해 둔 그대로다. 이 단계가 틀리면 고치는 데 한 줄인가, 전체 재작성인가.
스킬 frontmatter에 모델을 박는 이야기는 토큰 절약 글 쪽에서 이미 다뤘다. 이 글은 그다음 축이다. 할일 단위로 모델을 동적으로 다는 쪽.
dispatch가 서브에이전트로 돌린다
/dispatch는 레포의 docs/todo.md에서 `auto` 태스크를 모아 실행한다. 오케스트레이터는 메인 세션이고, 실제 작업은 서브에이전트(또는 Claude 쪽이면 Workflow의 agent())에 넘긴다.
넘길 때 todo 줄의 있는 `model:fast|mid|strong|reason` 이 주입된다. 예전에 Claude 기준으로는 Agent(model: "haiku") 같은 호출이 모델 전환의 실체였다. Skill()로 다른 스킬을 중첩 호출하는 것만으로는 모델이 안 바뀌고, 컨텍스트 inject만 된다. 핀에 적힌 실패가 그거였다. 모델이 안 바뀌던 날.
지금은 프로필에 model_map이 있어서 등급을 벤더 ID로 바꾼다. Grok runtime이면 spawn_subagent 쪽에 같은 축이 붙어 있다. 발견 맥락은 Claude였고, 구조는 “할일 줄 태그 → 위임 호출 모델”이라 에이전트가 바뀌어도 같은 이야기다.
실전 감각은 이렇다.
| 재실행 비용 | 감각 | todo에 다는 예 |
|---|---|---|
| 낮음 (파일 생성·I/O·단순 검증) | 저가 | model:fast / 옛 haiku |
| 중간 (분류·경량 수정) | 중가 | model:mid / 옛 sonnet |
| 높음 (설계·초안 품질) | 고가 | model:strong / 옛 opus |
알뜰히 나누면 리셋 창 안에서 더 오래 버틴다. 스킬이랑 todo에 모델을 나눠 박아 둔 이유가 그거였다.
그래서 todo가 길어진다
서브에이전트는 부모 대화를 모른다. 메인 세션에서 티키타카로 합의한 내용이 자동으로 안 넘어간다. dispatch가 넘기는 건 대략 이거다.
- todo 한 줄 (목표·범위·태그)
- 항목 아래 상세 블록 (재현 문장, 금지, 파일 힌트)
- dossier (합격 기준·결정·검증)
문맥을 넣어 주려고 상세 블록이 길어진다. 처음엔 할일이 장황해 보였다. 지금은 그게 낭비처럼 안 보인다. 위임 프롬프트의 SSOT라서다. 짧게 쓰면 토큰은 줄지만, 받는 쪽이 백지라서 일처리를 못한다. 난이도만 보고 모델만 싸게 박아 두고 재현 문장을 빼먹으면 더 비싸다.
Todoist description에 적어 둔 것도 dispatch는 안 읽는다. 레포 todo.md에 없는 건 없는 거다.
주의점 전체(백지, 종료조건, 140턴)는 서브에이전트는 백지다에 따로 적었다. 이 글의 범위는 “모델을 어디에 박아서 토큰을 나누는가”와 “그래서 todo가 왜 길어지는가”까지다.
한 줄로
todo의 model: 태그는 장식이 아니다. dispatch가 서브에이전트를 띄울 때 쓰는 토큰 레버다. 스킬 쪽 모델 설정이 파이프라인 단계 성격이라면, todo 쪽은 할일 난이도 성격에 가깝다.
대신 위임할 문맥은 같은 줄과 상세 블록에 같이 실어야 한다. 길어 보이는 todo는 종종 설계다.