models.json validation requires redundant apiKey for custom providers even when auth.json already has credentials

[ssdiwu]

Summary

When defining custom providers in ~/.pi/agent/models.json, pi requires an apiKey field at validation/load time even if valid credentials for that provider already exist in ~/.pi/agent/auth.json.

This makes auth.json insufficient as the actual source of truth for provider credentials, and forces users to duplicate auth state in models.json using a fake/sentinel apiKey value just to pass schema validation.

This appears related to:

• models.json: adding custom models to an already-authenticated provider requires redundant apiKey with unhelpful error #2955
• models.json: adding custom models to an already-authenticated provider requires redundant apiKey with unhelpful error #3043
• Provider auth status treats placeholder API key as usable models.json key #5204

Problem

The docs say credentials can come from:

1. CLI --api-key
2. auth.json
3. environment variable
4. custom provider keys from models.json

But for custom providers defined in models.json, pi fails early unless apiKey is present in the provider config itself.

Example error:

Failed to load models.json: Provider digitflowai: "apiKey" is required when defining custom models.

This happens even when auth.json already contains:

{
  "digitflowai": { "type": "api_key", "key": "..." }
}

Reproduction

auth.json

{
  "ollama-cloud": {
    "type": "api_key",
    "key": "real-secret"
  }
}

models.json

{
  "providers": {
    "ollama-cloud": {
      "api": "openai-completions",
      "baseUrl": "https://ollama.com/v1",
      "models": [
        { "id": "glm-5.2" }
      ]
    }
  }
}

Actual result

pi refuses to load models.json because apiKey is missing in the provider config.

Workaround

Add a fake placeholder:

"apiKey": "from-auth-json"

Then pi loads successfully and uses the real key from auth.json at request time.

Why this is a problem

1. It makes users duplicate auth state conceptually across two files.
2. The placeholder is not real auth, but it must exist just to satisfy validation.
3. Placeholder keys can create confusing UX / auth-status semantics (see Provider auth status treats placeholder API key as usable models.json key #5204).
4. It conflicts with the documented resolution order where auth.json is a first-class credential source.

Expected behavior

If a provider already has credentials in auth.json, models.json should not require a redundant apiKey field just to define custom provider models.

At minimum, one of these should happen:

Preferred

Skip the apiKey validation requirement when stored auth exists for that provider.

Acceptable fallback

Keep the requirement, but make the error actionable and explicitly say:

• auth.json is not currently considered by validation
• users must add a placeholder apiKey field
• runtime auth will still come from auth.json

Suggested fix

During models validation/loading, check whether auth already exists for the provider before enforcing apiKey presence.

Something like:

• if provider defines custom models
• and provider has auth in auth.json
• allow missing apiKey in models.json

Real affected custom providers in my setup

• ollama-cloud
• digitflowai
• yairouter
• volcengine-coding

Environment

• pi version: 0.79.9
• config dir: ~/.pi/agent
• affected files:
  • models.json
  • auth.json

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open.

See CONTRIBUTING.md.

[mitsuhiko]

Fixed in the local change.

The models.json loader no longer requires provider-level apiKey for non-built-in custom providers. It still requires baseUrl and API information, and auth resolution remains runtime-based: --api-key, auth.json, then provider request config. Custom providers without any configured auth load but remain unavailable until credentials are configured.

Validation run:

• cd packages/coding-agent && node node_modules/vitest/dist/cli.js --run test/model-registry.test.ts
• npm run check

This comment is AI-generated by /wr

[ssdiwu]

Thanks @mitsuhiko , this fully matches what I was hoping for.

Removing the hard apiKey requirement at load time and keeping auth purely runtime (--api-key → auth.json → provider request config) is actually cleaner than the "check auth.json during validation" alternative I originally proposed — it avoids coupling the models.json validator to credential state, which felt like the wrong layer.

Appreciate the quick fix and the test run.