Feat/configurable api base url

[buhagee]

Feat/configurable api base url- #149

feat(providers): add configurable API base URL for Go and Zen providers

---

📝 What does this change?

Adds opencodego.apiBaseUrl and opencodezen.apiBaseUrl settings so the extension can point at any compatible gateway instead of the hardcoded opencode.ai endpoints. The extension derives the /chat/completions, /messages, /responses, /models, and (Go only) /usage routes from the configured base URL and applies them across every provider path (normal chat, Agents window variants, inline completions, usage sync). Missing or malformed values fall back to the defaults.

Custom URLs are normalized and validated — non-http(s), embedded credentials, query strings, and hashes are rejected via normalizeApiBaseUrl(). Includes unit tests for URL normalization, route construction, and the custom usage endpoint.

🧪 How did you test it?

• Verified against a real gateway GET /models returns 200 with a valid model list; POST /chat/completions is reachable and enforces auth (401 with a deliberately invalid key).
• Confirmed an end-to-end chat request through the custom URL works in the extension.
• Unit tests for the new URL helpers and custom usage endpoint all pass.
• Full suite: 278/279 pass — the single failure is a pre-existing Windows-only isCwdInWorkspace path assertion, unrelated to this change.

✅ Checklist

• npm run compile passes
• npm run lint passes
• npm test passes (278/279; one pre-existing Windows-only failure unrelated to this change)
• npm run package produces a VSIX
• I tested it works
• I updated docs/CHANGELOG if needed (README + CHANGELOG updated)

[ltmoerdani]

Nice one on this @buhagee. Configurable base URL is genuinely useful, and the validation (rejecting embedded credentials, query strings, hashes) is a good call.

I built the branch locally and ran the suite: 279/279 pass on macOS, which matches your note about the Windows-only one.

One thing I'd flag before merge, and it's a functional regression rather than a nit:

In activate(), the Agents-window providers are now built with providerVariant(goDefinition, AGENT_GO_VENDOR, ...), but providerVariant() doesn't carry isAgentVariant / baseVendor. The previous code used
PROVIDERS[AGENT_GO_VENDOR], which set both manually ({ ...providerVariant(...), isAgentVariant: true, baseVendor: GO_VENDOR }).

provideLanguageModelChatInformation() checks this.definition.isAgentVariant to decide whether to emit the targetChatSessionType: "copilotcli" entry (extension.ts:3003). Without it, the agent providers now return plain general
models, so the OpenCode models drop out of the Agents-window picker (the whole point of #39 / #42 / #125). The model family key also shifts to opencodego-agent-..., and the key-persist branch at extension.ts:2922 now runs for agent providers too.

Quick fix, same shape as the existing record:

const agentGoProvider = new OpenCodeProvider(context, {
  ...providerVariant(goDefinition, AGENT_GO_VENDOR, "OpenCode Go (Agents)"),
  isAgentVariant: true,
  baseVendor: GO_VENDOR,
});

A few minor things while we're here:

• PROVIDERS[AGENT_GO_VENDOR] / PROVIDERS[AGENT_ZEN_VENDOR] become dead after that change, nothing reads them anymore. Could drop them.
• usageUrl on the provider definition is set but never read; the actual override flows through resolveUsageUrl in goUsageTracker. Worth wiring it through or removing the field.
• A small test asserting the agent definition keeps isAgentVariant / baseVendor (and that the URLs follow the configured base) would have caught this early.

Happy to test again once it's updated.

[buhagee]

Thanks for catching this @ltmoerdani. Fixed in commit 3bcce3e.

Agent providers now preserve isAgentVariant: true and baseVendor while inheriting the configured base-provider URLs, so they continue to appear in the Agents-window picker with the correct copilotcli target and model family.

I also removed the unused usageUrl/dead provider entries and added regression coverage for the agent metadata and configured endpoints.

TypeScript and ESLint checks pass. The full suite reports 279/280 passing; the remaining failure is the existing Windows-sensitive isCwdInWorkspace subfolder test.

[ltmoerdani]

Thanks for the quick fix on the agent metadata @buhagee. I re-ran it and the logic is good now, compile clean and 280/280 on macOS.

One thing before merge: the CI build is red. The code is fine, the failure is in the Prettier step of lint. Three files fail prettier --check:

• README.md (the settings table needs realigning after the two new rows)
• src/agentProvider.ts
• src/test/config.test.ts

npx prettier --write on those three fixes it. Running npm run format:prettier before pushing keeps the formatting check green.

Let me know once it's pushed and I'll re-run the build.

[xianhongtao]

Why?
In my opinion. This extension should and only focus on OpenCode Go Gateway.
Allow configurable API base URL will increase complexity and gain no profit.

If you need to use other providers. Why not use BYOK method or Build another extension?

I mean, this extension is already a mess. I don't want more.

[xianhongtao]

@ltmoerdani Don't merge everything bro.

[ltmoerdani]

Hey guys,

@xianhongtao thanks for flagging the scope question, and for keeping the vision of this extension focused. You're right that VS Code's native BYOK already has a Custom Endpoint provider. It handles Chat Completions, Responses, and Messages, lets you set a custom base URL, apiKey, requestHeaders, even auto-discover the model list. So for the "just talk to another gateway" case, nothing new is needed here. I agree this extension should stay an OpenCode Go and Zen provider, not a generic gateway client.

The one case where this PR makes sense is narrower: you want the things this extension adds on top of the gateway, like Go usage tracking and pricing, per-model thinking controls, model metadata and limits from models.dev, the Agents window variants, and the vision proxy, but pointed at your own gateway or proxy. Native BYOK gives you none of that, it's a bare connection.

@buhagee the code side is in good shape. I verified the agent metadata fix, compile clean and 280/280 on macOS. Before we decide on merging, could you share what you're actually trying to solve? If it's the "all extension features on my own gateway" case, this PR has a real reason to exist and I'll help get it merged. If it's just reaching another OpenAI-compatible endpoint, we might be better off closing it and pointing people at the native flow.

One heads up, the Prettier step in CI is still red, so a npm run format:prettier pass is needed either way.

[jbuhagiar88]

Thanks @ltmoerdani for the review. The use case is the narrower one you described: retaining the extension’s Go/Zen-specific functionality—usage tracking, pricing, model metadata, thinking controls, Agents window support, and vision proxy—while routing requests through a controlled gateway endpoint.

This is useful in environments where direct access to the standard OpenCode endpoints is restricted by network or organizational policy. The goal is not to create another generic OpenAI-compatible client; native BYOK remains the better option for that. The configurable base URL simply allows the existing OpenCode-specific features to work with an approved compatible gateway.

I’ve also run npm run lint; Prettier, TypeScript, ShellCheck, ESLint, and tests are passing locally. The configurable URL is opt-in and defaults to the existing Go/Zen endpoints, so existing users are unaffected.

[ltmoerdani]

Thanks @jbuhagiar88, that clarifies it. The use case you described is exactly where this PR earns its place: keeping the OpenCode-specific features like usage tracking, pricing, model metadata, thinking controls, Agents window support, and the vision proxy, but routing them through a gateway that fits your network or policy constraints. That's not a generic OpenAI-compatible client, which keeps the scope where it should be.

@xianhongtao the scope concern is addressed by this. The extension stays an OpenCode Go and Zen provider. The base URL setting is opt-in, defaults to the existing endpoints, and only exists so the OpenCode features can work behind an approved gateway when direct access is blocked.

The CI is green now, the Prettier issue is fixed, and I verified the agent metadata change earlier, compile clean and 280/280 on macOS. I'll merge this one.