feat(llm): add Atlas Cloud LLM provider

[binyangzhu000-sudo]

Summary

Adds Atlas Cloud as an LLM provider. It is an OpenAI-compatible inference platform, so the
provider follows the same shape as the other OpenAI-compatible entries already here (Novita, PPIO,
SiliconFlow, Jiekou.AI): reuse the OpenAI client with a different base URL, read the key from
ATLASCLOUD_API_KEY, and allow api_key / base_url overrides through kwargs.

config.set_provider_config("llm", "AtlasCloud", {"model": "deepseek-ai/deepseek-v4-pro"})

Files

• deepsearcher/llm/atlascloud.py — AtlasCloud(BaseLLM), default model
  deepseek-ai/deepseek-v4-pro, base URL https://api.atlascloud.ai/v1.
• deepsearcher/llm/__init__.py — import + __all__.
• tests/llm/test_atlascloud.py — 8 cases mirroring tests/llm/test_novita.py (default init, key
  from env, key as parameter, custom model, custom base URL, single- and multi-message chat,
  response mapping).
• docs/configuration/llm.md — provider table row + example section.
• README.md — LLMName list + a <details> example block, following the PPIO / Jiekou.AI entries.

One caveat, documented rather than left to be discovered

The default model is a reasoning model: it spends completion tokens on a hidden chain of thought
before writing the answer, so a small max_tokens passed through kwargs can come back with
finish_reason="length" and an empty content. This provider leaves max_tokens unset, which
is safe — I verified against the live API that a call with no max_tokens returns content normally
(finish_reason=stop, 32 total tokens for a one-word reply). Non-reasoning ids such as
deepseek-ai/DeepSeek-V3.1 are unaffected. Both are noted in the docs section.

Validation

• pytest tests/llm/ → 146 passed / 10 failed, up from 138 passed / 10 failed on a clean
  checkout. The 8 new cases pass; the 10 failures are pre-existing (test_xai and friends fail
  identically before this branch — I checked by stashing and re-running).
• Live API check for the reasoning-model note above; the provider itself is unit-tested with a
  mocked openai module, exactly like the Novita tests.

No credentials in the diff — the tests use placeholder keys and the docs use the env var name.

---

🤝 Partnership & contact

This PR comes from the Atlas Cloud team. Beyond the integration above, we'd love to explore a closer collaboration with DeepSearcher — for example co-marketing or a featured integration.

If that sounds interesting, reach out anytime:

• 📧 marketing@atlascloud.ai
• 🌐 https://www.atlascloud.ai
• 📚 Docs: https://www.atlascloud.ai/docs

And of course, happy to revise this PR to match your project's conventions — just leave a comment. 🙌

[sre-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: binyangzhu000-sudo
To complete the pull request process, please assign zc277584121 after the PR has been reviewed.
You can assign the PR to them by writing /assign @zc277584121 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sre-ci-robot]

Welcome @binyangzhu000-sudo! It looks like this is your first PR to zilliztech/deep-searcher 🎉

[yhmo]

deepsearcher/llm/atlascloud.py line:33
Medium ---- When ATLASCLOUD_API_KEY is unset, api_key stays None and the OpenAI client (openai>=1.77) silently falls back to the OPENAI_API_KEY env var. Since DeepSearcher's default provider is OpenAI, most users have OPENAI_API_KEY set, so a misconfigured Atlas Cloud setup would silently authenticate against api.atlascloud.ai with the user's live OpenAI credential (sent to a third-party endpoint); if that var is also missing, construction raises "The api_key client option must be set ... OPENAI_API_KEY", which is misleading for Atlas Cloud users. Consider rejecting a missing key explicitly with a clear error naming ATLASCLOUD_API_KEY instead of relying on the client fallback.

[yhmo]

deepsearcher/llm/atlascloud.py line:16
Low ---- The docstring says "if a caller passes a small max_tokens through kwargs the reply can come back with finish_reason="length" and empty content", but kwargs are forwarded to the OpenAI client constructor, and OpenAI.init has a fixed keyword-only signature (openai>=1.77, verified in the pinned client source), so max_tokens/temperature/etc. raise TypeError at construction and never reach chat.completions.create(). The described empty-content scenario is therefore unreachable through this provider's API surface. Consider forwarding request-level kwargs to completions.create() or rewording the docstring to state that max_tokens is not supported via this provider.

[yhmo]

docs/configuration/llm.md line:53
Low ---- The established onboarding pattern for new providers (see the Novita and Jiekou.AI PRs) also registers the provider in deepsearcher/config.yaml (commented block), env.example, and docs/integrations/index.md. Atlas Cloud is missing from all three: no ATLASCLOUD_API_KEY in env.example (NOVITA_API_KEY and JIEKOU_API_KEY are both listed), no Atlas Cloud row in docs/integrations/index.md, and no commented AtlasCloud block in config.yaml. Users who discover providers through those surfaces will not find this one; consider adding the same three registration points.