Latest in AI
Magpie Provider Plugins: What Changes for Accounts and Extensions
Magpie moves eleven provider integrations into plugins and adds interface extensions, with account migration steps and different trust boundaries for pages and provider code.
Magpie's October 17 releases move eleven built-in provider integrations into plugins and let extensions add panels, row actions and replacement pages. For developers using its local model gateway, the change affects both account migration and how much access a plugin needs to handle their requests.
These changes shipped across several versions. Version 0.1.1282 moved the providers, while 0.1.1285 expanded the interface. By October 19, the latest published release was 0.1.1292. The plugin changes are an upgrade sequence, rather than a single new version with all those features.
Which provider accounts need attention?
The retired built-in integrations cover Command Code, Devin, Grok, Factory, ZCode, Xiaomi MiMo, WorkBuddy, Qoder, Cursor, Kiro and Zed. Their corresponding plugins now serve those connections. Magpie enables its built-in plugins by default, including on new installations.
Accounts that have not moved receive a Move option when the corresponding plugin is available. The release also reduces the retry interval for failed moves from six hours to ten minutes. An existing sign-in is therefore worth checking after an upgrade, even if the application itself opens normally.
A useful migration check is to inspect the intended provider account, select a model you already use and send a small request through the same agent. That establishes whether the route still works in your setup without assuming that a successful application update also completed every account migration.
Extensions can change the interface
Version 0.1.1285 lets plugin pages add actions to provider and agent row menus, insert panels into Magpie's pages and replace selected built-in pages. Titles can follow the window's language, and panels use the application's visual styling.
The tagged plugin documentation limits each plugin to eight panels and eight menu items. Replacement pages can take over Sessions, Library, Routing or Usage; disabling the plugin restores the original page.
For a team with its own provider tooling, this creates room for a more relevant interface. A custom usage view or provider action could sit beside the workflow where it is needed. Those are possible uses of the extension points, not features that every installed plugin already supplies.
A sandboxed page is only one part of plugin trust
Plugin pages run in sandboxed frames and use a restricted bridge for approved reads. Those reads omit credentials, sign-in details and request bodies. Provider plugin code has a different role: it runs through Bun and can see the conversations, tools and results in the requests it handles.
This is the important boundary when reviewing an extension. A harmless-looking panel does not establish that every component in its package has equally limited access. Review who maintains the provider code and where it sends data before using it for private repository or customer work.
The README describes Magpie as a local gateway between agents and providers. It can discover existing subscription sign-ins, and offers a setting to turn that discovery off. That behavior deserves attention during setup because the set of accounts the app can find may be broader than the accounts intended for one workflow.
Check routing behavior and provider terms
Version 0.1.1283 also gives provider middleware context about the selected destination. The tagged documentation says the onProvider hook runs after routing and cannot reject or reroute the request. Developers building an extension should choose the hook that actually supports the behavior they need.
Magpie is MIT licensed, with desktop and terminal-only packages for supported Windows, Linux and macOS targets. Its local gateway does not remove upstream usage charges or change a provider's account terms. Check those terms separately when considering how an existing subscription or API account will be used.
For existing users, the first priority is confirming the migrated account and route. For extension developers, it is defining the smallest amount of interface and request access the plugin needs. Those checks are more useful than judging the upgrade by the number of integrations listed.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help developer-tool teams explain integrations, architecture changes and technical launches through clear writing and founder-led distribution.