# Pi Subagents Using the Wrong Provider: How to Lock Model Routing

Feynman 0.5.66 fixes silent provider fallback, but preventing unexpected paid calls also needs an enforced model policy.

By Paras Madan | 2026-11-09

If Pi subagents use a paid provider while your main agent runs locally, check both model routing and model permissions. Feynman 0.5.66 bundles a fix for silent provider fallback, but that fix does not stop a subagent from explicitly requesting a different paid model.

This distinction matters in review loops. The parent can be inexpensive while repeated child calls consume a separate account's credits. A local model in the main conversation tells you very little about the cost of the whole workflow.

## What Feynman 0.5.66 actually fixes

The [November 8 Feynman release](https://github.com/Companion-Inc/feynman/releases/tag/v0.5.66) bundles pi-subagents 0.87.0. A qualified model such as `anthropic/claude-opus-4-8` must stay on the named provider rather than silently resolving to another provider's copy. If the requested model is unavailable on that provider, the launch fails; when a matching alternative exists, the error can name it without using it.

The underlying [user report](https://github.com/nicobailon/pi-subagents/issues/3203) described a local-model review workflow that selected an Anthropic model and reached an OpenRouter copy. The maintainer confirmed a resolver bug. That is evidence of a specific failure path, not proof that every unexpected charge has the same cause.

**Correct routing and permission to spend are separate controls.** After the fix, an explicit request for an OpenRouter model can still be valid unless your model policy rejects it. Updating the package closes the accidental substitution; it does not make the parent model a mandatory choice for every child.

## Upgrade the Feynman core, not just its packages

Feynman's [installation guide](https://feynman.is/docs/getting-started/installation/) makes an easy-to-miss distinction: `feynman update` updates optional Pi packages, not the core bundled dependencies. Use the original installation method to upgrade the core. For an npm installation, the documented command is:

```bash
npm install -g @companion-ai/feynman@latest
```

The relevant bundled release is 0.5.66. Check your installed version rather than assuming an optional-package update brought in the resolver fix.

## Check the model Pi actually loaded

The [versioned model documentation](https://github.com/nicobailon/pi-subagents/blob/v0.87.0/docs/models.md) provides two useful inspection commands:

```text
/subagents-models
/subagents-models reviewer
```

Run these before starting another long review chain. They show the live mapping, which can differ from the settings file until Pi is reloaded. Check the provider as well as the model name, particularly when the same model is available directly and through a routing service.

A per-run override has higher precedence than a provider-scoped role override, an ordinary role override, agent frontmatter, the subagent default and finally the parent model. Setting only `subagents.defaultModel` therefore cannot guarantee that a reviewer stays on that model. A more specific setting can win.

Use fully qualified provider/model identifiers when you intend a particular billing destination. Bare model IDs can need disambiguation, and `defaultProvider` is a preference for resolving those IDs rather than an allowlist.

## Keep children on the current parent model

Merge the following into the appropriate settings file rather than overwriting unrelated settings. [Feynman's configuration guide](https://feynman.is/docs/getting-started/configuration/) places user settings at `~/.feynman/agent/settings.json`; a custom `FEYNMAN_HOME` changes that location. Standard Pi uses `~/.pi/agent/settings.json` for user settings and `.pi/settings.json` for project settings. Do not edit the Pi path and assume Feynman will read it.

```json
{
  "subagents": {
    "agentOverrides": {
      "reviewer": {
        "model": "inherit"
      }
    },
    "modelScope": {
      "enforce": true,
      "strict": true,
      "allow": ["inherit"]
    }
  }
}
```

This is a worked policy example, not a live billing test. The reviewer override selects the parent model. The scope rejects a resolved model outside that allowed choice. If another role has a conflicting model in its configuration, the policy should reject its launch rather than quietly choosing something cheaper.

Both enforcement flags matter. With enforcement enabled but strict mode off, out-of-scope models coming from configuration or inheritance can warn and remain available. Strict mode rejects those too. The allowlist is checked against the resolved provider/model, so it addresses the destination that would actually run.

The word `inherit` means the immediate parent's current model at launch. It does not permanently mean "local" or "free." If you switch the parent to a paid model, this policy permits that model for its children. For a fixed provider boundary, use exact permitted provider/model IDs from your registry instead.

## Check project settings before trusting the restriction

Project settings take precedence over user settings. More importantly, a trusted project's `modelScope` replaces the complete user scope rather than automatically tightening it. Read the effective project configuration before assuming a user-level allowlist still applies.

Agent-specific allowlists can narrow the global policy: a model must pass both lists. A configuration containing only named-agent restrictions does not automatically restrict every other role. For a local-only workflow, start with a global restriction and deliberately add exceptions, rather than assuming a reviewer rule covers researchers and workers too.

Reload Pi after editing settings, inspect the live mapping again and check the provider's own usage records for earlier activity. Model selection evidence helps explain a charge, but the provider's billing record is what establishes the amount. Avoid running a paid probe merely to prove the old problem existed.

## A model allowlist is not a monetary cap

The fixed resolver returns errors from the selected model, including rate-limit failures, rather than silently switching providers. A parent or operator can issue a later explicit launch with another model; an enforced scope is what determines whether that different model is permitted.

Even an allowed model can generate a large bill through repeated calls. Use provider-side spending controls where available and bound review loops separately. The practical goal is to make an expensive fallback a visible decision before execution, not something discovered while reconciling an invoice.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn complex developer tools and AI workflows into clear technical stories that people can use and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).