Raw OpenAI Usage is broken in pi now.

[soliloqueen]

https://github.com/cortexkit/magic-context/blame/d576723637c9db07ac000f1804c8504ba85867c7/packages/plugin/src/shared/harness-provider-map.ts#L24-L31

If one has no codex subscription and uses ONLY the API directly (like me), subagent spawn fails with:

stderr: No API key found for openai-codex. Use /login to log into a provider via OAuth or API key. See:
C:\Users\Ari\AppData\Roaming\npm\node_modules\@earendil-works\pi-coding-agent\docs\providers.md
C:\Users\Ari\AppData\Roaming\npm\node_modules\@earendil-works\pi-coding-agent\docs\models.md```

[ualtinok]

Fixed on the working branch, shipping in the next release — and thanks for the blame link, it pointed at exactly the right lines.

You are right about the root cause: the shared config stores the OpenCode-canonical form (openai/<model>), and when spawning Pi subagents we unconditionally translated it to openai-codex/<model>. Pi legitimately has both providers, so the canonical form is ambiguous — Codex subscription vs direct API key — and we had hardcoded the subscription arm.

The fix keeps the translation as the first attempt (so existing Codex-subscription setups see no change), and when the child exits with the exact "No API key found for openai-codex" failure it retries once with the untranslated openai/<model>. The winning form is remembered for the rest of the process, so after the first spawn your setup goes straight to the direct-API form. Same handling for google/ vs google-antigravity/. No configuration needed on your side.