Hermes Agentのcronでモデルを固定する｜jobごとのpinとfleet defaultを分ける

夜中の集計 job だけを重いモデルで動かしたいのに、昼の会話でモデルを替えたら、朝の通知まで挙動が変わった。定期実行では、この種の変化が一番追いにくい問題になります。

Hermes Agent の cron では、job 個別の pin、cron 全体のデフォルト値、会話中の main model が別の役割を持ちます。私は、失敗時の影響を小さくするため、止まると困る job だけを個別に固定し、通常の job は fleet default へ寄せる形が扱いやすいと考えています。

前回完了時から今回完了後まで

前回は、cron の実行結果をcontext_fromで次の job へ渡す境界を扱いました。今回は、同じスケジュールでもモデル選択が偶然変わらないように、解決順を明示します。

時点	状態
前回完了時	jobは実行時点のmain modelに追従し、会話側の切り替えが運用へ波及します
今回完了後	個別pinとcron.modelを使い分け、jobごとの選択理由を確認できます

読み飛ばせる章: cronを1本だけ使い、会話中のモデルも変えない場合は「解決順を先に読む」と「変更後に確認する」だけ読めば足ります。

まず、どの値が勝つかを決める

モデルは実行時に次の順で解決されます。

[cron jobの個別pin]
          │  設定ありならここで確定
          ▼
[cron.model / cron.model_provider]
          │  unpinned jobのfleet default
          ▼
[main agent model]
  実行時点のhermes model

個別 pin がある job は、cron.modelより先に決まります。cron.modelがある場合、unpinned job は会話のhermes model変更に追従しません。どちらも無い時だけ、発火した時点の main model を使います。

この順番を知る前に設定を足すと、「固定したつもりの job」が実は会話のモデルを追っている状況を見落とします。モデルを替えた直後に問題が起きた時は、まず job が pinned か、fleet default があるかを見ます。

用語を揃える

用語	この回での意味
cron job	スケジュールに従って別セッションで動く1つの定期タスクです
main model	hermes modelまたは/modelで会話側へ選ぶモデルです
per-job pin	1つのjobへ保存するモデルとproviderの指定です
fleet default	cron.modelとcron.model_providerで決める、unpinned job共通のデフォルト値です
unpinned job	個別モデルを持たず、下位の解決規則へ委ねるjobです
reasoning effort	モデルpinとは別にjobごとへ指定できる思考量です

固定するjobと、まとめて動かすjobを分ける理由

毎時のリンク確認、週次の集計、障害通知では、必要な能力と費用が同じではありません。すべてを個別 pin にすると、変更が必要な時に job を 1 本ずつ追うことになります。反対に、すべてを main model 追従にすると、対話の試行が定期運用へそのまま入ります。

私は次のように分けます。

jobの性質	選び方	理由
監査、月次集計、公開前レビュー	個別pin	出力形式や失敗率を急に変えたくないためです
日次の軽い要約、定型の通知	cron.model	まとめて更新し、費用と品質を揃えやすいためです
試作中の短命job	main model追従	会話で選んだモデルの確認をそのまま使えるためです

個別 pin は「高性能なモデルを選ぶため」の機能ではありません。守るべき job の実行条件を、対話の都合から切り離すための境界です。

変更は1つずつ行う

まず対象 job を一覧で確認します。

hermes cron list

一覧では各 job のpinned状態を確認します。似た名前の job が複数なら、表示された job ID を控えてから変更します。

現在の main model を、その job だけへ固定する場合は次です。

hermes cron edit <job_id> --pin

この操作は、その時点で main agent に選ばれているモデルを対象 job へ保存します。後で会話側のモデルを替えても、その job の pin は変わりません。

provider と model を明示して固定する場合は、両方を指定します。

hermes cron edit <job_id> --provider <provider> --model <model>

実行前に provider 名と model 名を、利用中の設定と公式の provider 情報で照合します。存在しない識別子を置くと、cron の事前検査で実行が始まる前に止まります。

unpinned job 全体のデフォルト値を変える時だけ、cron.modelを使います。

hermes config set cron.model <model>
hermes config set cron.model_provider <provider>

この変更は個別 pin を持たない job にだけ及びます。個別 pin を外し、fleet default へ戻す操作は次です。

hermes cron edit <job_id> --unpin

--unpinのあとにcron.modelがあれば、その job は fleet default へ移ります。cron.modelも無い場合は、発火時の main model へ戻ります。解除後の行き先を決めずに unpin すると、次回の会話モデル変更で意図せず動作が変わります。

変更後に確認する

設定を書いただけでは、次の発火時に何が選ばれるかは分かりません。必ず一覧を読み直します。

hermes cron list
hermes config get cron.model
hermes config get cron.model_provider

確認したい点は 3 つです。

1. 守る job だけが pinned として表示されます。
2. unpinned job 用のcron.modelと provider が意図した値です。
3. main model を変える試行が必要なら、pin も fleet default もない試作 job だけで行います。

job ごとの reasoning effort も別に確認します。モデルを pin しても、思考量は自動では固定されません。

hermes cron edit <job_id> --reasoning-effort high

これは重い分析 job だけの思考量を上げる指定です。model pin と reasoning effort を同じ設定だと思うと、モデルを固定したのに出力時間や費用が変わる理由を取り違えます。

よくあるエラー

症状	主な原因	対応
会話でモデルを替えたら定期jobも変わりました	jobがunpinnedでcron.modelも未設定です	重要jobを--pinし、残りはfleet defaultを決めます
cron.modelを変えたのに重要jobが変わりません	そのjobに個別pinがあります	意図した固定ならそのままにし、fleetへ戻す時だけ--unpinします
jobが実行前に止まります	pinしたproviderの認証情報やskillの準備が不足しています	cronの事前検査が示すprofileとcredentialの場所を確認します
思ったより遅く、費用も増えました	reasoning effortをjobへ個別指定しています	--reasoning-effortの指定とglobal設定を分けて確認します
解除後にjobの結果が不安定です	unpin後の解決先がmain modelになっています	cron.modelを設定するか、必要なjobを再度pinします

変更の責任を小さくする

会話で使うモデルを試すことと、決まった時刻に動く job の契約は別です。個別 pin は重要な契約を守り、fleet default は通常 job をまとめて保守し、main model 追従は試作へ残します。

この 3 つを混ぜなければ、モデルを変える判断は怖くありません。次にhermes modelを替える前に、hermes cron listで pinned job と unpinned job を一度だけ分けておくと、変更の影響範囲を説明できる状態になります。

一次情報

資料	確認した内容
Scheduled Tasks (Cron)	per-job pin、cron.model、main modelの解決順、--pin、--unpin、reasoning effort、事前検査
Hermes Agent Configuration	hermes config getとhermes config setによる設定の確認と保存先の原則