Как /goal в Claude Code потерял мне $200. Разбор и шаблон

11 мая 2026 года Anthropic выкатила команду /goal. Она запускает Claude Code в автономном режиме: ты пишешь условие выхода, агент крутится сам, пока не достигнет цели. Звучит как мечта - оставил на ночь, утром получил результат.

У одного разработчика на днях из vague-формулировки за 14 часов утекло $200. У другого, ещё в апреле, кэш-loop через cron сжёг $6 000 за ночь - просто потому что Anthropic тихо сменил cache TTL с часа на пять минут. Это весь weekly-лимит на Max-плане и больше половины зарплаты джуна.

Я три недели крутил /goal на своих проектах - в Piratix, в Aishka, в админке Смыслокода. Спалился на тех же граблях, что описаны в этой статье. Разбираю рабочий шаблон condition, 3 антипаттерна с цифрами и связку, при которой агент не теряет деньги ночью.

Если хочешь забрать одну вещь и закрыть вкладку - вот она. Apidog в своём гайде по /goal дал шаблон-формулу:

Подставляешь под свою задачу. Пример для миграции API:

Три части шаблона решают три проблемы:

Что сделать - даёт агенту понятную задачу. Без этой части evaluator не знает, что вообще проверять.

until + измеримое состояние - даёт evaluator'у конкретный сигнал «готово». «Когда станет хорошо» не сработает - нужен npm test с нулём падений в выводе. Текстом, в чате. Если ты не показал команду в транскрипте - evaluator скажет «not yet» бесконечно.

without + ограничения - страховка от того, что Claude «починит» тесты, удалив сами тесты. Без этой части агент может закомментить assertions и сказать, что задача выполнена.

Hard turn limit или стоп через N ходов обязателен. Это спасательный круг. Для лёгких задач - 15 ходов, для тяжёлых - 50, для overnight - максимум 100. Любую формулировку без turn limit считаешь сломанной по умолчанию.

Шаблон не идеальный, но он закрывает 80% типичных провалов. Дальше расскажу, что входит в оставшиеся 20%.

Антипаттерн 1 - vague condition без turn limit. Это та самая история с $200. Разработчик написал что-то в стиле «улучши код», ушёл спать. Evaluator каждый ход возвращал «not yet». Агент крутился 14 часов и потратил месячный лимит на одной строке. Никакого «улучшения» утром не оказалось - просто нет критерия «улучшено».

Findskill в своём разборе сформулировал жёстко: слабое condition, по которому evaluator всё время ставит «not yet», крутит 50, 100, 500 ходов, прежде чем ты заметишь. Расплачиваешься токенами и квотой.

Антипаттерн 2 - рекурсивный loop с broken caching. История MakeUseOf от 22 мая 2026. Разработчик не использовал /goal напрямую - он написал свой bash-скрипт ещё до релиза автономного режима. Cron-таск дёргал claude -p каждые 30 минут, между запусками кэш умирал. Anthropic незаметно сменил cache TTL с часа на 5 минут. Каждый запуск пересобирал 800 000 токенов истории с нуля. Запись свежих данных в кэш стоит сильно дороже, чем чтение из активного.

Утром - счёт на $6 000. Разработчик использовал инструмент ровно так, как Anthropic его рекламировал.

Логика та же самая может случиться с /goal, если запустить на 8 часов без supervision. Защита - три простых правила. Не запускай /goal дольше 4 часов без промежуточной проверки. Включи usage limits в Settings → Usage - это новая защита, которую Anthropic добавил после истории на $6 000. Открой claude agents дважды за ночь и сделай peek через Space - посмотри, что turn count не растёт быстрее ожиданий.

Антипаттерн 3 - креатив через /goal. Jason Croucher запустил /goal на сборку игры. Condition включало детерминизм, инварианты, проверку прохождения уровня. Игра собралась, тесты прошли, evaluator сказал «достигнуто». Визуала в игре не было - условие не упоминало графику.

Это иллюстрирует общее правило, которое Croucher вынес в свой field guide: evaluator оптимизирует ровно то, что ты измеряешь. Если в condition нет визуала - визуала не будет. Если в condition только «тесты проходят» - агент может закомментить сложные тесты и победить.

