Код-агент написал решение, запустил тесты и получил Wrong Answer. Следующий шаг обычно задан жёстко: повторить попытку дешёвой моделью или сразу вызвать более дорогую. При этом в системе уже есть полезная диагностика, включая тип ошибки и stderr.

Авторы CodeRescue предлагают выбирать действие после каждого неудачного запуска. Их роутер решает, стоит ли исправить текущий код, начать заново или передать задачу более сильной модели. Работа опубликована как arXiv:2607.19338, код доступен в репозитории проекта.

Почему обычного каскада мало

FrugalGPT, RouteLLM и AutoMix выбирают модель до генерации. Код-агент находится в другой ситуации: первая попытка уже выполнена, а среда вернула wrong answer, timeout, compile error или другой вердикт. Это новый сигнал, которого не было в исходном запросе.

CodeRescue называет такую постановку recovery routing. Роутер получает условие задачи, вердикт и трассу ошибки, после чего выбирает одно из трёх действий:

• reflect исправляет текущий код;
• replan начинает решение заново с другим планом;
• escalate передаёт задачу более сильной модели.

Дешёвое восстановление и эскалация решают разные подмножества задач. В эксперименте встречались случаи, где GPT-5.4-nano справлялась после reflect, а GPT-5.4 после прямой эскалации не находила решение. Было и обратное.

Как обучается роутер

Авторы собрали rollout'ы на APPS, TACO, BigCodeBench, LiveCodeBench и CodeContests. Для каждой неудачной первой попытки они проверяли доступные recovery actions. Меткой становилось самое дешёвое действие, которое всё же привело к правильному решению. Примеры, где не помог ни один вариант, не использовались для обучения.

Роутер работает как классификатор. Его вход содержит recovery context, а выходом служат вероятности reflect, replan и escalate. При использовании из оценки каждого действия вычитается стоимость, умноженная на коэффициент λ. Изменение λ даёт разные точки на кривой solve rate и cost без повторного обучения модели.

Prompt-only роутер видит только условие задачи. CodeRescue дополнительно получает результат исполнения, поэтому может отличить ошибку индекса от таймаута или неверной алгоритмической идеи.

Сколько стоили стратегии

В Table 1 средняя стоимость восстановления для пары GPT-5.4-nano и GPT-5.4 составила:

Стратегия	Стоимость на задачу
always-reflect	1,24 миллидоллара
always-replan	1,59 миллидоллара
always-escalate	7,22 миллидоллара
CRC argmax	5,51 миллидоллара

Точка CRC argmax обходилась в 76% цены always-escalate при сопоставимом solve rate. Для другой калиброванной точки авторы сообщают 35% средней стоимости восстановления при solve rate уровня always-escalate.

Разница между 7,22 и 5,51 миллидоллара невелика для одной задачи, но заметна в потоке. При тысяче восстановлений в день это около $1,71 экономии ежедневно, или примерно $51 в месяц. Реальный счёт зависит от длины запросов, цен моделей и доли неудачных первых попыток.

Какие ошибки выгодно исправлять дешёвой моделью

В анализ вошли 720 задач из калибровочного и тестового наборов. Примерно треть решалась только через reflect или replan, ещё треть только через escalate, остальные допускали оба пути.

На APPS и TACO много задач с локальными ошибками в парсинге, индексах и типах данных. Здесь stderr часто достаточно, чтобы дешёвая модель поправила решение. LiveCodeBench и CodeContests чаще требуют новой алгоритмической идеи. Повторное размышление над тем же кодом помогает реже, поэтому роутер чаще выбирает эскалацию.

Это не фиксированная таблица правил. Классификатор учится на rollout'ах, поэтому его решения зависят от обучающего распределения. Если типы задач меняются, полезность старой калибровки тоже меняется.

Как CRC ограничивает бюджет

