招待して報酬

招待報酬の仕組み

招待リンクを共有します。友だちがリンクから登録してチャージすると、その後のチャージごとに表示された報酬を受け取れます。

エージェント・自動化

Hermes Agentのローカルモデル設定：Ollama／Qwenと明示的なクラウド切り替え

プライバシー境界を明確にする実践ガイドです。Ollama経由でローカルQwenを設定し、小さなファイルタスクで動作確認し、クラウドプロバイダーを追加したうえで、セッション単位・1回だけ・全体既定値の切り替えと、補助モデルやfallbackの監査まで行います。

BT

BetterToken

編集チーム
3 分で読めます
目次
Hermes Agentのローカルモデル設定：Ollama／Qwenと明示的なクラウド切り替え

Hermes Agentの日常的なファイル操作やコマンド実行はローカルモデルに任せ、難しいタスクだけクラウドモデルへ切り替えられます。境界を分かりやすく保つには、まずローカル経路を小さなタスクで確認し、クラウド利用は自動fallbackではなく毎回明示的な操作にします。

以下はHermesとOllamaの現行公式ドキュメントに基づく一連の手順です。ローカルQwenの接続、確認可能なファイルタスク、クラウドプロバイダーの設定、3種類の切り替え範囲、そしてどの段階でデータが端末外へ出るかを説明します。特定ハードウェアでの独自ベンチマークを示すものではありません。

基本方針：既定はローカル、クラウドは明示的に選ぶ

状況優先する経路理由
ローカルファイル、小規模なコード修正、日常タスクローカルOllama／Qwenモデル要求が127.0.0.1へ向かい、境界を確認しやすい
tool callが繰り返し失敗先にモデル、runtime、contextを確認原因が難易度ではなく、形式・parser・contextの場合がある
長いcontext、複雑な推論、vision、厳しい待ち時間新しいセッションを作り明示的にcloudへ過去の私的な会話を不用意に送らず、追加能力を使える
データを一切外へ出せないローカルモデルとローカルtoolsのみ。cloud auxiliaryとfallbackは無効main modelがローカルでも全工程がofflineとは限らない

main model、tools、auxiliaryの送信先を分けて確認する

段階通常の送信先確認点
Hermesがhttp://127.0.0.1:11434/v1を呼ぶローカルOllamamodel tagが:cloudで終わらず、loopback URLであること
cloud modelへ切り替えた次のturn選択したcloud provider会話context、system instructions、tool schemasが送られる可能性
ローカルfile／terminal tools通常は端末内コマンド自体がupload、download、remote APIを実行しないか
Web、browser、search、remote MCP、messaging接続先サービスquery、ページ内容、tool arguments、結果
local Whisperとcloud TTS音声認識はlocal、合成用textはcloudハイブリッド音声経路を完全offlineと呼ばない
fallback_providersやcloud auxiliary条件成立時にclouderror、rate limit、auth、capacityで自動的に境界が変わる

OllamaのHermes向けselectorにはlocalとcloudの両方が表示されます。名前が:cloudで終わるmodelは、Ollama経由で選んでもremote inferenceです。

最短経路：ollama launch hermes

ollama launch hermes

公式integrationは必要に応じてHermesをinstallし、model selectorを表示し、http://127.0.0.1:11434/v1を設定します。必ずlocal entryを選びます。たとえばqwen3.5:cloudはlocalではありません。

設定後は実際のrouteを確認します。

hermes config get model --json
hermes status

launcherがdownload済みmodelを見つけない場合や、各段階を確認したい場合はmanual設定を使います。

ローカルQwenを手動で接続する

1. tools対応のQwenを取得する

OllamaはQwen 3.5 familyをtools対応として掲載しています。ここでは接続確認用の軽い例としてqwen3.5:4bを使います。4B modelがすべてのagent taskで安定するという意味ではありません。RAM／VRAMに余裕があれば、より大きい公式tagも検討してください。

