Hermes: как выбрать reasoning effort и проверить настройки

Максимальный reasoning effort не делает любой ответ лучше, а видимый блок thinking ещё не доказывает, что запрос ушёл с выбранным уровнем. Надёжнее оставить разумное глобальное значение, повышать глубину только для сложных задач, назначать отдельные значения конкретным моделям после повторяемой проверки и сверять результат с журналом запросов провайдера.

Базовый выбор: начните с medium

Hermes принимает none, minimal, low, medium, high, xhigh, max и ultra. Если значение не задано, используется medium. Конкретная модель или маршрут может поддерживать не всю шкалу: уровень может быть понижен, преобразован, проигнорирован или отклонён. Поэтому ориентируйтесь на актуальную документацию Hermes и фактическую запись запроса у провайдера.

Задача	С чего начать	Когда менять
Форматирование, извлечение полей, простая переработка текста	low; minimal или none — только после проверки поддержки	Если пропадают поля или нарушается формат, перейти на medium
Небольшая правка кода, обычный вопрос, локальная диагностика	medium	При стабильно точных ответах попробовать low; при пропусках условий — high
Ревью с несколькими ограничениями, поиск причины в нескольких файлах, выбор архитектуры	high	Проверять xhigh или max, только если выигрыш повторяется и задержка приемлема
Очень сложное планирование и длинная цепочка зависимостей	Сначала сравнить high и xhigh	Оставлять max или ultra лишь после контролируемого теста

ultra — внутренняя ступень Hermes. Маршрут преобразует её в самый высокий уровень, который способен отправить. Само название не повод делать её глобальным значением.

Показ thinking и reasoning effort — разные настройки

Эти команды меняют глубину рассуждения в текущей сессии:

/reasoning high
/reasoning none

А эти лишь управляют отображением thinking:

/reasoning show
/reasoning hide

Скрытый thinking не означает, что модель перестала рассуждать. Видимый thinking не означает, что включён высокий уровень. Команда /reasoning без аргументов показывает и текущий effort, и состояние отображения — проверяйте оба значения отдельно.

Когда использовать сессию, глобальное значение и настройку по модели

Уровень для сессии: одна сложная задача

В активной сессии выполните:

/reasoning high

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

Чтобы запросить отключение reasoning в этой сессии:

/reasoning none

Отключение сработает только там, где модель и маршрут его допускают. Провайдер может требовать reasoning, иначе трактовать значение или отвергнуть параметр, поэтому итог проверяется не по интерфейсу, а по запросу.

Глобальное значение: повседневный режим

Чтобы сохранить уровень для новых сессий, добавьте --global:

/reasoning medium --global

Hermes сохраняет его как agent.reasoning_effort. Для смешанной нагрузки разумно оставить глобально medium, а редкие сложные задачи поднимать до high внутри сессии.

Проверить сохранённое значение можно из терминала:

hermes config path
hermes config get agent.reasoning_effort
hermes config check

config get подтверждает, что Hermes прочитал настройку. Он не доказывает, что провайдер принял её и применил без преобразования.

Настройка по модели: устойчивое поведение при переключении

Если вы регулярно меняете быструю модель на более глубокую, отредактируйте config.yaml:

agent:
  reasoning_effort: "medium"
  reasoning_overrides:
    "custom/example-fast-model": "low"
    "custom/example-deep-model": "high"

Совпавшая запись в reasoning_overrides имеет приоритет над глобальным значением. Лучше использовать точный model ID из конфигурации Hermes. После изменения откройте новую сессию, выберите нужную модель и снова выполните /reasoning.

Карту переопределений можно прочитать так:

hermes config get agent.reasoning_overrides --json

В model ID часто встречаются точки и слеши. Проще редактировать YAML напрямую; при создании нового ключа с точкой через hermes config set используйте правила экранирования из справочника CLI.

Приоритет настроек: почему глобальный уровень не меняет результат

Для выбранной модели порядок удобно понимать так:

1. временный /reasoning в текущей сессии;
2. подходящая запись agent.reasoning_overrides;
3. глобальный agent.reasoning_effort;
4. значение по умолчанию модели или провайдера.

