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.