Add Atlas Cloud as an LLM adapter (SDK v1)

[binyangzhu000-sudo]

What & Why

Adds Atlas Cloud as a new LLM adapter in unstract-sdk1, in the same category as the existing OpenRouter/NVIDIA Build/MiniMax adapters. Atlas Cloud is an OpenAI-compatible gateway to 100+ LLMs from a single endpoint (https://api.atlascloud.ai/v1), identified by vendor/model ids (e.g. openai/gpt-4.1-mini, anthropic/claude-sonnet-4.6, deepseek-ai/deepseek-v3.2).

Disclosure: I work at Atlas Cloud.

Implementation notes

• AtlasCloudLLMParameters extends OpenAICompatibleLLMParameters and calls the existing _validate_branded_openai_compatible() helper — the same shape as NvidiaBuildLLMParameters, not OpenRouterLLMParameters.
• The reason: Atlas Cloud's own model ids are already fully-qualified vendor/model strings, unlike LiteLLM's native provider prefixes. OpenRouterLLMParameters routes through LiteLLM's openrouter/ prefix (a provider LiteLLM recognizes natively, per the class's own docstring: "Routed through LiteLLM's native openrouter/ provider so per-token costs resolve..."). "atlascloud" isn't one of those, so the correct route is the generic custom_openai/ path NVIDIA Build already uses — verified this is required, not just a style choice, with a real (non-mocked) litellm.completion() call.
• Added llm1/static/atlascloud.json (required by get_json_schema(), which loads {provider}.json by filename) and a new AtlasCloud.png icon (512×512, same format as the existing adapter icons) so the adapter picker doesn't break on a missing schema/icon.
• Registered in llm1/__init__.py (this package doesn't auto-discover adapters — each one is explicitly imported and added to __all__, same as every other adapter here).

Testing

Extended tests/test_branded_openai_adapters.py — added AtlasCloudLLMAdapter/AtlasCloudLLMParameters to the existing parametrized branded-adapter tests (registration, blank/overridden api_base, schema exposure) plus one dedicated test for the custom_openai/ prefixing behavior:

$ pytest tests/test_branded_openai_adapters.py -v
68 passed

ruff check passes on all changed files.

Manual test — a real, unmocked litellm.completion() call against the production Atlas Cloud API using the adapter's own validate() output:

validated = AtlasCloudLLMParameters.validate({"model": "openai/gpt-4.1-mini", "api_key": "..."})
# validated["model"]    == "custom_openai/openai/gpt-4.1-mini"
# validated["api_base"] == "https://api.atlascloud.ai/v1"

litellm.completion(model=validated["model"], api_base=validated["api_base"], api_key=validated["api_key"], messages=[...])
# REAL GATEWAY RESPONSE: UNSTRACT_ATLASCLOUD_OK

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[greptile-apps]

via Greptile

Confidence Score: 4/5

The PR should not merge until Atlas models receive resolvable context-window metadata so supported large-context inputs are not truncated to the generic 4096-token fallback.

Findings

1.  Context Window Falls Back ▶

Fix with agent prompt

### Issue 1
unstract/sdk1/src/unstract/sdk1/adapters/base1.py:599
Atlas validation leaves `context_window` unset while retaining the `custom_openai/` model prefix, which LiteLLM cannot resolve for model metadata. `LLM.get_context_window_size()` therefore falls back to 4096 tokens. Callers such as the classifier derive their input budget from that value and truncate requests to roughly 4 KB, even when the selected Atlas model supports a much larger context window. Supply resolvable context metadata instead of relying on this fallback.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR adds Atlas Cloud as an SDK1 OpenAI-compatible LLM adapter, including registration, validation, configuration schema, frontend icon, and branded-adapter tests.

• Routes Atlas model IDs through LiteLLM’s generic custom_openai/ provider.
• Defaults requests to the Atlas Cloud API while retaining support for endpoint overrides.
• Adds the adapter to SDK exports and the generic frontend adapter picker.
• The request path is registered correctly, but unresolved context metadata limits callers to the 4096-token fallback.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  UI[Adapter picker] --> Schema[atlascloud.json]
  Schema --> Adapter[AtlasCloudLLMAdapter]
  Adapter --> Validate[AtlasCloudLLMParameters.validate]
  Validate --> Model["custom_openai/vendor/model"]
  Model --> Atlas[Atlas Cloud API]
  Validate --> Context[Context-window lookup]
  Context -->|Model metadata unresolved| Fallback[4096-token fallback]
  Fallback --> Truncate[Caller input truncation]

Loading

_{Reviews (1) · Last reviewed commit: "[pre-commit.ci] auto fixes from pre-comm..."}

[greptile-apps]

Context Window Falls Back

Atlas validation leaves context_window unset while retaining the custom_openai/ model prefix, which LiteLLM cannot resolve for model metadata. LLM.get_context_window_size() therefore falls back to 4096 tokens. Callers such as the classifier derive their input budget from that value and truncate requests to roughly 4 KB, even when the selected Atlas model supports a much larger context window. Supply resolvable context metadata instead of relying on this fallback.

Prompt To Fix With AI

This is a comment left during a code review.
Path: unstract/sdk1/src/unstract/sdk1/adapters/base1.py
Line: 599

Comment:
**Context Window Falls Back**

Atlas validation leaves `context_window` unset while retaining the `custom_openai/` model prefix, which LiteLLM cannot resolve for model metadata. `LLM.get_context_window_size()` therefore falls back to 4096 tokens. Callers such as the classifier derive their input budget from that value and truncate requests to roughly 4 KB, even when the selected Atlas model supports a much larger context window. Supply resolvable context metadata instead of relying on this fallback.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.