feat(providers): add Atlas Cloud integration

[binyangzhu000-sudo]

Summary

• add Atlas Cloud as a ready, first-class OpenAI-compatible provider with the default endpoint and qwen/qwen3.8-max
• expose Atlas Cloud in the provider catalog with localized display copy and model capability metadata
• cover registry wiring, catalog readiness, models.dev exclusion, and generated provider contracts

Verification

• npm --workspace @maka/core test (805 passed)
• provider contract matrix (124 passed, including Atlas Cloud discovery and tool loop)
• npm run build
• npm run typecheck
• npm run lint
• npm run format
• live Atlas Cloud model discovery, text generation, and two-step tool execution with qwen/qwen3.8-max

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — Atlas Cloud becomes selectable as a ready provider.
• No

[Astro-Han]

Thanks for taking the time to prepare this integration and its tests.

Before I review the implementation further, I need to resolve the product and provenance questions first.

Maka already supports arbitrary OpenAI Chat-compatible services through the built-in Custom relay (OpenAI Chat-compatible) provider, including a custom base URL, API key, model discovery, and per-model capability declarations. Atlas Cloud’s own documentation describes its LLM endpoint as OpenAI-compatible, so it appears to be usable today with:

https://api.atlascloud.ai/v1

Adding a ready, first-class provider is therefore not only a transport change. It creates a permanent catalog and support contract for the endpoint, fallback model, capability metadata, display copy, and future compatibility maintenance. I currently cannot find a linked Maka user request or a concrete Atlas-specific incompatibility that the existing custom-provider path cannot express.

I also noticed that this account has recently opened a large number of Atlas Cloud integration PRs across many unrelated repositories and has contributed to repositories under the AtlasCloudAI organization. I do not want to make assumptions about that relationship, but transparency matters for a provider-catalog decision. Could you please disclose:

• any affiliation, sponsorship, compensation, or other relationship with Atlas Cloud;
• whether automation or generative AI materially produced this contribution;
• the concrete Maka user demand motivating a first-class entry;
• the specific behavior that cannot be supported through Maka’s existing OpenAI-compatible provider;
• inspectable, redacted evidence for the claimed live discovery, text-generation, and tool-execution verification.

Unless there is a genuine protocol or product requirement that the shared path cannot satisfy, my current preference is to keep Atlas Cloud on the generic OpenAI-compatible seam rather than add a parallel first-class provider contract. This is not a judgment on the service itself, and I am open to being shown a concrete incompatibility or user need that changes that conclusion.

中文对照

感谢你准备这项集成及相关测试。

在继续审查具体实现之前，我需要先明确产品需求和贡献来源。

Maka 已经通过内置的“Custom relay (OpenAI Chat-compatible)”支持任意 OpenAI Chat 兼容服务，包括自定义 Base URL、API key、模型发现和逐模型能力声明。Atlas Cloud 官方文档也将其 LLM endpoint 描述为 OpenAI-compatible，因此目前应当已经可以使用：

https://api.atlascloud.ai/v1

增加一个 ready 状态的一级 Provider 并不只是传输层改动。它会为 endpoint、默认模型、能力元数据、展示文案以及未来兼容性建立长期的目录和维护契约。目前我没有找到关联的 Maka 用户需求，也没有看到现有通用 Provider 无法表达的 Atlas 特有不兼容行为。

我还注意到，这个账号最近向许多互不相关的仓库提交了大量 Atlas Cloud 集成 PR，并且参与了 AtlasCloudAI 组织下仓库的贡献。我不希望对双方关系作未经证实的推断，但 Provider 目录决策需要透明度。请说明：

• 是否与 Atlas Cloud 存在从属、赞助、报酬或其他关系；
• 本次贡献是否实质使用了自动化或生成式 AI；
• 将 Atlas 作为一级入口所对应的具体 Maka 用户需求；
• Maka 现有 OpenAI-compatible Provider 无法支持的具体行为；
• PR 中所称实时模型发现、文本生成和工具执行验证的可检查、已脱敏证据。

除非确实存在共享路径无法满足的协议或产品需求，否则我目前倾向于继续通过通用 OpenAI-compatible 扩展点支持 Atlas Cloud，而不是增加一个平行的一级 Provider 契约。这不是对服务本身的评价；如果有具体的不兼容行为或用户需求，我愿意据此重新判断。

Disclosure: Codex assisted with repository and public-contribution-pattern analysis and drafted this comment. I reviewed the cited evidence, determined the product and provenance questions, and made the decision to request clarification.

[Astro-Han]

/agentic_review

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Multimodal model marked text-only 🐞 Bug ≡ Correctness

Description

The Atlas Cloud metadata omits vision: true and image input modalities for qwen/qwen3.8-max, so
resolveModelVisionSupport() returns false and the runtime replaces image attachments with a “model
does not support image input” notice. This contradicts Atlas Cloud's description of this exact model
as supporting multimodal applications.

