omp (Oh My Pi) + JoinGonka Gateway: モデルロールを備えたエージェント

ステップ1：ompをインストールする。プロジェクトのREADMEに記載された公式の方法：

# macOS and Linux
curl -fsSL https://omp.sh/install | sh

# Homebrew
brew install can1357/tap/omp

# via Bun (requires Bun 1.3.14 or newer)
bun install -g @oh-my-pi/pi-coding-agent

# Windows (PowerShell)
irm https://omp.sh/install.ps1 | iex

ステップ2：キーを取得する。gate.joingonka.ai/registerで登録し、アドレスを確認して、「APIキー」セクションでjg-プレフィックス付きのキーを作成します。1つのキーと1つの残高がネットワークのすべてのモデルで有効です。

ステップ3：インストーラーを実行する。

npx @joingonka/setup --tool omp

インストーラーはキーを尋ねます — シェル履歴に残らないようコマンドライン引数では渡されません — そして4つのことを行います：

• ~/.omp/agent/models.ymlにプロバイダーjoingonkaを書き込みます：ゲートウェイアドレス、プロトコルopenai-completions、リテラルとしてのキー、そして実際のコンテキストウィンドウと応答上限を持つ3つのネットワークモデル。ファイルには600権限が付与されます。
• デフォルトモデル — ~/.omp/agent/config.ymlのmodelRoles.default — をDeepSeek V4 Flashに設定しますが、それはそのロールが空か、ネットワークから削除されたモデルを指している場合のみ：他人の選択を横取りせず、切り替え方法を提案します。
• 書き込み前に以前のファイルをバックアップし、他のプロバイダー、ロール、コメントはそのまま残します。
• 最後にゲートウェイへ実際のリクエストを送り、キー、アドレス、モデルが受け入れられたかを明示的に伝えます。

別のデフォルトモデルは--modelフラグで指定します。短縮形はdeepseek、glm、minimax — 明示的に指定されたモデルは常に書き込まれます。ドットファイルやサーバー向けには質問なしのモードがあり、そのモードではキーは環境変数から取得されます：

JOINGONKA_API_KEY=jg-your-key npx @joingonka/setup --tool omp --model glm --non-interactive

非標準の設定場所もインストーラーは自分で考慮します：名前付きプロファイル（OMP_PROFILE）と移動されたエージェントディレクトリ（PI_CODING_AGENT_DIR）。継承されたmodels.jsonはomp自身が行うのと同じようにmodels.ymlへ移行されます — 以前のプロバイダーは失われません。そして、config.ymlなしの古いsettings.jsonが隣にある場合、インストーラーはconfig.ymlを作成しません。ompが独自の設定移行を見逃さないようにするためです：一度ompを起動してコマンドを再実行するよう促します。

インストーラーがやっていることは、すべて手作業で書けます。ファイルは2つだけで、それぞれ役割が決まっています。models.ymlはプロバイダーとモデルを記述し、config.ymlは設定を保持します——どのモデルがどのロールに割り当てられているかも含めて。

# ~/.omp/agent/models.yml
providers:
  joingonka:
    baseUrl: https://gate.joingonka.ai/v1
    api: openai-completions
    apiKey: jg-your-key
    models:
      - id: deepseek-ai/DeepSeek-V4-Flash-0731
        name: DeepSeek V4 Flash (Gonka)
        input: [text]
        contextWindow: 380000
        maxTokens: 32768
        reasoning: true
      - id: zai-org/GLM-5.3-Flash
        name: GLM-5.3 Flash (Gonka)
        input: [text]
        contextWindow: 390000
        maxTokens: 8192
        reasoning: true
      - id: MiniMaxAI/MiniMax-M2.7
        name: MiniMax M2.7 (Gonka)
        input: [text]
        contextWindow: 200000
        maxTokens: 8192

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731

キーをリテラルで書くのが最もトラブルの少ない方法です。ompはどの環境からでも起動でき、ファイルはchmod 600 ~/.omp/agent/models.ymlで保護するだけで十分です。キーをファイルの外に置きたい場合は、apiKeyに環境変数名（例：JOINGONKA_API_KEY）を書き、ompを起動するシェルでそれをexportしてください——このキー解決の順序はプロジェクトのドキュメントに記載されているとおりです。

オプションのcostフィールド（100万トークンあたりの価格）は、ompのUIでセッションコストを見積もるためだけに必要です。インストーラーはインストール時点のゲートウェイの実際の価格を書き込みます。手動設定ではこのフィールドを省略しても構いません——この見積もりは請求には関係なく、実際の使用量はダッシュボードで確認できます。

モデルセレクターはprovider/model-idとして記述します。プロバイダー名は最初のスラッシュで区切られるため、独自のスラッシュを含むネットワークのIDはそのまま書きます：joingonka/deepseek-ai/DeepSeek-V4-Flash-0731。config.ymlを編集する代わりに、セッション内で/modelコマンドを使うか、omp setupウィザードからロールを割り当てることもできます。

ompでは、すべてのタスクに単一のモデルではなく、役割（ロール）ごとにモデルを選択します。これが設定の主なポイントです。組み込みの対話用ロール：default、smol、slow、plan、commit、task、tiny、memory、advisor、およびvision。すべてを指定する必要はありません。設定されていないsmolやslowは、まずdefaultロールのモデルを使用します。taskロールを持たないサブエージェントは現在のセッションのモデルで動作し、commitとtinyはsmolに追従します。defaultを1行指定するだけの構成でも完全に動作します。

