対応プロバイダー

runtimeごとの対応範囲

現行のLLM providerはAnthropicとOpenAIの2つです。models.<name>.providerが受け付ける値もanthropicとopenaiだけです。GitHubはrepository連携であり、LLM providerには含めません。

対応範囲。 1つのlocal runでAnthropicとOpenAIをstep単位に混成できます。managed runでproviderを混成することはできません。

最初はinitで1つ選ぶ

TTYではproviderを質問し、未指定のnon-TTYではAnthropicを選びます。initはlocal-defaultのscaffold専用で、既存global configがあれば上書きしません。

# Anthropic local
npx specrunner init --provider anthropic

# OpenAI local
npx specrunner init --provider openai
codex login

--runtimeはinitの選択肢ではありません。 init --runtime localとinit --runtime managedは現在argument errorです。managedはlocal scaffoldとは別にmanaged setupで構成します。

built-in registryにあるmodel

registry登録と利用権限は別です。 built-inにあるmodelでも、契約・account・SDK側で利用できるとは限りません。SpecRunnerのregistryはproviderへのroutingとconfig validationを行い、provider側のentitlementはrun時に決まります。

価格表はmodel registryと別管理です。対応modelでも価格が不明、または価格だけ登録されていてbuilt-in modelではない場合があります。詳しくはコスト目安と計測を参照してください。

localはeffective modelでstepごとに振り分ける

local runtimeは各stepのeffective modelをmerged registryで解決し、AnthropicならClaude runner、OpenAIならCodex runnerへ渡します。

{
  "version": 1,
  "steps": {
    "defaults": { "model": "claude-sonnet-4-6" },
    "design": { "model": "gpt-5.5" },
    "code-review": { "model": "gpt-5.4" }
  }
}

npx specrunner config effective --type spec-change
npx specrunner doctor

OpenAI runnerは最初のOpenAI stepで初めて読み込まれるため、未準備でもAnthropic stepまでは進めてしまう可能性があります。

managedはAnthropicの登録済みagentを使う

runtime: managedではAnthropic Managed Agents APIを使い、managed setupが登録したagent IDとenvironment IDを参照します。

export SPECRUNNER_API_KEY=...
npx specrunner managed setup
npx specrunner managed status
npx specrunner doctor

managedのAPI key、GitHub token、environmentの準備は権限・認証・環境変数を参照してください。

custom modelはproviderを明示して追加する

built-inにないmodel名はそのままではCONFIG_INVALIDです。modelsへ追加すると、指定providerのlocal runnerへroutingされます。

{
  "version": 1,
  "models": {
    "provider-model-id": { "provider": "anthropic" }
  },
  "steps": {
    "implementer": { "model": "provider-model-id" }
  }
}

built-in mappingの上書きは慎重に行います。 user registryはbuilt-inより優先します。同じmodel名を別providerへ割り当てると、その文字列が別SDKへ渡るため、通常は新しい実model IDを追加します。

providerごとに認証経路が違う

1. 01
   effective config

   対象request typeで各stepのmodelを解決します。

2. 02
   credential

   使うproviderだけでなく、混成時は両方の認証を確認します。

3. 03
   doctor

   CLI・token・managed resourceのrequired failureを解消します。

4. 04
   small run

   最初の1件は小さいrequestでprovider dispatchとusage記録を確認します。

対応表だけでは保証されないこと

実行条件。 config effective --type、provider認証、doctor、小規模runの4点が揃ってから本番requestへ進みます。