Cherry Studio, Chatbox and LobeChat: base_url configuration for desktop clients

Why start with this category

Desktop clients — Cherry Studio, Chatbox, LobeChat, NextChat and the rest — are the lowest-barrier way to connect to a relay site: fill in three fields and you are running. Precisely because it is easy, many people treat it as the standard test for "does this relay site work", and that is where the trouble starts.

Being able to chat proves exactly one thing: the plain-text path through /v1/chat/completions is reachable. It does not prove that tool calling, image input or structured output work.

The three configuration essentials

1. Base URL

Two families of client handle the URL differently:

• Full path required: https://<domain>/v1/chat/completions
• Up to /v1 required: https://<domain>/v1
• Domain alone accepted: /v1 is appended automatically

How to check: click "test" after filling it in, and switch to the other form if it fails. Two or three attempts will find the right shape.

A high-frequency mistake: entering /v1 twice, as in https://<domain>/v1/v1. This is common with clients that accept a bare domain — they appended /v1 and you typed it as well.

2. API key

Some clients put the key straight into Authorization: Bearer, others into x-api-key. Most relay sites accept the former. If you keep getting 401, confirm which one the client is using.

3. Model name ★ the most frequent mistake

As with Cursor: the model name must be added by hand, and must match the relay site.

In clients like Cherry Studio and LobeChat this usually means "add model" then typing a model ID. Getting it wrong shows up as a successful connection test — because the test usually only checks that the endpoint is reachable — followed by a 404 or 400 the moment you send a message.

The safest approach: curl the list first.

curl -s https://<domain>/v1/models -H "Authorization: Bearer $KEY" | head -c 2000

"Test passed" is not "usable"

This is the point this article most wants to make. Verify in three steps and do not stop at the first:

Step 2 is regularly skipped. If the output is "wait a few seconds, then the whole passage appears at once", the site's streaming is fake — it is buffering and forwarding. The effect on interactive use is obvious.

Step 3: the advanced capability desktop client users reach for most is image input, the screenshot-question pattern. Test it with "what is in this image" plus an image file. If it is unsupported, some sites return 400 outright and others silently ignore the image and process only the text. The second kind is the more insidious.

Sharing one relay site across several clients

If you use a desktop client, an IDE extension and scripts at the same time, do one small thing: open a separate key on the relay for each client.

The benefits:

1. Usage is separable — when something goes wrong you know who is hammering it.
2. It can be blocked on its own — if one client's bad configuration causes high-frequency retries, it will not drag down your other uses.
3. Easier investigation — the site's call log can be filtered by key.

This matters especially with clients like Cherry Studio that issue concurrent multi-model requests. Some clients fire the same question at several models at once for comparison, and the volume is well above what you expect.

Extra considerations for a self-hosted LobeChat

LobeChat can be deployed yourself, and Docker images are provided. In that case requests originate from your server, so note:

1. The server must be able to reach the relay site. If the relay is in mainland China and the server is overseas, you may hit reverse-direction network problems.
2. Do not bake the key into the image. Inject it at runtime, or sharing the image amounts to leaking the key.
3. Mind the outbound IP. If the site has an IP allowlist, add the server's egress IP, not your own machine's.

A recommendation on tooling choice

If you are only checking whether a relay site suits you, a desktop client is the fastest instrument available — five minutes covers both the text and image tests.

But for a production evaluation it will not surface the information that matters. You would still need at least:

• A curl tool-calling test, as in our tool use compatibility article.
• The six streaming checks, as in the streaming failure article.
• A look at whether the site's own usage statistics are accurate, which is its reconciliation ability.

Those three are what decide whether a site can go into production.