Если глобально стоит low, а /reasoning показывает high, сначала ищите настройку сессии или переопределение для модели. После /model проверяйте уровень заново: другая модель может совпасть с другой строкой в карте.

Один и тот же проверяемый тест

Нельзя проверять low на простом перефразировании, а high — на сложной ошибке: вы измерите разницу задач. Ниже небольшой пример с проверяемым ответом, для которого не нужны инструменты:

Функция должна объединять пересекающиеся или соприкасающиеся замкнутые целочисленные интервалы, не уменьшая уже покрытый диапазон.
Найдите минимальный контрпример, укажите ожидаемый и фактический результат, предложите минимальную правку и три регрессионных теста.
Не используйте инструменты. Верните только JSON с ключами counterexample, expected, actual, fix и tests.

def merge_ranges(ranges):
    ranges = sorted(ranges)
    merged = []
    for start, end in ranges:
        if not merged or start > merged[-1][1] + 1:
            merged.append([start, end])
        else:
            merged[-1][1] = end
    return merged

Ошибка проявляется, когда следующий интервал целиком находится внутри уже добавленного: присваивание меньшей правой границы сокращает покрытие. Оценивайте не стиль, а пять объективных пунктов:

1. корректный JSON без лишнего текста;
2. контрпример со вложенным интервалом, действительно вызывающий ошибку;
3. правильные expected и actual;
4. минимальная правка, сохраняющая большую правую границу;
5. тесты для вложенных, соприкасающихся и раздельных интервалов.

Ручное сравнение уровней

Для каждого уровня начинайте новую сессию. Не меняйте model ID, провайдера, рабочую папку, контекст, набор инструментов, текст задачи и формат ответа. Одного прогона достаточно для первичного отбора; если вы меняете часто используемое значение, повторите каждый финальный вариант не менее трёх раз, чтобы случайный ответ не стал правилом.

Записывайте:

Поле	Как фиксировать
Effort	Перед задачей выполнить /reasoning и сохранить показанный уровень
Качество	Оценка 0–5 по чек-листу выше
Задержка	Время от отправки до полного финального ответа
Модель и провайдер	Сверить статус Hermes и запись запроса у провайдера
Фактический расход	Брать из API-журнала или детализации провайдера
Аномалии	Отмечать timeout, retry, fallback, ошибку или смену модели

Прогон с retry или fallback нельзя усреднять с чистыми прогонами. В нём одновременно меняются число вызовов, модель, время и Token, поэтому он не показывает влияние reasoning effort.

Локальный отчёт Hermes через --usage-file

Для машинного сравнения можно временно менять глобальный уровень и запускать одну и ту же one-shot задачу:

hermes config set agent.reasoning_effort low
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-low-usage.json > ./hermes-low-output.txt

hermes config set agent.reasoning_effort medium
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-medium-usage.json > ./hermes-medium-output.txt

hermes config set agent.reasoning_effort high
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-high-usage.json > ./hermes-high-output.txt

В реальном тесте передавайте все три раза полный одинаковый текст задачи. До запуска убедитесь, что для выбранной модели нет переопределения, которое перекроет глобальное значение. После теста восстановите исходную настройку. Если раньше она не была задана:

hermes config unset agent.reasoning_effort

Если значение было явным, установите его обратно.

JSON Hermes может содержать input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider и estimated_cost_usd. Верхний уровень относится к main agent loop. Вызовы для заголовка, vision, compression и других вспомогательных задач вынесены в auxiliary; локальный общий итог находится в total_including_auxiliary.

Важно соблюдать границы:

• estimated_cost_usd — локальная оценка Hermes, а не счёт провайдера;
• если провайдер не возвращает отдельный тип Token, отсутствие поля не означает нулевой расход;
• при retry или fallback фактические вызовы и модели нужно сверять по журналу провайдера.

Проверяйте четыре вида подтверждения отдельно

Надёжная проверка фиксирует четыре разные вещи:

1. Считанная конфигурация: hermes config get и config.yaml содержат ожидаемое значение. Это подтверждает, что Hermes сохранил и разрешил настройку, но не то, что её принял провайдер.
2. Фактически отправленный или преобразованный effort: после выбора целевой модели выполните /reasoning. Если статус показывает sends ... on this route или маршрут предоставляет trace исходящего запроса, сверяйте значение, отправленное в API, с ожидаемым преобразованием. Показ thinking остаётся отдельной настройкой интерфейса.
3. Получение, принятие или выполнение на стороне провайдера: используйте серверную запись запроса, отражённое значение или явное подтверждение принятия/выполнения только тогда, когда маршрут или провайдер действительно это показывает. Признак успеха — сервер записал тот же параметр, который Hermes отправил после преобразования, и нет записи об отказе, retry, fallback или дополнительном понижении. Payload trace доказывает получение, но не выполнение; не требуйте поля, которого провайдер не предоставляет.
4. Расход и результат: записывайте фактическую модель, качество ответа, задержку, категории Token, число API-вызовов и списанную или оценочную стоимость. Эти данные подтверждают маршрут и реальный расход, но не принятый провайдером effort; по числу reasoning Token нельзя восстановить уровень.

Эти виды подтверждения не заменяют друг друга. Если журнал провайдера показывает только модель, Token, число вызовов или списание и не раскрывает effort, корректный вывод таков: вы сравнили ответы, задержку и фактический расход при зафиксированных настройках, но не подтвердили, какой уровень принял провайдер.

Что делать, если none не сохраняется

В публичном GitHub issue от 5 октября 2026 года автор сообщил, что на указанных им коммитах main команда hermes config set agent.reasoning_effort none могла сохранить YAML null, тогда как /reasoning none --global сохраняла строку none. Это пользовательский отчёт, привязанный к конкретным версиям. Он не доказывает, что проблема есть в вашей сборке, и не подтверждает её исправление позже.

Проверяйте по порядку:

1. выполните /reasoning none --global;
2. выполните hermes config get agent.reasoning_effort;
3. откройте файл из hermes config path и убедитесь, что записана строка none, а не пустое значение или null;
4. создайте новую сессию и снова выполните /reasoning;
5. если маршрут или провайдер показывает серверную запись запроса, отражённое значение или явное подтверждение, сопоставьте отправленный/преобразованный effort с тем, что было получено или принято; если в журнале есть только модель, Token или списание, зафиксируйте, что принятый уровень подтвердить нельзя, и не выводите его косвенно.

Если модель обязательно использует reasoning, полностью отключить его не получится. Тогда выбирайте минимальный уровень, который поддерживает маршрут, а не переключайте показ thinking.

OpenAI-compatible провайдер и BetterToken

Итог зависит одновременно от Hermes, модели и провайдера. Например, актуальная инструкция BetterToken для Hermes предлагает указать собственный API Key, Base URL https://www.bettertoken.ai/v1 и точный Model ID из каталога, а затем проверить подключение коротким запросом. BetterToken не гарантирует поддержку всех reasoning-уровней каждой моделью и не обещает, что повышение уровня всегда улучшит ответ.

При любом провайдере записывайте model ID, запрос и фактический расход в одну таблицу. Иначе смену модели, маршрута или схемы списания легко принять за эффект reasoning effort.

Как выбрать окончательное значение

Оставьте medium глобальной базой, для редких сложных задач используйте настройку сессии, а high, xhigh или более высокий уровень назначайте конкретной модели только после нескольких одинаковых тестов со стабильным выигрышем. Для механических задач снижайте уровень до low, minimal или none лишь тогда, когда качество не падает, а измеренные задержка и фактический расход меняются ожидаемо. Если маршрут показывает сопоставление sends или провайдер даёт подтверждение принятия/выполнения, сверяйте его; иначе явно укажите границу доказательств и не считайте Token или списание подтверждением принятого уровня.

Полезный уровень — не самый громко названный. Это минимальный effort, который на вашей модели и маршруте стабильно проходит порог качества при приемлемом времени и фактическом расходе.