Code

packages/core/src/model-metadata.ts[416]

+      capabilities: { chat: true, reasoning: true, functionCalling: true },

Relevance

●●● Strong

Missing vision metadata deterministically disables image inputs; accepted history favors fixing
concrete runtime correctness gaps.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Atlas Cloud is explicitly excluded from generated models.dev metadata, making this static entry its
metadata authority. The vision resolver defaults undeclared models to false, that result is passed
into runtime execution, and the runtime then omits user and tool-result images; Atlas Cloud's model
page describes the exact registered model as intended for multimodal applications.

packages/core/src/tests/models-dev-sync-contract.test.ts[55-59]
packages/core/src/model-metadata.ts[45-63]
packages/core/src/model-metadata.ts[183-214]
packages/runtime-host/src/server/execution-model-composition.ts[331-336]
packages/runtime/src/ai-sdk-backend.ts[846-847]
packages/runtime/src/ai-sdk-backend.ts[4323-4332]
🌐 Atlas Cloud describes qwen/qwen3.8-max as a flagship model for advanced reasoning, coding, and multimodal applications.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Atlas Cloud's `qwen/qwen3.8-max` metadata omits vision and image-input declarations, causing the runtime to reject images for a multimodal model.

## Issue Context
Use the existing static metadata seam: add `vision: true` and `modalities: { input: ['text', 'image'], output: ['text'] }`, plus a focused regression assertion. Deletion or consolidation cannot restore the missing provider-specific capability; this adds no new public surface or authority because the static metadata entry is already authoritative for Atlas Cloud, with only a small test-maintenance burden.

## Fix Focus Areas
- packages/core/src/model-metadata.ts[412-418]
- packages/core/src/__tests__/model-metadata.test.ts[1-130]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Web pages:

  🌐 qwen3.8-max

  🌐 Qwen LLM API Collection: Alibaba Open-Source AI Models

  🌐 Atlas Cloud for Developers - OpenAI-Compatible API, MCP, Skills | Atlas Cloud

  +6 more

Review mode: ⚖️ Balanced: This adds a selectable runtime provider and changes registry, discovery, model capability, and catalog contracts, creating real behavioral and public-surface risk despite the small localized diff.

Tip of the day

💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Multimodal model marked text-only 🐞 Bug ≡ Correctness

The Atlas Cloud metadata omits vision: true and image input modalities for qwen/qwen3.8-max, so
resolveModelVisionSupport() returns false and the runtime replaces image attachments with a “model
does not support image input” notice. This contradicts Atlas Cloud's description of this exact model
as supporting multimodal applications.

Agent Prompt

## Issue description
Atlas Cloud's `qwen/qwen3.8-max` metadata omits vision and image-input declarations, causing the runtime to reject images for a multimodal model.

## Issue Context
Use the existing static metadata seam: add `vision: true` and `modalities: { input: ['text', 'image'], output: ['text'] }`, plus a focused regression assertion. Deletion or consolidation cannot restore the missing provider-specific capability; this adds no new public surface or authority because the static metadata entry is already authoritative for Atlas Cloud, with only a small test-maintenance burden.

## Fix Focus Areas
- packages/core/src/model-metadata.ts[412-418]
- packages/core/src/__tests__/model-metadata.test.ts[1-130]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[Astro-Han]

This PR makes Atlas Cloud selectable in the Desktop provider catalog. Could you please add a screenshot showing Atlas Cloud in the catalog and its connection or model-selection surface? Please sanitize any account or credential details. One annotated screenshot is fine. Thanks!

Posted by Codex on behalf of Astro-Han.

[Astro-Han]

Heads up — this has drifted into conflict with main and can't be merged or reviewed as-is.

Worth knowing before you rebase: #3397 landed on 2026-08-22 and added ASF license headers across ~2685 files, so a rebase will touch more than you'd expect, and any file you add now needs a header (npm run write:asf-headers). A green check from before that date no longer proves anything about the current tree.

I'd like to review this — just ping me once it's rebased and CI is green.

[Astro-Han]

Hi — this PR conflicts with current main and cannot be merged as-is.

I tested a rebase onto current main locally (in a throwaway worktree — your branch was not touched). It stops on these files:

• packages/core/src/__tests__/models-dev-sync-contract.test.ts

These are real source conflicts, so they need your judgement rather than a mechanical rebase — please rebase onto current main and resolve them yourself, then push. Once the branch is conflict-free and CI is green on the new head, I will pick it up for review.

git fetch upstream && git rebase upstream/main
# resolve, then
git push --force-with-lease

Thanks for the contribution — happy to help if any conflict is unclear.

---

AI-assisted maintenance note, not a review. It does not count as the required human review under CONTRIBUTING.md §Review.

[binyangzhu000-sudo]

Synced with main (1179 commits behind) and addressed the Qodo finding. Both needed real digging, so details below.

The Qodo finding: measured, and it would have introduced the bug

