Have you given a custom provider a try for this? In general we're trying to move away from creating too many providers, and it seems this one should work pretty well with the openai format.

Manual Integration Test Results

Tested against live Tanzu AI Services endpoints on VMware Tanzu Platform (TAS). Both credential binding formats validated end-to-end.

Multi-Model Binding (tanzu-all-models)

Single-Model Binding (tanzu-qwen3-coder)

Binary Verification

Automated Tests

cargo test -p goose -- tanzu          # 24 tests pass (14 unit + 10 integration via wiremock)
cargo clippy -p goose -- -D warnings  # clean
cargo fmt -p goose -- --check         # clean

Notes

• The openai/gpt-oss-120b model on the multi-model endpoint returns HTTP 200 with token usage but an empty content field on some prompts — this is model-side behavior (Qwen3-Coder works perfectly on the same endpoint)
• Both credential formats (single-model with api_base/model_name and multi-model with endpoint-only) resolve correctly
• Bearer token (JWT) authentication works for all endpoints
• system_fingerprint: "tanzuAiServer" confirmed in all responses

Great question — and yes, the custom provider does work for the basic flow since Tanzu AI Services exposes an OpenAI-compatible API. I tested it and you can point a custom provider at {endpoint}/openai, set the JWT as the API key, and chat/streaming/tools all work.

That said, the dedicated provider adds meaningful value in a few areas that the custom provider can't cover:

1. VCAP_SERVICES auto-detection (Cloud Foundry)
This is the biggest one. On Tanzu Platform (Cloud Foundry), credentials are injected into apps via VCAP_SERVICES JSON. The dedicated provider parses this automatically — zero config needed. With the custom provider, every CF-deployed app would need to manually extract and configure credentials, which defeats the purpose of CF service bindings. This is the primary deployment model for our enterprise customers.

2. Credential format normalization
Tanzu has two binding formats — a legacy single-model format (where api_base includes /openai) and the newer multi-model format (where it doesn't). The dedicated provider handles both transparently. A custom provider user would need to know which format they have and construct the URL differently.

3. Capability-based model filtering
Tanzu's /config/v1/endpoint returns models with capability metadata (CHAT, TOOLS, EMBEDDING). The dedicated provider filters to chat-capable models automatically, so users don't accidentally select an embedding model.

4. Customer ease of use and recognition
We're investing more broadly in the Goose project and want to make the onboarding experience as smooth as possible for Tanzu Platform customers. Having tanzu_ai show up as a recognized provider — rather than requiring users to manually configure a custom provider with the right URL structure, path prefixes, and auth setup — significantly reduces friction. For enterprise users who may not be deeply familiar with OpenAI API conventions, the difference between "set 2 env vars and go" vs "create a custom provider JSON config with the correct base URL format" is meaningful.

thanks for the explanation. this is still a lot of code! that said, we want to work well with all providers especially the ones that invest in Goose. so:

VCAP_SERVICES auto-detection (Cloud Foundry)

this is true, but that is not specific to Tanzu, is it? so we could just add support for VCAP to the custom provider set up, no?

Credential format normalization

can you say more about this? does this mean the endpoint url depends on legacy or not? we have some primitive handling in the custom providers for this too, could expand?

Capability-based model filtering

we recently implemented recommended_models vs all models, does this not work for you use case? @katzdave is actually the person who put that together so let's make that work!

Customer ease of use and recognition

Ah yes, but you can add your custom provider to the canonical providers folder and then it will just show up in our provider list, just like all the other providers. 5 of our providers work that way already

so in short, we're excited to work with you to get Tanzu in, but would very much prefer it if we can make this work inside the canonical provider framework and just add options to it to make it fit. that way any provider in the future can work with VCAP

does that make sesne?

Thanks @DOsinga — this makes a lot of sense and I'm on board with the direction. I've dug into the declarative provider framework (declarative/*.json, DeclarativeProviderConfig, from_custom_config()) and I can see how Tanzu fits into it. Here's what I'm thinking:

Dropping VCAP_SERVICES and credential normalization

Our primary use case for Goose is desktop users connecting to Tanzu AI Services via an API key and endpoint URL — they won't be running Goose inside Cloud Foundry. So I'm happy to drop the VCAP auto-detection and credential format normalization from this PR entirely. That eliminates the bulk of the custom Rust code. For Goose agents running inside Cloud Foundry, we can wrap them with our own code on deployment to extract credentials from VCAP and set the right env vars. The real pain point we're solving is on the desktop side.

The declarative provider approach

With that simplification, Tanzu becomes a declarative/tanzu.json config — similar to Mistral, Groq, etc. The only difference is that Tanzu endpoints are per-customer (each organization has their own deployment URL), so we'd need a small framework addition: a base_url_env field on DeclarativeProviderConfig that reads the base URL from an environment variable instead of hardcoding it. This is generic and useful for any provider with per-customer deployments (self-hosted, private cloud, etc.).

Dynamic model fetching

The bigger gap is model discovery. Tanzu's available models vary per customer depending on their service plan — one user might have Qwen3-Coder only, another might have Qwen3 + gpt-oss-120b. A static model list in the JSON won't work well here. The dedicated provider currently calls /v1/models at runtime to discover what's available.

I'd propose extending the declarative framework so that OpenAI-engine providers can optionally fetch models dynamically from the API's /v1/models endpoint, rather than relying solely on the static list. This would also benefit other declarative providers that support a broad or changing model catalog. @katzdave would appreciate your thoughts on how this fits with the recommended_models work.

Proposed plan:

1. Add base_url_env support to DeclarativeProviderConfig (~10 lines of Rust)
2. Add dynamic model fetching for OpenAI-engine declarative providers via /v1/models
3. Add declarative/tanzu.json config
4. Remove the dedicated tanzu.rs provider, registry entries, and Tanzu-specific tests

Happy to split this into separate PRs (framework extensions vs Tanzu config) or combine — whatever works best for your review process.

this sounds great. and again, adding VCAP_SERVICES to the custom providers doesn't seem like a crazy idea.

one thing we could do, is just support environment variable replacement in custom providers, maybe have a list of which ones you want and their defaults? that would make everything in there configurable

dynamically fetching the models is I think at least somewhat supported, so yeah that would be great too

looking forward to this!

Rebased onto latest main and resolved merge conflicts:

• declarative_providers.rs — Merged both upstream's new catalog_provider_id/base_path fields alongside our env_vars/dynamic_models fields
• provider_registry.rs — Adapted to upstream's removal of allows_unlisted_models (all providers now allow custom model entry by default), and added the new primary parameter to ConfigKey::new()
• init.rs — Removed test assertion on the now-deleted allows_unlisted_models field
• ui/desktop/src/api/index.ts — Took upstream's latest auto-generated version

All checks pass:

• cargo check -p goose ✓
• cargo check -p goose-server ✓
• cargo clippy -p goose -- -D warnings ✓
• All 9 Tanzu-related unit tests pass ✓

Rebased onto latest main and resolved merge conflicts — all CI checks are passing now.

On a personal note, glad to see you both still here and active on this @DOsinga @blackgirlbytes. Sorry to hear about the layoffs 😢 — hope you and the rest of the team are doing okay.

thanks! and yeah we got somewhat impacted, but goose is still here