[salman1993]

Why

Goose and Pi can each use several inference providers, so today a user signs in to Databricks separately for each harness. provider-plugins-exploration.md proposes one shared provider plugin that owns sign-in and model discovery, while each agent plugin keeps its own inference code. This PR implements that doc's first two slices: one Databricks connection, used by both Goose and Pi agents.

What

• A bundled buzz.databricks plugin adds Settings → Providers → Databricks. It signs in to Block's Databricks workspace in the browser, stores credentials privately, refreshes tokens, and lists models along with the gateway routes each one serves.
• Goose agents can choose Databricks in Buzz and one of nine verified models in their provider dialog or Settings tab: GPT-6 Sol/Luna/Astra, GPT-6.1 Sol, Claude Opus/Sonnet/Haiku 5.5, GLM 5.3, and Grok 4.7. Goose's model now shows in New agent's Model field, which follows main's Streamline agent creation and library controls #966.
• Pi agents get Databricks in Buzz as the first entry in their provider list. They sign in through the Databricks connection instead of an API key. Claude models run on Anthropic Messages; other families run on OpenAI Responses. Gemini and models that only have a Chat route are not offered.
• The shared OAuth callback host gains an opt-in localhost callback host and a bare-origin path. The databricks-cli OAuth client only accepts http://localhost:{port}.

How

Shared plugin

• Credentials never reach the renderer, Goose's config, or Pi's auth.json. They live in Buzz's local data directory, at providers/databricks/credential.json (folder 0700, file 0600). A file lock serializes token refresh across Buzz and every agent process.
• The catalog lists ready endpoints that support tool calls and AI Gateway v2, with every route each one serves (apis). Agent plugins filter those routes. The plugin also gives agents the token helper: the Buzz binary run with --databricks-provider-token, which prints a fresh access token and exits before the app starts. The helper refreshes a token 60 seconds before it expires.

Goose

• Goose's native Databricks adapter cannot take an external token, so Buzz writes a Goose custom provider (custom_providers/buzz_databricks.json) with command auth that runs the helper.
• Goose still owns request formatting, streaming, and history. The provider file uses the gateway's Responses route (ai-gateway/mlflow/v1/responses). The Chat route rejects reasoning effort alongside tools for GPT-6 models, and GPT-6.1 Sol always requires one. With Responses, the user's Goose thinking effort still applies.
• The model list is an allowlist in src/bundled/goose/shared-provider.ts, limited to models the catalog says serve the Responses route. Gemini fails on Goose's stream_options, and Gemma rejects minimum in a tool schema, so neither is offered.

Pi

• Buzz does not load Pi packages, so Pi's host registers the provider with pi-ai itself instead of loading pi-databricks. It copies that extension's routes and gateway compatibility settings, including dropping Responses item IDs longer than 64 characters.
• The plugin maps the catalog to a binding (src/bundled/pi/shared-provider.ts). The host asks for it with a new host→plugin provider call: when the provider is first needed, and again each time it lists that provider's models, in case the user signed in or the catalog changed. Pi's own providers never need this call.
• Context windows, output limits, and thinking levels come from Pi's built-in model with the same canonical name. Each request runs the helper, which then serves requests for the next 30 seconds.
• Pi still owns request formatting, streaming, and history.

Risk

Medium, for a prototype. This PR targets sm/goose-agent-plugin (#1096) and merges in the Pi branch (#1103), so the diff includes #1103's commits until that PR lands. Pi stays off by default.

The OAuth callback change is opt-in, so existing callers (hosted communities, builderlab) keep 127.0.0.1 and their own paths. The Databricks plugin is enabled by default and points at Block's workspace, which needs a decision before this stops being a prototype.

Testing

On this head (db09d64e2)

• Typecheck, biome, clippy, and pre-push hooks pass. Vitest passes across src/bundled, src/features/providers, and src/features/agents: 2,760 tests.
• Rust tests cover the catalog's route filtering, the helper op, and Goose rejecting a model without the Responses route.
• New unit tests:
  • sharedBinding routes each model, and returns nothing for Pi's own providers.
  • The Pi transport answers the host's provider call.
  • In the Pi provider dialog, Databricks in Buzz shows the shared sign-in instead of a key field, asks Pi for no models while signed out, and saves the chosen model after sign-in.
• Pi host live test (host.live.test.ts, run locally with PI_DEPS pointing at Pi's installed packages): the real host and pi-ai 1.1.0 ran against a fake local gateway and a fake token command.
  • Claude went to /ai-gateway/anthropic/v1/messages?beta=true, and o3 to /ai-gateway/openai/v1/responses. Both used Authorization: Bearer <token> with no x-api-key.
  • Thinking levels were borrowed from Pi's models.
  • One helper run served three requests.

From the Goose prototype commits (carried into this branch; not rerun on this head)

• Live sign-in (native flow): a temporary #[ignore] Rust test (since removed) ran authorize, the callback host, connect, and models against the real workspace. Databricks accepted redirect_uri = http://localhost:62166, and discovery returned 57 models.
• Token helper: --databricks-provider-token exited 0 and printed one token.
• Model matrix: real goose run called a stubbed Buzz send tool with all nine models, each loaded with Buzz's 12 tool schemas and the developer tools, with GOOSE_THINKING_EFFORT: medium. All nine passed.

Not yet done

• Running the app from this head: signing in through the UI, then the Goose and Pi provider dialogs.
• Pi turns against the real gateway: Claude on Anthropic Messages and GPT on Responses, including tool calls, compatibility settings, and long item IDs.
• A Goose agent and a Pi agent replying in a Buzz channel on one connection.
• History after restart, and continued work after a token refresh in a long session.
• Linux and packaged builds. An independent review. Human acceptance.

Bigger picture

OpenRouter can follow the same boundary. Known gaps:

• A revoked refresh token still shows "Connected" until sign-out.
• All Buzz builds on a machine share one connection.
• Pi offers every catalog model on a supported route without verifying each one, unlike Goose's allowlist.

🤖 Generated with Claude Code

[salman1993]

this PR was a prototype to see if a provider plugin architecture made sense which could be shared among agentType plugins like goose and pi where you can configure many providers. also applicable for MeshLLM (Shared Compute).

TLDR:

• Mic’s shipping shared compute / mesh as an “agent type” - basically a harness plugin. Like Claude, Codex, or Goose. He demoed that and it’s a nice experience.
• We discussed separating providers from agent types (ie, Databricks or Jev) and agreed that’s a “maybe later” thing, that it most likely looks like some way of serving credentials to plugins with permission but it's not a priority at all to solve in the next month.
• Also called out the need for clarity around plugin contracts, what we’re promising if anything.