Qodo flagged that the Atlas entry omits vision, so resolveModelVisionSupport() returns false and image attachments get replaced with a not-supported notice — and suggested declaring vision because Atlas Cloud markets the model as multimodal.

The causal chain is exactly right. The conclusion isn't. I tested the endpoint:

request	qwen/qwen3.8-max	qwen/qwen3-vl-235b-a22b-thinking
text-only string	200	200
text-only parts array	200	—
parts array with image_url	400	400

Atlas Cloud's OpenAI-compatible /v1/chat/completions rejects an image_url content part — including for its own vision-branded model. So declaring vision: true would make the runtime send attachments the endpoint cannot accept, turning a graceful notice into a 400.

What the finding did surface correctly is that leaving it undeclared relies on the Claude-family fallback to land on false. So I pinned it explicitly — capabilities: { …, vision: false } with a comment recording the verification date and the observed behaviour. That matches how tencent-coding-plan pins kimi-k2.5.

Merge

• ProviderDefaults dropped description, backendKind, protocol and catalogBadge, renamed readyOrder → recommendedOrder, and modelDiscovery.filter lost its fallback-models member. The entry now mirrors the neighbouring deepinfra provider field-for-field.
• models-dev-sync-contract.test.ts was deleted in "remove pure snapshot suites", taking the NOT_IN_MODELS_DEV allow-list with it. Before accepting that deletion I checked the mechanism wasn't relocated — nothing equivalent exists, and volcengine-ark has no replacement declaration either — so the Atlas line is simply gone rather than needing a new home.
• model-metadata.generated.ts is gitignored upstream now, so the merge drops it from tracking.

Verification — tsc --noEmit clean; node --test dist/**/*.test.js in @maka/core: 826 passing, 0 failing.

Disclosure: I work at Atlas Cloud.

[hqhq1025]

Reviewed exact head 01a38acda0f4dc6752cb00b2a130c5a85c57a673. The Core registry, metadata, discovery, and generated OpenAI-compatible wire paths pass their focused suites, but the Desktop catalog addition has one blocking localization/type-contract defect. The branch is also currently conflicting with main in packages/core/src/__tests__/llm-connections.test.ts, and GitHub reports no hosted checks for this head.

The earlier product question also remains a maintainer decision: this adds a permanent first-class provider alongside the existing custom OpenAI-compatible route.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[hqhq1025]

[P2] Add the two supported Chinese locale entries instead of zh

UiCatalog is exactly Record<'zh-CN' | 'zh-TW' | 'en', ...>, so this zh key leaves both supported Chinese locales missing. On this exact head, tsc -p apps/desktop/tsconfig.renderer.json --noEmit fails here with TS2353/TS2352. If type checking is bypassed, the runtime behavior is also broken: providerDisplay('atlascloud', 'zh-CN') and zh-TW both fall back to the provider id plus “provider not registered” copy, while English works. Please provide separate zh-CN and zh-TW entries and cover them through the display-copy contract.

[binyangzhu000-sudo]

Re-synced — main moved another 8 commits since this morning's merge and re-conflicted the branch.

The conflict was in llm-connections.test.ts, where your new slug-validation test and this branch's Atlas registry test landed in the same position. Kept both.

One thing I caught before pushing: my first pass at that resolution silently swallowed the closing }); of your slug test, which tsc flagged as TS1005 at end of file. Fixed and re-verified — worth mentioning since a brace-level truncation like that is exactly the kind of thing a green-looking merge can hide.

Verification — @maka/core build clean; node --test dist/**/*.test.js: 830 passing, 0 failing (up from 826, the difference being your new tests).

Disclosure: I work at Atlas Cloud.

[hqhq1025]

Reviewed exact head 15a918d153a9a578c1f0645abcaed15971a6dd25. The previous localization defect remains unchanged on this head.

P2: apps/desktop/src/renderer/settings/provider-display-copy.ts:248 defines the new atlascloud entry with zh and en, but the required UiCatalog keys are zh-CN, zh-TW, and en. A clean build:test stops in Desktop TypeScript with TS2353 and reports both supported Chinese keys missing. At runtime, providerDisplay() indexes the exact locale, so both Chinese locales fall back to the provider id plus “not registered” copy instead of the intended Atlas Cloud text. Please provide zh-CN and zh-TW entries and add the provider to the display-copy contract test.

The focused Core registry/model-metadata tests pass (34/34), as do changed-file Biome, locale hygiene, ASF headers, and git diff --check. A synthetic merge onto current main (eca7778b1aa04ae21d33850cefd2f46ae7c7138a) is clean and preserves the PR patch. GitHub currently exposes no hosted checks for this head. I did not have Atlas credentials, so I did not independently repeat the reported live discovery/completion/vision probes. Whether Atlas Cloud should become a permanent first-class catalog provider rather than use the existing generic OpenAI-compatible route remains a maintainer product decision.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.