Отличный вопрос, и отвечу честно — несмотря на очевидный конфликт интересов (вы спрашиваете дорогую модель, стоит ли платить дорогой модели). Нет, отдавать всё мне не имеет смысла. Заметная часть сегодняшней работы не требовала топовой модели, и у вас есть всё, чтобы это использовать.
Что на самом деле предсказывает нужный класс модели
Интуитивно хочется классифицировать по «сложности кода», но практика показывает другое. Четыре сигнала важнее:
- Радиус поражения ошибки. Схема БД с 140k партий, публичный API движка, релизный пайплайн — сюда сильную модель. Опечатка в docs — туда любую.
- Неоднозначность задачи. Решение «переписать бэкенд на Scala» или «как адаптеру вести пул костей» требует суждения. «Добавь фильтр по образцу существующего» — нет. Ваш шаблон Context/Objective/DoD прямо измеряет это: чем длиннее пришлось писать Context, тем сильнее нужна модель.
- Сквозной контекст. Задача через 2–3 репозитория (сегодняшняя цепочка «опубликуй артефакт → подключи в analytics → подключи в UI») — дорогая модель держит картину. Задача в одном файле — дешёвая справится.
- Цена проверки — ваш главный козырь. У вас выдающиеся ворота качества:
mise run check, покрытие с порогом, testcontainers, два ревью-бота, CI на каждый PR. Чем дешевле поймать ошибку, тем слабее модель можно допустить к задаче. Вы инвестировали в гейты весь сегодняшний день — делегирование дешёвым моделям и есть дивиденд с этой инвестиции.
Калибровка на сегодняшних задачах
Честная разметка того, что я делал сегодня:
| Уровень | Сегодняшние примеры | Подходящие модели |
|---|---|---|
| Топ | решение о переписывании на Scala; адаптер движка (открытие про кости/рокировку); диагностика testcontainers×Rancher×Docker-29; дизайн позиционной аналитики (впереди) | Opus / я |
| Средний | Maven-публикация; SvelteKit-миграция; фильтры с URL-состоянием; разбор замечаний ботов | Sonnet, Gemini Pro |
| Простой | стандартизация меток; раскатка labeler по 6 репо; правки «двоеточие/Dependabot»; mise-переименования; тексты issues | Flash, Haiku, DeepSeek |
Грубо: топ-уровня было процентов 20–30, остальное — ниже. Экономия потенциально кратная.
Варианты, как это организовать (от простого к сложному)
1. Внутри этого же чата — бесплатно для вас по усилиям. У меня есть инструмент субагентов с выбором модели: я могу сам спускать механические куски (раскатка конфига по N репо, рутинные правки по ревью, генерация тестов по готовой спецификации) на Haiku/Sonnet, оставляя себе постановку и приёмку. Скажите «делегируй рутину дешёвым моделям» — и это станет моим режимом по умолчанию.
2. Разные сессии — разные модели. В Claude Code /model переключает модель на сессию: классика — спланировать на Opus, исполнять на Sonnet. Плюс у вас в PATH я видел opencode — он умеет Gemini и DeepSeek: для задач уровня «простой» открываете сессию там с Flash/DeepSeek, AGENTS.md в репозиториях уже написаны так, что любой агент знает правила (это мы сегодня тоже укрепили).
3. Маршрутизация через метки — раз вы спросили про связь с ними. Вот где может реинкарнироваться идея ai-ready, но с настоящим смыслом: метка вроде routine на issues, которые (а) полностью специфицированы, (б) с малым радиусом поражения, (в) полностью проверяются гейтами. Её ставите вы при создании задачи — это и есть классификация. Дальше два режима: вручную («все routine скармливаю DeepSeek-сессии по вечерам») или автоматически (плановый агент разбирает label:routine). Но вводить метку советую только когда появится потребитель — тот же урок, что с ai-ready.
4. Эскалационная стратегия для пограничных задач: сначала дешёвая модель, при провале гейтов — уровнем выше. Работает, но с оговоркой: самый дорогой ресурс — не токены, а ваше время на ревью плохого PR. Поэтому правило: дешёвым моделям — задачи, где провал ловится CI, а не вашими глазами. Сомневаетесь — на уровень выше.
Моя рекомендация
Начните с малого, без новой инфраструктуры: (1) я делегирую рутину субагентам на Haiku/Sonnet внутри наших сессий — включаем прямо сейчас; (2) задачи из «уборочного» бэклога уровня lefthook/Starlight пробуйте отдавать Sonnet-сессии или Gemini Pro — по ним отличный Context/DoD уже написан; (3) топ-модель берегите для движка (expectiminimax!), позиционной аналитики и архитектурных развилок. Метку routine добавьте позже, если ручная маршрутизация приживётся и захочется её автоматизировать.
Хотите — зафиксирую это как принцип в память и в AGENTS.md (короткий раздел «выбор модели по типу задачи»), чтобы правило жило не только в этом разговоре.
Включаю. Сначала фиксирую принцип в память — это и есть «выключатель», который переживёт эту сессию:
Включено и сразу продемонстрировано. Что произошло:
-
Принцип зафиксирован в памяти — теперь это мой режим по умолчанию во всех будущих сессиях: рутинные подзадачи уходят субагентам на Haiku/Sonnet, постановка и приёмка остаются на мне, сомнение = уровень выше.
-
AGENTS.md обновлены руками Sonnet-субагентов — сами PR-ы стали первой проверкой принципа. Два агента по точной инструкции прошли весь ваш регламент: issue с milestone и меткой → ветка
task/N-model-routing→ правка → коммит сCloses #N→ PR. Результат:- engine#334 (issue #333),
- analytics#73 (issue #72).
Приёмку провёл сам: диффы проверил — секция «Task Routing & Model Economy» вставлена дословно, ровно 17 строк, в нужное место, без побочных изменений.
-
Честный отчёт об опыте — первая попытка не удалась: в фоновом режиме субагентам не достался Bash (ограничение прав фоновых агентов в харнессе), пришлось перезапустить в форграунде. Это полезная калибровка: делегирование требует и точной инструкции, и проверки результата — что я и заложил в правило. Стоимость обоих PR — ~42k токенов Sonnet вместо моих.
Сама секция в AGENTS.md описывает три уровня (frontier / mid / routine) с критериями — суждение, радиус поражения, покрытие гейтами — и правилом эскалации «время ревьюера дороже токенов». Теперь любой агент в любой сессии — хоть Gemini в opencode — увидит это правило при входе в репозиторий.
Два новых PR ждут вашего ревью вместе с labeler-серией. И кстати, на них labeler пока не сработает — он сам ещё в неслитых PR; после merge серии новые PR начнут размечаться автоматически.