Context
We run a workspace plugin that pools multiple accounts for providers outside the Account Pooler builtin's closed set (Devin, Grok, OpenCode). Stock BB 0.43.3's pooler is hard-wired to claude + codex (providerSchema z.enum(["claude","codex"])), so extended lanes currently can't exist without forking the builtin bundle. Two narrow API asks would let third-party poolers live beside the builtin on published surface only.
Ask 1 — provider lanes as data
The builtin pooler's provider list, routing map and per-provider adapter contract are closed enums/constants. A plugin can already contribute env via experimental_contributeEnv, but there is no published way to:
- declare "this provider's lane is served by plugin X" in a way the routing/status surfaces understand,
- reuse the builtin's quota-window / hold / affinity model for a non-stock provider.
If the pool provider set were data (registered adapters keyed by provider id, like the provider registry itself), a workspace pooler could pool any provider without a bundle patch.
Ask 2 — a refuse-capable env contract
experimental_contributeEnv(providerId, resolver) resolvers cannot refuse thread startup: there is no way to say "no eligible account — fail this thread now." The only fail-closed shape available is contributing a deliberately-invalid token so the vendor 401s, which works but turns "the pool is empty" into an in-band auth error instead of an explicit refusal.
A released contract where a resolver can refuse (or mark contributed env as required so its absence fails thread start visibly, before spawn) would let poolers fail closed without poisoning requests. The unreleased required-env work that existed on main earlier this year is exactly the shape needed.
Notes
- We are not asking for the extended lanes themselves upstream — only the two contracts that let a plugin own them.
- Happy to provide the failing-state captures (0.43.3, plugin SDK 0.4.104, host protocol 215) if useful.
Context
We run a workspace plugin that pools multiple accounts for providers outside the Account Pooler builtin's closed set (Devin, Grok, OpenCode). Stock BB 0.43.3's pooler is hard-wired to
claude+codex(providerSchema z.enum(["claude","codex"])), so extended lanes currently can't exist without forking the builtin bundle. Two narrow API asks would let third-party poolers live beside the builtin on published surface only.Ask 1 — provider lanes as data
The builtin pooler's provider list, routing map and per-provider adapter contract are closed enums/constants. A plugin can already contribute env via
experimental_contributeEnv, but there is no published way to:If the pool provider set were data (registered adapters keyed by provider id, like the provider registry itself), a workspace pooler could pool any provider without a bundle patch.
Ask 2 — a refuse-capable env contract
experimental_contributeEnv(providerId, resolver)resolvers cannot refuse thread startup: there is no way to say "no eligible account — fail this thread now." The only fail-closed shape available is contributing a deliberately-invalid token so the vendor 401s, which works but turns "the pool is empty" into an in-band auth error instead of an explicit refusal.A released contract where a resolver can refuse (or mark contributed env as required so its absence fails thread start visibly, before spawn) would let poolers fail closed without poisoning requests. The unreleased required-env work that existed on main earlier this year is exactly the shape needed.
Notes