ネットワーク内のモデル間でロールを分けるのは、コスト削減のためではありません（DeepSeek V4 Flash、GLM-5.3 Flash、MiniMax M2.7の価格は同じです）。動作と容量のためです。推論モデルは計画立案に優れ、長文生成モデルはライティングに優れており、バックグラウンドの些細なタスクを主要なタスクと同じキューに入れる必要はないからです。

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731
  slow: joingonka/zai-org/GLM-5.3-Flash
  plan: joingonka/zai-org/GLM-5.3-Flash
  tiny: joingonka/MiniMaxAI/MiniMax-M2.7

retry:
  fallbackChains:
    default:
      - joingonka/zai-org/GLM-5.3-Flash

retry.fallbackChainsブロックは、ピーク時の保険です。メインモデルが429エラーを返し続ける場合、ompは残りの処理をチェーン内の次のエントリに渡し、一時停止後にメインモデルに戻ります。チェーンのキーには、ロール、特定のモデル、またはプロバイダー全体（joingonka/*）を指定できます。

1回の起動ごとにロールをフラグで再定義できます。omp --model slowはslowロールのモデルでセッションを開始し、--smol、--slow、--planは各ロールのモデルを置き換えます。セッション内ではCtrl+Pでロールモデルを切り替え、/modelで選択を開くことができます。同じタブの「Roles」でロールと予備のモデルを設定できます。

ロールの値に推論レベル（:low、:medium、:high）を追加できます。これはompの構文であり、特定のモデルがこのレベルをどのように解釈するかはモデル自体に依存します。例えば、GLM-5.3 Flashの場合、これはバイナリスイッチです。詳細はモデルの概要を参照してください。もう1つの便利な機能として、<repo>/.omp/config.ymlファイルを作成し、同じmodelRolesブロックを含めることで、リポジトリごとにロールを再定義できます。プロバイダーとキーはホームディレクトリに残るため、キーがリポジトリにコミットされることはありません。

まず、omp がプロバイダーを認識しているか確認しましょう：

omp models joingonka

応答として、models.yml のコンテキストウィンドウと最大出力トークンを千単位に丸めた3行の表が返ります（出力は省略版です。omp には thinking と images という列もあります）：

joingonka (3)
model                                context  max-out
deepseek-ai/DeepSeek-V4-Flash-0731      380K      33K
MiniMaxAI/MiniMax-M2.7                  200K     8.2K
zai-org/GLM-5.3-Flash                   390K     8.2K

次に、インターフェースなしの単発実行です。空のディレクトリに明らかなバグを含むファイルを置き、それを見つけるよう指示します：

omp -p "Read calc.py and tell me in one sentence whether it has a bug."

エージェントは自ら読み取りツールを呼び出し、バグのある式を具体的に示しながら本質的な回答をするはずです。2026年9月21日の検証では、このサイクル（リクエスト→ツール呼び出し→結果→回答）を DeepSeek V4 Flash と GLM-5.3 Flash が問題なく通過しました。MiniMax M2.7 については、下の表の最終行をご覧ください。

3つ目の確認はゲートウェイ側から行います。管理画面の「使用状況」セクションで、リクエストが「モデル別」の内訳に表示され、「キー別」ブロックで最終リクエスト時刻が更新されます。そこが空なら、omp は別のプロバイダーに接続しています。ロールに何が設定されているか omp config get modelRoles コマンドで確認してください。

問題が発生した場合、通常はエラーメッセージから原因が読み取れます：

エージェントツールはチャットとは異なるトークン消費をします。ompは各フレーズにシステムプロンプトとツール定義を追加し、タスクは通常数ターンのやり取りを必要とするためです。私たちの実行環境では、読み取りツールを1つ有効にしただけでも1ターンにつき約3,500入力トークンを消費しました。すべてのツールを有効にすればさらに増加します。そのため、ここでのトークン単価が重要になります。

JoinGonka Gateway経由の場合、トークン単価は入力100万トークンあたり$0.0069、出力100万トークンあたり$0.021です。この価格はネットワーク内の全モデルで共通であり、このページのライブソースから動的に反映されています。

右列の概算は2026年9月時点の価格に基づいています。参考までに、ompでのモデル支払い方法は以下の通りです：

ompのステータスバーにはセッションコストの概算が表示されます。これは models.yml の cost フィールドに基づいて計算されます。インストーラーがインストール時のゲートウェイ価格を記録しますが、ネットワーク内のドル建て価格はGNKレートに応じて変動するため、概算値として扱ってください。正確な消費量と残高は、管理画面の「利用状況 (Usage)」および「請求 (Billing)」セクションで確認できます。デフォルトでDeepSeek V4 Flashが選択されている理由は、モデルのレビューで詳しく解説しています。

承認モード。 デフォルトで omp は yolo モードで動作します。読み取り、書き込み、コマンド実行をすべて自動承認します。自分のプロジェクトでは便利ですが、他人のコードではモードを厳格化するか、コンテナに退避する理由になります：

omp config set tools.approvalMode write

write モードでは、エージェントはコマンド実行の許可だけを求め、always-ask では書き込みについても尋ねます。1回の実行に対しては --approval-mode フラグでも同じことを指定できます。これは omp 自体の性質であり、モデルプロバイダーには依存しません。

Pi と omp は設定が異なる親戚同士。 一方のツールの設定は他方に引き継がれません。ディレクトリ、フォーマット、フィールド名はそれぞれ独自です。

複数の環境。 名前付きプロファイル（omp --profile work または変数 OMP_PROFILE）は、すべての設定を ~/.omp/profiles/<name>/agent に移動します。仕事用と個人用のキーを分けるのに便利です。現在のエージェントディレクトリは omp config path で表示されます。

エディタ内でエージェントを使いたい場合。 omp は ACP プロトコルを介して Zed 内で動作できます。これは同じ設定の同じエージェントであり、プロバイダーとロールを再度設定する必要はありません。