ollama --version
ollama pull qwen3.5:4b

Ollama serviceが起動していない場合だけ実行します。

ollama serve

別terminalでmodel一覧を確認します。

curl http://127.0.0.1:11434/api/tags

Hermesを設定する前にOpenAI-compatible endpointを直接testします。

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.5:4b",
    "messages": [{"role": "user", "content": "Reply with LOCAL_OK"}],
    "max_tokens": 16
  }'

model replyを含むJSONが返れば、Ollamaのlocal servingは動作しています。ここでConnection refusedなら、HermesではなくOllama serviceを先に直します。

2. Hermesをlocal endpointへ向ける

hermes model

Custom endpointを選び、次を入力します。

  • API Base URL：http://127.0.0.1:11434/v1
  • API Key：空欄
  • Model：qwen3.5:4b
  • Context length：現行integrationがauto-detectを提供する場合は空欄

保存結果を確認します。

hermes config get model --json
hermes status

local model、provider custom、loopback URLが表示されるはずです。Hermesはtool中心のagent処理に大きいcontextを推奨しています。context errorが出た場合は利用中versionの文書に従い、Ollamaが実際に読み込んだ値を確認します。

ollama ps

メモリ不足や継続的なswapを起こすほど大きなcontextを無理に設定しないでください。

小さなファイルタスクでlocal chainを確認する

mkdir -p ~/hermes-local-check
cd ~/hermes-local-check
printf 'alpha\nbeta\ngamma\n' > input.txt
hermes

Hermes sessionで次を入力します。

input.txtを読み、行数と1文の要約を含むsummary.mdを作成してください。Web、browser、network、messaging、cloud toolsは使用しないでください。最後に書き込んだ正確なpathを報告してください。

結果を確認します。

cd ~/hermes-local-check
cat summary.md

合格条件は、summary.mdが存在して3行を認識し、Hermesがtool-call JSONを表示するだけでなく実際に書き込み、hermes statusがlocal Qwenと127.0.0.1を示し続け、不要なcloud fallbackやcloud auxiliaryがないことです。

このtestが示すのはendpoint、tool loop、file writeの接続です。複雑なtaskの性能や、すべてのoptional toolがofflineであることまでは証明しません。

cloud providerを追加し、切り替えだけを明示的にする

hermes model

利用するcloud providerを選び、OAuthまたはinteractive secret inputを完了し、modelを選びます。API keyをchat messageやshell historyに残るcommandへ貼り付けないでください。

hermes modelはdefaultを変更するため、cloud設定後にcurrent sessionと将来のdefaultをlocalへ戻します。

/model qwen3.5:4b --provider custom --global

3種類のscopeがあります。

/model YOUR_CLOUD_MODEL --provider YOUR_CLOUD_PROVIDER
/model YOUR_CLOUD_MODEL --provider YOUR_CLOUD_PROVIDER --once
/model YOUR_CLOUD_MODEL --provider YOUR_CLOUD_PROVIDER --global
  • 1行目はcurrent sessionだけを変更します。
  • --onceは次の1 turnだけcloudを使い、その後元へ戻します。
  • --globalはcurrent sessionと新しいsessionsのdefaultを変更します。

localへ戻す場合：

/model qwen3.5:4b --provider custom

/modelにproviderが見えない場合は、先にhermes modelでconfigureまたはauthenticateします。session commandは新しいcredentialを作りません。

cloudへ切り替える判断基準

未公開source code、個人文書、internal logs、範囲の明確な小規模taskはlocalに残します。toolsが正しく動き、速度も許容できるなら、理論上のquality向上だけでsessionを外へ送る必要はありません。

endpoint、context、tool supportを確認してもlocal modelが失敗する場合、非常に長いcontext、vision、複雑なmulti-step reasoning、より低いlatencyが必要な場合はcloudが妥当です。

