Oh My Pi

~/.omp/agent/models.ymlのプロバイダーブロック — baseUrl、api、apiKey — でOh My PiをKunavoに接続し、GET /v1/modelsからモデル一覧を自動取得します。

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1
    api: openai-completions
    apiKey: KUNAVO_API_KEY       # an env-var name; literal text also works
    discovery:
      type: openai-models-list   # reads GET /v1/models

# Prefer a fixed list to a discovered one? Drop the discovery block and
# declare ids instead. Omitted metadata defaults to a 128,000-token context
# window and a 16,384-token output limit, so set the real numbers from
# /models when they differ.
#
#     models:
#       - id: claude-sonnet-5
#         name: Claude Sonnet 5
#         contextWindow: ...
#         maxTokens: ...

手順

1. /app/keys でキーを作成してコピーします。キーは一度だけ表示されます。
2. ompを起動するシェルでKUNAVO_API_KEYとしてエクスポートします。ompはまずapiKeyを環境変数名として解決し、見つからない場合は文字列をキーそのものとして扱います。そのため、変数名を誤って入力しても気付かないまま読み込まれ、最初のリクエストで失敗します。!で始まる値は代わりにシェルコマンドとして実行されます。これは1Password形式の方法です。
3. 上記のブロックを~/.omp/agent/models.ymlに記述します。ここでのプロバイダーID — kunavo — は任意に選べ、すべてのセレクターの前半部分になります。
4. omp models kunavoを実行してファイルを読み込み、このプロバイダーだけを一覧表示します。YAMLまたはスキーマに問題がある場合は、models.yml validation failedと失敗したフィールドが表示されます。omp models refresh kunavoを指定すると、キャッシュ済みのカタログを使わずに新たに検出リクエストを行います。
5. 正確なセレクターで動作を確認します。omp -p --model kunavo/claude-sonnet-5 "Reply with only OK"。次にompを起動し、/modelと入力して、使いたいIDをDefaultに設定します。モデルハブを開くとmodels.ymlが再読み込みされます。/switchが変更するのは現在のセッションだけです。

ompのProvidersページで2026年9月21日に確認しました。サードパーティの設定は変更されます。ここに記載されたフィールド名が表示内容と一致しなくなった場合は、このページではなく、そのページを正しい情報源としてください。

クライアントをデバッグする前に確認すること

1回のリクエストで、失敗の原因がエンドポイント、キー、設定ファイルのどれかを特定できます。これがJSONを返すなら、同じベースURLとキーがOh My Piで機能します。

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

フィールドに入力するモデルID

すべてのテキストモデルにはモデルIDでアクセスできます。現在の一覧はGET /v1/models、価格付きのカタログはモデルページにあります。料金は100万トークンあたりのUSDで、入力 / 出力の順です。

モデル検出：どのタイプを使うか、モデル選択欄に何が表示されるか

ompには6種類のdiscovery.typeがあり、そのうち2つはゲートウェイに適しているように見えますが、使えるのは1つだけです。proxyは「各モデルの行でsupported_endpoint_typesを通知する、OpenAI/Anthropic混在プロキシ」向けとされ、そのフィールドに基づいて各モデルのワイヤ形式が決まります。KunavoのGET /v1/modelsではこのフィールドを公開していないため、proxyではすべてのモデルがプロバイダーレベルのapiにフォールバックするか、未設定なら除外されます。「汎用のOpenAI互換GET /v1/modelsエンドポイント」と説明されているopenai-models-listを使ってください。そのため、上記の設定にはapi: openai-completionsを指定しています。ompの規則では、「proxyを除き、検出にはプロバイダーレベルのapiが必要」です。

モデル選択欄を開く前に、知っておきたい点が1つあります。Kunavoのモデル一覧には、有効になっているカタログ全体が表示されます。そのため、検出したプロバイダーにはチャットモデルとともに画像、動画、音楽のIDも表示されますが、チャット用の通信方式ではこれらを呼び出せません。チャットモデルではKunavoがcontext_lengthを公開しており、モデルに関するドキュメントによると、ompの汎用検出はmax_model_lenの後でこのフィールドを読み取ります。一方、メディアモデルではこれが省略されるため、実際の値ではなくompのデフォルトである128,000トークンとして扱われます。短く正確なモデル一覧が必要なら、検出ブロックを削除し、実際に使う3～4個のIDを宣言してください。

ompはanthropic-messagesにも対応しており、Kunavoは/v1/messagesで応答します。この組み合わせの設定ブロックはこのページには掲載していません。ここで引用する2つのページでは、OpenAI互換ルートのベースURL形式は確認できますが、Anthropicルートで末尾の/v1がどう扱われるかは説明されていません。設定ブロックは読者がそのまま貼り付けられることが目的です。この方法を使う場合、Anthropic互換エンドポイントでツール呼び出しが400エラーになるときの対処法として、ドキュメントではdisableStrictTools: trueを指定するよう案内しています。