DeepSeek Harness search key also used by chat: same ref

"I entered a key on the search page, and later chat spending also went through that key" — this is neither an illusion nor search counting chat tokens; both places default to the same credential reference name. The search plugin stores no key at all, it writes only a name into the credential domain, and the model route reads that same name by default (#11174). Think of "name" and "value" separately and the relationship becomes obvious.

DeepSeek Harness: Layer 1: what "entering a key on the search page" actually writes

It writes a credential entry reference name, not a search plugin configuration item.

1. The submit action calls credentials.set(this.ref(), value), writing the value into the credential domain.
2. this.ref() is the reference name, defaulting to DEEPSEEK_API_KEY.
3. In the search plugin's schema, the default reference name is the same string.
4. So "entering a key" is really "assigning a value to this name".
5. The search plugin side stores only "which name I use", never the secret itself.

DSH plugin: Layer 2: three defaults add up to the same name

The search page, the search plugin, and the API-key model route share the same default reference name, so by default they naturally share one key.

1. Search settings page: default reference DEEPSEEK_API_KEY.
2. Search plugin schema: the same default.
3. DeepSeek API-key model connection: also resolves this name by default.
4. All three defaults point at one credential entry, and whoever writes it takes effect.
5. So the key you entered on the search page is what the model route reads.

DeepSeek Harness: Layer 3: why it shows up as "chat using this key"

On an API-key route, the model request carries exactly this credential; search did not forward it, they were the same entry all along.

1. Before a session calls the model, the adapter fetches the secret by reference name.
2. What it gets is the entry you just filled in.
3. So the chat call naturally uses this key.
4. This has nothing to do with search results or search billing.
5. The deciding factor is "the provider is an API-key route", not "search is enabled".

DSH Plugin: Layer 4: when this explanation fails

If the session uses the account-login route, the model does not read this reference name and the symptom needs another cause.

1. Open that session's request/header and read the provider.
2. If it is account login (deepseek-account), the model does not use an API key.
3. Then "shared key" does not apply, and you should check account quota or other configuration.
4. Likewise, changing the reference name only matters on API-key routes.
5. Confirming this one point saves half of the useless investigation.

DeepSeek Harness: Where the defaults collide

Put the three defaults side by side and the collision is obvious.

All three rows point at one name, so "fill it once, both sides take effect" is default behavior rather than an accident.

DSH plugin: Three common misconceptions

Remove these three and misdiagnosis mostly stops.

1. "Search counted the chat tokens" — no. Search only references the secret and takes no part in chat metering.
2. "The key is stored in the search plugin" — no. The key lives in the credential domain; the plugin remembers only the reference name.
3. "Changing the search address separates them" — no. Address and credential are different dimensions, and DEEPSEEK_SEARCH_BASE_URL only controls where requests land.

How to separate them

Giving search its own reference name is the smallest reversible change.

1. Open search settings and change the credential reference from DEEPSEEK_API_KEY to DEEPSEEK_SEARCH_API_KEY.
2. Enter the search key under that new name.
3. Confirm the model route still uses DEEPSEEK_API_KEY with its value unchanged.
4. Send a message that triggers search and confirm search works.
5. Send an ordinary chat message and confirm the model still uses the original key.
6. If search has its own service address, set it with DEEPSEEK_SEARCH_BASE_URL separately, not mixed with the chat baseURL.

Cautions

Name and value are separate decisions; only the name is shared.

1. Do not read "shared" as "search bills the chat". They are simply one key.
2. Change the reference name in both places. Renaming without entering a key under the new name breaks search.
3. This explanation does not apply to account-login routes. Check the provider first.
4. Search address and chat address are two variables. Mixing them leads you to misdiagnose it as a credential issue.
5. Verify both directions after the change. Search must run, and chat must use the original key.

On UI shortcuts such as "cmd+R force refresh", the community reply gives no built-in implementation; file a separate request and do not fold it into this credential issue.

One last reminder: if after renaming the reference, search someday starts using the chat key again, first check whether a reinstall or reset restored the default name.

If you do not actually need them separated, keeping the default is simpler — one key for both places, one less configuration.See DSH plugin web_search ignores your gateway: fix baseURL for the related case.