Conformal Risk Control, или CRC, калибрует рабочую точку на holdout-наборе. Пользователь задаёт средний бюджет B, после чего система подбирает λ с требуемой статистической гарантией.

Роутер переобучать не нужно. Для нового бюджета достаточно пересчитать квантиль на калибровочных данных. Это удобно, когда одна система должна работать в нескольких режимах стоимости.

Гарантия опирается на exchangeability. Проще говоря, калибровочные и будущие задачи должны приходить из сопоставимого распределения. При заметном дрейфе задач старый предел расхода уже нельзя считать надёжным.

Что дали эксперименты и абляции

Обученный роутер сравнивали с always-reflect, always-escalate и prompt-only выбором. На пяти бенчмарках комбинация диагностического контекста и cost-aware решения использовала взаимодополняемость дешёвых действий и эскалации.

Удаление вердикта и stderr снизило accuracy роутера с 0,697 до 0,656. Soft labeling по всем успешным действиям дал 0,653, тогда как жёсткая метка самого дешёвого успешного действия работала лучше.

В Table 4 приведена кросс-модельная проверка на паре Gemini с n=229. Она показывает, что перенос возможен, но этого опыта мало, чтобы обещать перенос на любую новую пару моделей без дополнительной проверки.

Figure 4 содержит ещё один неудобный результат. На сложных подмножествах TACO прямая эскалация иногда ухудшала средний результат. Более сильная модель не гарантирует лучший ответ на каждой задаче, поэтому правило «при ошибке всегда зови дорогую» тратит деньги и иногда снижает solve rate.

Как применить подход в своём агенте

Для обучения понадобится журнал неудачных запусков. Сохраняйте условие задачи, код, вердикт, stderr, выбранное recovery action, стоимость и итоговый результат. Затем проиграйте несколько действий для одного и того же состояния и отметьте самое дешёвое успешное.

Сначала полезно проверить простую модель. Если тип ошибки уже хорошо предсказывает действие, сложный роутер может не окупиться. CRC имеет смысл после того, как стоимость и качество каждого action измерены на вашем трафике.

Не переносите опубликованные проценты напрямую в бюджет production-системы. Цены GPT-5.4-nano и GPT-5.4, длина trace, число тестов и распределение задач в вашем агенте могут сильно отличаться от эксперимента.

Часто задаваемые вопросы

Чем CodeRescue отличается от каскада моделей?

Каскад обычно выбирает между продолжением дешёвой моделью и эскалацией. CodeRescue различает исправление текущего кода, новый план и передачу другой модели. Решение принимается после запуска, когда уже доступны stderr и вердикт.

Нужен ли reinforcement learning?

Нет. Роутер обучается как обычный классификатор на rollout'ах с известным самым дешёвым успешным действием.

Подойдёт ли метод для открытых моделей?

Метод не зависит от конкретного API. Нужны как минимум два доступных варианта восстановления, execution environment и данные об их стоимости и успехе. Но новую пару моделей придётся откалибровать на собственных задачах.

Как быстро меняется бюджет?

CRC пересчитывает квантиль и выбирает новое λ. Сам роутер при этом остаётся прежним. Точная скорость зависит от размера holdout-набора, но операция намного дешевле повторного обучения.

Ограничения

Работа рассматривает одно recovery decision после неудачи. Реальные агенты могут делать несколько попыток, и состояние после каждой меняется. Для такого сценария нужен последовательный роутер, который учитывает уже потраченный бюджет и историю исправлений.

Калибровка устаревает при дрейфе задач. Кроме того, сбор контрфактических rollout'ов стоит денег: чтобы узнать, какое действие было самым дешёвым успешным, приходится попробовать несколько вариантов.

CodeRescue полезен как схема принятия решения после сбоя. Самый практичный сигнал здесь уже есть почти в каждом код-агенте: результат исполнения. Вопрос в том, собирает ли система эту диагностику и умеет ли использовать её до следующего дорогого вызова.