feat(atlascloud): expand validated model pool for static resolution

[lucaszhu-hue]

Summary

• expand CodeWhale's Atlas Cloud static registry from the legacy 2-model fallback to the validated Atlas chat model pool
• keep the existing deepseek-v4-* aliases and fallback behavior intact for current users
• update provider docs and README examples so users understand this is about broader Atlas model resolution

Why This PR

Atlas Cloud support is already merged, but the static registry still behaved like a minimal provider bootstrap. This follow-up PR makes the AtlasCloud path visibly support the broader validated model pool while preserving the existing defaults.

Validation

• VS Code diagnostics clean for the touched files
• local Rust test execution could not run in this environment because cargo is unavailable

Greptile Summary

This PR expands the AtlasCloud static model registry from two legacy DeepSeek aliases to a 50-entry validated model pool, refactored into a dedicated atlascloud_models() helper and a ATLASCLOUD_VALIDATED_MODELS constant. Documentation and README examples are updated to reflect the broader pool.

• crates/agent/src/lib.rs: Introduces ATLASCLOUD_VALIDATED_MODELS, atlascloud_model() helper, and atlascloud_models(), then splices the full pool into the default registry at position 6, preserving existing aliases and fallback order.
• README.md / docs/PROVIDERS.md: Adds --model usage examples and updates the provider table description for AtlasCloud.

Confidence Score: 3/5

The core Rust change is mechanically straightforward but ships two correctness problems in the model data itself that affect live API calls.

The atlascloud_model helper blindly stamps every entry in the 50-model pool with supports_tools/supports_reasoning true, including deepseek-ai/deepseek-ocr which is an OCR model without a tool-call interface. The ATLASCLOUD_VALIDATED_MODELS array also mixes Pascal-cased IDs with fully-lowercase IDs; since the provider-hint resolution path returns the stored ID verbatim, the casing sent to the AtlasCloud endpoint is inconsistent and may trigger failures.

crates/agent/src/lib.rs — both the capability flags and the model ID casing in ATLASCLOUD_VALIDATED_MODELS need review before merge.

Important Files Changed

Filename	Overview
crates/agent/src/lib.rs	Expands AtlasCloud model pool from 2 to 52+ entries via a new const array and helper; two issues found: mixed casing in stored model IDs produces inconsistent API strings, and deepseek-ocr is incorrectly flagged as supports_tools/supports_reasoning.
README.md	Adds two AtlasCloud --model example commands; both model IDs exist in the validated pool with matching casing.
docs/PROVIDERS.md	Updates AtlasCloud provider table row to document the broader validated model pool; documentation change only, no logic impact.

_{Reviews (1): Last reviewed commit: "feat(atlascloud): expand validated model..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[greptile-apps]

Mixed casing within ATLASCLOUD_VALIDATED_MODELS produces inconsistent API IDs

The list mixes Pascal-cased IDs ("deepseek-ai/DeepSeek-V3-0324", "Qwen/Qwen3-Coder", "MiniMaxAI/MiniMax-M2", "moonshotai/Kimi-K2-Instruct") with lower-snake-cased IDs ("qwen/qwen3-8b", "deepseek-ai/deepseek-r1-0528", "minimaxai/minimax-m2.1"). When a provider-hinted resolution succeeds, the returned resolved.id is the stored ID verbatim (the preserve_requested_model_id_case path is only taken in the alias-map branch, not here). That means a request for qwen/qwen3-coder routes to AtlasCloud with the model string "Qwen/Qwen3-Coder", while a request for qwen/qwen3-8b routes with "qwen/qwen3-8b". If the AtlasCloud endpoint is case-sensitive (which REST APIs typically are), requests for the Pascal-cased entries will behave differently than the lowercase ones.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

deepseek-ai/deepseek-ocr is an OCR-specialised model that does not expose a chat-with-tools API. Marking it as supports_tools: true and supports_reasoning: true will cause the agent to send tool-call payloads to it, which the endpoint will reject or silently ignore. The atlascloud_model helper currently applies these flags uniformly to every entry in ATLASCLOUD_VALIDATED_MODELS, so there is no way to flag per-model capability differences. At minimum, deepseek-ocr should be excluded from the blanket helper.

Suggested change

	"deepseek-ai/deepseek-ocr",
	"xai/grok-4-0709",
	];
	// deepseek-ocr is an OCR-only model; add it manually with appropriate
	// capability flags instead of through the blanket atlascloud_model helper.
	"xai/grok-4-0709",
	];

[Hmbown]

Thanks for pushing this, @lucaszhu-hue. The idea is useful: AtlasCloud users should be able to select models beyond the two DeepSeek fallback rows without the CLI silently falling back to the default.

I harvested the low-risk slice into the v0.8.50 triage branch in #2504 as eedeb5290: when AtlasCloud is explicitly selected, namespaced model IDs like vendor/model-id now pass through exactly as requested. The existing DeepSeek V4 AtlasCloud aliases still resolve to the curated defaults, and plain unknown names still fall back to the provider default so typos do not silently become arbitrary model IDs.

I did not pull in the full static 50-model catalog for this release because that list is too easy to stale out and the current implementation gives every entry the same supports_tools / supports_reasoning flags. To make this PR mergeable as a broader follow-up, please tighten it to one of these paths:

1. Add a small curated AtlasCloud model list with source/evidence for each ID and explicit per-model capability flags.
2. Or keep the pass-through behavior from [codex] v0.8.50 triage harvest #2504 and make this PR docs-only, showing users how to select AtlasCloud model IDs without hardcoding the whole provider catalog.

Either path should keep model ID casing exact and include registry tests for provider-hinted resolution, alias preservation, and fallback behavior. Appreciate the push here; the release branch now carries the user-facing value while leaving the heavier catalog policy for a safer follow-up.

[Hmbown]

This was harvested into the v0.8.50 release — thank you for the contribution!