Защита от третьего антипаттерна простая. Для всего, что про вкус - дизайн, тексты, UX-полишинг, поиск инсайтов - /goal не используй. Возвращайся в обычную сессию или открывай Plan Mode, чтобы оставаться в петле решений. Сам режим разбирал отдельно - Plan Mode в Claude Code: гайд по сложным задачам.

Anthropic в документации описывает три обязательных элемента хорошего condition: измеримое конечное состояние, способ проверки, важные ограничения. Это формулировка для документации - в реальной работе нужны более конкретные правила.

Правило 1. Конечное состояние - проверяемое командой, не вкусом.

«Сделай красиво» крутится бесконечно. Рабочая формулировка - npm test exits 0. Для UX-задачи вместо «улучши UX» пишешь Lighthouse Performance score выше 90. Evaluator читает только транскрипт - он не запускает команды и не смотрит на скриншоты. Если результат нельзя зафиксировать текстом - evaluator никогда не скажет «да».

Правило 2. Constraints явные и узкие.

Без constraints Claude может починить тесты, удалив сами тесты. Может пройти миграцию, заменив getUser в директории, в которой её не должно быть. Прописывай without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Правило 3. Hard turn limit обязателен.

или стоп через N ходов в каждом condition без исключений. Это спасательный круг от бесконечного loop. Для лёгких задач 15, для тяжёлых 50, для overnight 100. Не оставляешь и не «уточнишь потом» - вписываешь сразу.

Правило 4. Описывай WHAT, не только HOW.

Это то правило, на котором сломался Croucher. Если ты не упомянул визуал в condition - Claude его не сделает. Если condition требует только «тесты проходят», агент может закомментить assertions. Описывай ЧТО ты хочешь видеть на выходе, а не только КАК проверишь.

Правило 5. Заставляй Claude выводить evidence в чат.

Evaluator не запускает команды. Он читает только то, что Claude уже вывел. Если condition требует «npm test зелёный», но Claude в транскрипте не показал вывод npm test - evaluator скажет «not yet» бесконечно. В condition добавляй фразу «show the output of these commands in the conversation» или по-русски «выведи результат команд в чат».

Пять рабочих condition, которые я обкатал на своих проектах. Бери, меняй имена директорий и команд, запускай.

Цифру 6 в четвёртом примере я ставлю не случайно - реалистичный потолок для одной ночи на Pro-плане. Boris Cherny из Anthropic в интервью Sequoia говорил, что у него «каждую ночь крутится тысячи агентов с телефона». Это правда - но это Cherny, у него Enterprise-доступ и команда сопровождения. Для смертных Pro ($20/мес) хватит на 1-2 параллельных сессии за ночь, не на десять.

Если /goal - это команда «работай, пока не закончишь», то Agent View - это панель, на которой видно все такие команды разом. Открывается одной строкой:

Откроется TUI-дашборд внутри терминала. Слева список сессий, справа peek-панель с последним сообщением активной строки.

У каждой сессии есть одно из шести состояний: Working - агент активно работает; Needs input - ждёт твой ответ на разрешение; Idle - сессия живёт, но ничего не делает; Completed - задача успешно закрыта; Failed - сессия закончилась с ошибкой; Stopped - ты сам остановил через Ctrl+X.

Шорткаты, которые я держу в голове, чтобы не лазить в документацию:

Запустить фоновую сессию можно двумя способами. Из интерактивной сессии Claude Code - команда /bg. Сразу из шелла - флаг --bg у claude:

Подключается фоновая сессия к Agent View автоматически.

Главная фишка Agent View, ради которой Anthropic это делал, - сессии переживают сон ноута и закрытие окна. Состояние сохраняется на диск, при пробуждении supervisor подключается к ним заново, а не считает паузу простоем. Но shutdown ноут или ручной reboot - и фоновые сессии в Failed. Все «тысячи агентов» работают на ноуте, который не выключают.

Worktrees решают главную проблему параллельной автономки: что, если две сессии одновременно пытаются править src/auth.ts? До 2.1.139 такие сессии буквально перетирали изменения друг друга. С Agent View Anthropic ввёл автоматическую изоляцию.