機密性のある作業では、新しいcloud sessionを開き、必要最小限の内容だけを渡します。Hermesの文書ではmid-session model switchでprompt cacheがresetされ、次のrequestが会話を再読込します。privacy上は、切り替え後にrelevant current-session contextがcloud providerへ送られると考えてください。

auxiliary modelsとfallbackも監査する

「外部model callは毎回自分で決める」という方針なら、fallback_providersを設定しません。fallbackはerror、rate limit、authentication、capacityで起動し得るため、人間がtaskの難しさを判断した結果とは限りません。

Hermesはcompression、vision、web extractionなどをauxiliary modelsへ割り当てられます。main modelがlocalでも、それらのslotsまでlocalとは限りません。

Bash、macOS、Linuxではread-only確認を行えます。

grep -nE 'fallback|auxiliary|base_url|provider|default' ~/.hermes/config.yaml

Windowsでは%USERPROFILE%\.hermes\config.yamlを確認します。main endpoint、auxiliary providers、fallback_providers、不明なremote Base URLを探してください。

より強い証明が必要ならfirewall、DNS、outbound proxy logsで実通信を観察します。UIの「local」表示だけではworkflow全体のnetwork boundaryを保証できません。

よくある問題

Connection refused

curl http://127.0.0.1:11434/api/tags

失敗したらollama serveまたはdesktop serviceを起動します。

tool JSONを出すだけで実行しない

対象Qwen tagがtools対応か、HermesとOllamaが最新かを確認します。小さいmodelは複雑なargumentsで不安定な場合があります。1ファイルtestを再実行し、その後に大きいlocal modelまたは明示的cloud switchを試します。

modelやproviderが表示されない

hermes modelで設定します。/modelは既に設定済みのroutesだけを表示します。

current chatが古いmodelのままに見える

default変更は主に新しいsessionsへ適用されます。active chatでは/modelを使うか、新規sessionを開きます。

遅い、またはcontext errorが出る

ollama ps

model size、GPU offload、contextを確認します。大きいcontextはtool schemasの保持に役立つ一方、memoryとfirst-turn prefillを増やします。

ハイブリッド構成は便利でも完全offlineとは限らない

あるX userは、Ollama Cloud経由のGemma、cloud Qwen、local Qwen、local Whisper、cloud TTSを組み合わせた個人prototypeを報告しています。task別routingの例にはなりますが、再現可能な設定、network log、independent benchmarkが公開されたわけではありません。

model、voice、toolsにはそれぞれ別の境界があります。local Whisperでもcloud TTSはremoteのままであり、local main modelでもcalendar、project management、search、remote MCPの通信は自動的にprivateにはなりません。

最終チェックリスト

  • local tagが:cloudで終わらず、Base URLがhttp://127.0.0.1:11434/v1。
  • direct curl testが成功し、hermes statusが想定routeを表示。
  • test taskが実際にsummary.mdを作成。
  • cloud providerは設定済みだが、切り替えは毎回/modelで明示。
  • 機密cloud作業は新しいsessionと最小contextで開始。
  • remote tools、auxiliary models、fallback_providersを確認済み。
  • 完全offline要件ではnetwork toolsとcloud servicesをすべて無効化。

参照資料

BetterTokenAI MODEL APIsすべてのモデルを1つのAPIでGPTClaudeDeepSeekQwenGLMKimiMiniMaxAI API · 従量課金BetterToken で 開発を始めようAPI キーを作成して、 最初のリクエストを送信。利用を始めるbettertoken.ai
エージェント・自動化ChatGPT Dotsの使用上限と権限：自動で何をする？エージェント・自動化Mistral WorkとGitHubを接続する方法：権限確認と初回読み取りテストエージェント・自動化Gemini CLIの制限：1日の上限、使用量確認、リセットと継続方法

LLM ワークフローを最適化しませんか？

単一 API でモデルを接続し、キーと AI コストを管理できます。

無料で始める