Hermesのreasoning effort設定：セッション・全体・モデル別

Hermesを常に最大のreasoning levelで動かしても、すべてのタスクが良くなるとは限りません。また、画面にthinkingが表示されても、選んだeffortが実際のリクエストで使われた証拠にはなりません。日常用のグローバル値を決め、難しいタスクだけセッション内で上げ、繰り返し効果を確認できたモデルにだけモデル別設定を追加し、同じ検証可能な課題とプロバイダーの記録で確認するのが安全です。

基本方針：まず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の表示とeffortの設定は別物

次のコマンドは現在のセッションのreasoning effortを変更します。

/reasoning high
/reasoning none

次のコマンドはthinkingの表示だけを変更します。

/reasoning show
/reasoning hide

Thinkingを隠しても、リクエストはhighで動いている可能性があります。表示されていても高い段階とは限りません。引数なしで/reasoningを実行し、現在のeffortと表示状態を別々に確認してください。

セッション、グローバル、モデル別をどう使い分けるか

セッション：目の前の難しいタスクだけを変える

アクティブなセッションで次を実行します。

/reasoning high

変更は既定で現在のセッションだけに適用されます。将来の会話を変えず、特定の難しいデバッグや設計判断だけに多くのeffortを割り当てる最も安全な方法です。

現在のセッションでreasoningを無効にするよう要求するには、次を使います。

/reasoning none

実際に無効になるのは、選択したモデルとルートが許可する場合だけです。プロバイダーがreasoningを必須にする、別の値へ変換する、または拒否することがあるため、実リクエストの確認が必要です。

グローバル：日常の既定値を決める

新しいセッションにも保存するには--globalを付けます。

/reasoning medium --global

Hermesはagent.reasoning_effortとして保存します。さまざまなタスクを扱うなら、最大値よりmediumを基準にし、本当に難しいセッションだけ一時的に上げる方が扱いやすいです。

ターミナルから保存値を確認できます。

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

config getで値が返ることは、Hermesが設定を読み取った証拠です。プロバイダーがその値をそのまま受け入れ、実行した証拠ではありません。

モデル別：頻繁に切り替えるモデルの既定値

高速モデルと深いreasoning向けモデルを頻繁に切り替える場合は、config.yamlを編集します。

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

一致したモデル別設定はグローバルのagent.reasoning_effortより優先されます。Hermesで実際に設定した正確なmodel IDを使うのが安全です。編集後は新しいセッションを開き、対象モデルを選び、もう一度/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を難しいバグで試してはいけません。それではeffortではなく課題の違いを測ることになります。次の小さな課題は手作業で答えを確認でき、ツールも不要です。

この関数は、重なる、または接している閉じた整数区間を、既に覆っている範囲を縮めずに結合する必要があります。
最小の反例を一つ見つけ、期待される出力と実際の出力を示し、最小のコード修正と三つの回帰テストを提示してください。
ツールは使わず、counterexample、expected、actual、fix、testsをキーとするJSONだけを返してください。

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の状態とプロバイダーのリクエスト記録で確認
実使用量	provider/APIの記録または請求明細を使用
異常	timeout、retry、fallback、エラー、モデル切替を記録

Retryやfallbackが発生した実行を正常な実行と平均しないでください。モデル、呼び出し回数、待ち時間、Token使用量が同時に変わり、reasoning effortの影響を切り分けられません。

--usage-fileでHermesのローカルレポートを保存する

機械的に比較する場合は、グローバル値を一時的に変え、同じ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

明示値があった場合は、記録した元の値を再設定します。

HermesのJSONには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はローカル推定であり、プロバイダーの請求書ではない
• プロバイダーが特定のToken種別を返さない場合、フィールド欠落は使用量ゼロの証拠ではない
• retryやfallbackがあれば、実際の呼び出しとモデルをプロバイダー記録で確認する

4種類の証拠を分けて確認する

有効な検証では、次の4点を別々に記録します。

1. 設定の読み戻し： hermes config getとconfig.yamlに意図した値があることを確認します。これはHermesが保存・解決した値の証拠であり、providerが受理した値の証拠ではありません。
2. 実際に送信またはマッピングされたeffort： 対象モデルを選んだ後に/reasoningを実行します。ステータスにsends ... on this routeが表示される場合、またはルートが送信リクエストのtraceを提供する場合は、APIへ送られた値が想定したマッピングと一致するか確認します。Thinkingの表示は別の表示設定です。
3. provider側での受信・受理・実行： ルート/providerが実際に提供する場合だけ、サーバー側のリクエスト記録、echo値、明示的な受理・実行確認を使います。成功の目印は、サーバー側のパラメーターが送信・マッピングされた値と一致し、拒否、retry、fallback、追加の下方変換が記録されていないことです。Payload traceが証明するのは受信までで、実行ではありません。providerが提供しないフィールドを要求しないでください。
4. 使用量と結果： 実際のモデル、出力品質、遅延、Token分類、API呼び出し数、請求額または推定コストを記録します。これらはルートと実使用量を確認できますが、providerが受理したeffortは証明しません。reasoning Tokenの量から段階を逆算することもできません。

4種類の証拠は互いの代わりになりません。providerのログがモデル、Token、呼び出し回数、消費額だけを示しeffortを公開しない場合、言えるのは「記録した設定の下で出力、遅延、実使用量を比較したが、providerが実際に受理した段階は確認できない」までです。

noneが保存されないように見える場合

2026年10月5日に公開されたGitHub issueでは、報告者が示した特定の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が示すファイルを開き、空値やnullではなく文字列noneであることを確認する
4. 新しいセッションを開き、再び/reasoningを実行する
5. ルート/providerがサーバー側のリクエスト記録、echo値、明示的な確認を提供する場合だけ、送信・マッピングされた値と受信・受理された値を照合する。ログがモデル、Token、消費額だけなら、受理されたeffortは確認できないと記録し、逆算しない

モデルがreasoning必須なら、完全に無効化できません。表示切替を繰り返すのではなく、そのルートが受け付ける最小段階を選びます。

OpenAI-compatibleのカスタムプロバイダーを使う場合

実際の挙動は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のマッピングやprovider側の受理・実行記録を公開する場合は確認し、公開しない場合は証拠の限界を明記して、Tokenや消費額を受理済み段階の証明にしないでください。

有用な既定値は理論上最強の段階ではありません。あなたのモデルとルートで、許容できる待ち時間と実使用量の範囲内で品質目標を安定して満たす最小のeffortです。