Berd's LM Studio provider is double-appending /v1 when the configured Base URL already includes it

[nuit-dhiver]

Before filing

• I searched open and closed issues for duplicates.
• I reproduced this on the latest release.
• This is one bug, not several bundled together.

Closest existing issue

none found

What's broken

Berd's LM Studio provider is double-appending /v1 when the configured Base URL already includes it, producing malformed requests (/v1/v1/models, /v1/v1/chat/completions).

Symptom: chat/model-list requests land as /v1/v1/... on the LM Studio side (confirmed via LM Studio's own server log), and the resulting failure shows in Berd only as "Unknown"

Steps to reproduce

1. Start LM Studio's local server (Local Server tab → Start), with a model loaded.
2. In Berd, add/configure a custom OpenAI-compatible provider pointing at LM Studio, setting Base URL to http://localhost:1234/v1 (i.e., including the /v1 suffix, as commonly documented for OpenAI-compatible endpoints).
3. Save the provider. Connection check succeeds — Berd fetches the model list fine.
4. Start a chat session using that provider/model and send any message (e.g. "hello").

What you expected to happen

Message sends normally and the model responds.

What actually happened

Chat fails immediately with a "The model returned an empty response. Please resend your message to continue."
Also the connection throws a warning as unknown error.

How often does it happen?

Every time — reliably reproducible

Berd version

0.6.2

Operating system

macOS (Apple Silicon)

Model and provider

LM Studio Bionic

Relevant log output

It's from lm studio NOT Berd.

183  [2026-08-20 12:40:17][DEBUG] Received request: GET to /v1/v1/models
184  [2026-08-20 12:40:17][ERROR] Unexpected endpoint or method. (GET /v1/v1/models). Returning 200 anyway
185  [2026-08-20 12:40:17][DEBUG] Received request: GET to /v1/v1/models
186  [2026-08-20 12:40:17][ERROR] Unexpected endpoint or method. (GET /v1/v1/models). Returning 200 anyway

Screenshots, recordings, or other context

No response

[nuit-dhiver]

Actually now that I'm thinking, it might be Goose's bug, but I'm not sure. I will install and test Goose last version to know if I get the same error.
It also worth to know if Berd is using latest release of Goose.
I will check it.

[nuit-dhiver]

Confirmed

This is kind of Berd's issue because:

1. goose has a dedicated, named lmstudio provider — not a generic "custom OpenAI-compatible" slot. It's configured via its own env var, LMSTUDIO_HOST, separate from goose's generic OpenAI provider config.
2. That value is currently a bare host (http://localhost:1234, no /v1)

So this confirms the mechanism precisely: goose's built-in lmstudio provider client appends /v1 itself to whatever LMSTUDIO_HOST it's given it expects a bare host. When the value written into that field included /v1 already, goose added a second one on top.

Berd took literal Base URL input and wrote it straight into LMSTUDIO_HOST without stripping a trailing /v1 before handing it to goose. The doubling arithmetic technically executes inside goose's provider code, but the bad value originates from Berd's setup flow not normalizing it and Berd owns that field and that write.

[chronakazi]

Can confirm I hit this one too. When trying to add an opencode zen endpoint I was seeing doubled up /v1 s. I wound up eliminating any /../v1/.. from API URL and moving it over to Base Path. Same fix for me as well, in my case: API URL: https://opencode.ai Base Path: /zen/v1/responses fixed it but Berd definitely doubles up a part of the path when handing it to goose if it's on the API URL side.