Каждая background-сессия, запущенная через /bg или claude --bg, стартует в твоей рабочей директории. Перед редактированием файлов Claude переносит её в изолированный git worktree в .claude/worktrees/. Параллельные сессии читают один и тот же checkout, но каждая пишет в свою копию.

Запустил три фоновые сессии:

Структура файлов после старта:

Каждая сессия работает в своей копии. Когда задача закончена, ты делаешь git merge нужных веток в main.

Главная опасность - удаление сессии удаляет worktree. Anthropic это явно описывает в документации: worktrees, созданные Claude, удаляются вместе с сессией в Agent View. Если ты в Agent View убил сессию Ctrl+X дважды - worktree исчез. Все uncommitted изменения пропали. Перед удалением сессии в Agent View всегда коммить или push.

Я на этом погорел один раз: открыл claude agents, увидел в списке сессию experiment-redis-cache, которую запускал три дня назад, решил «давно надо убрать». Ctrl+X дважды - и 4 часа экспериментов с конфигом улетели вместе с веткой. С тех пор у меня правило: прежде чем удалять сессию в Agent View, делаю git status в её worktree. Если есть uncommitted - сначала коммит, потом удаление.

Если у тебя репозиторий, где worktrees не работают (специфический setup с symlinks или большой monorepo с медленным checkout), есть опт-аут через .claude/settings.json:

Тогда фоновые сессии будут править твою рабочую копию напрямую. Этот опт-аут появился в 2.1.143 после жалоб от команд с большими monorepo. По умолчанию его не трогай - изоляция нужна.

Ещё одна цифра, которую полезно помнить: rate limits работают и для фоновых сессий. Background-сессии тратят квоту подписки так же, как интерактивные. 10 параллельных агентов сжигают квоту примерно в 10 раз быстрее, чем один. На Pro-плане ($20/мес) ты получишь 1-2 параллельных сессии за ночь, не больше. Хочешь стиль Cherny - нужен Max или Enterprise.

Это главная мысль, которую я вынес после трёх недель экспериментов. /goal - не универсальный inverter всех задач. Это узкий инструмент с жёсткими критериями применимости.

Croucher в своём field guide сформулировал правило выбора так: не используй /goal для задач, где «закончено» означает «выглядит хорошо», «ощущается правильно», «хорошо спроектировано» или «весело». Evaluator читает только транскрипт. Он не запускает инструменты, не смотрит на скриншоты, не оценивает, как работает результат на живых пользователях.

Это правило отсекает 80% субъективных задач, на которых /goal зацикливается без полезного выхода. Шесть типов задач, для которых я больше не запускаю /goal:

Где /goal реально работает - это задачи с verifiable end state. Миграции API, починка тестов, разбиение больших файлов, закрытие backlog issue, security audits. Правило выбора жёсткое: можешь ли описать «закончено» командой bash? Если да - подходит. Если нет - возвращайся в обычную сессию или Plan Mode.

Это противоречит маркетинговому посылу «автономный режим для всех задач». В реальности /goal - это финальное звено для механических задач, не серебряная пуля.

Типичный фейл - сразу написать /goal сделай новую фичу. Это не работает, потому что evaluator не знает, как выглядит «сделанная фича». Нужен план с чек-боксами, который evaluator сможет проверить пункт за пунктом.

Связка из трёх слоёв работает так.

Слой 1. Plan Mode пишет план с фазами. В Plan Mode ты просишь Claude составить детальный план изменений, разбитый на 5-7 фаз с проверяемыми чек-боксами. Сохраняешь как plans/2026-05-30-google-oauth.md. Каждая фаза - 3-7 чек-боксов с конкретными действиями. Я разбирал этот режим отдельно - там можно собирать план без интернета и без выжигания токенов на черновики.

Слой 2. Субагенты делят работу по фазам. Если план параллелизуется (фазы независимы - один сервис на сервере, форма в браузере, миграция БД), каждую фазу запускаешь в отдельной фоновой сессии через claude --bg --name "<phase>". Каждая сессия получит свой worktree. В этом случае Agent View начинает приносить реальную пользу - ты видишь три фазы параллельно в одном окне.

Слой 3. /goal крутит цикл до закрытия чек-боксов. Финальная команда выглядит так:

Evaluator после каждого хода читает план, проверяет, какие чек-боксы закрыты, и если что-то осталось - агент продолжает.

У меня это работает в Aishka на длинных рефакторингах - вечером Plan Mode пишет план разбиения большого сервиса, ночью три фоновые сессии в worktrees закрывают независимые фазы, утром я делаю git merge готовых веток. Один промпт - один цикл правок - без переключения между сессиями.

Без Plan Mode /goal бесполезен на сложных задачах. Evaluator должен знать, как выглядит «закончено» пункт за пунктом. План в plans/ отвечает на вопрос «что считать выполненным». Без CLAUDE.md /goal может предложить решение, ломающее архитектуру проекта. Без субагентов параллельных фаз не будет, всё последовательно.

Andrej Karpathy 19 мая 2026 ушёл в Anthropic в команду pre-training. До этого его подход к CLAUDE.md и автономным агентам, собранный в репозитории andrej-karpathy-skills на GitHub, набрал больше 150 000 звёзд. Один из его четырёх ключевых принципов работы с Claude называется Goal-Driven Execution - «определи критерии успеха, зацикливайся пока не проверено». Это ровно описание /goal.

Тот же принцип лежит в основе гайда по /goal и Agent View в Claude Code - там разбирал каждый компонент связки, версии 2.1.139-2.1.144 с патчами, и Karpathy-репо со всеми примерами.

Это то, что я держу под рукой и сверяю перед каждым запуском. Один пропущенный пункт может стоить тебе нескольких сотен долларов.

1. Версия Claude Code 2.1.139+. Проверь через claude --version, обнови если меньше. Минимально рекомендованная - 2.1.143 (15 мая 2026) с фиксом зацикливания stop hooks.

2. Condition содержит verifiable end state. Вместо «улучши» - npm test exits 0. Если ты не можешь придумать команду bash, которая проверит результат - /goal не для этой задачи.

3. Есть hard turn limit. В каждом condition прописано «или стоп через N ходов». Для лёгких задач 15, тяжёлых 50, overnight 100 максимум.

4. Constraints явные и узкие. without modifying files outside /auth, without removing existing assertions, without bumping major versions. Без них Claude может починить тесты, удалив сами тесты.

5. Все важные изменения закоммичены или запушены. Если ты работаешь не в worktree (выключил bgIsolation), Claude правит твою рабочую копию. Любая ошибка - теряешь несохранённое.

6. Включены usage limits в Settings → Usage. Это новая защита после истории на $6 000. Лимит на день, на сессию, на месяц. Включается одним кликом.

7. Открыт Agent View claude agents в отдельном окне. На длинных задачах заглядывай через peek (Space) раз в час. Если turn count растёт быстрее ожиданий или evaluator повторяет одну и ту же причину три хода - Ctrl+C и переформулировка.

Восьмой пункт, который добавил для себя лично: никогда не запускаю /goal с --dangerously-skip-permissions на чужом или незнакомом коде. Эта связка отключает любые проверки и даёт агенту делать всё что захочет в твоём проекте. Использую её только в свежем worktree, где терять нечего.

Если ты держишь дисциплину condition - /goal экономит реальное время на механической работе. Я в Aishka на рефакторинге одного из сервисов сэкономил 8 часов за выходные: вечером Plan Mode разложил, ночью три фоновые сессии закрыли по фазе, утром я сделал git merge. Без /goal это была бы неделя точечной работы.

Главный сдвиг 2026 года происходит не в умении Claude писать код - этот навык у него два года. Сдвиг происходит в другом: теперь критерий успеха можно описать командой bash, и инструмент сам обеспечит до неё дойти. Никакой магии - чистая инженерия. И как любая инженерия, она работает ровно настолько хорошо, насколько ты можешь сформулировать условие.

А у тебя на каком кейсе /goal уже сэкономил время - и где сжёг квоту впустую? Пиши в комментариях, разберём.

P.S. Источник истории про $6 000 - MakeUseOf, разбор инцидента 22 мая 2026 (makeuseof.com/someone-left-claude-code-running-overnight-and-it-cost-6000). История про $200 - findskill.ai. Я обкатывал шаблон на своих проектах три недели до публикации.