feat: add Atlas Cloud as LLM provider for agents

[lucaszhu-hue]

Adds Atlas Cloud as a supported LLM provider for Emdash agents.

Atlas Cloud provides 59 frontier models (DeepSeek-V4, Qwen3, Kimi K2, GPT-5, Gemini 2.5 Pro, Claude, Grok-4…) through a single OpenAI-compatible endpoint — perfect for powering multi-agent workflows in Emdash.

What's included:

• Registers atlascloud as a named provider in the agent registry, backed by opencode CLI configured against Atlas Cloud's API
• Adds the Atlas Cloud icon to the renderer icon map
• Adds an Atlas Cloud sponsor/info section at the top of README with a full model list

View all models · Coding Plan

[greptile-apps]

Greptile Summary

This PR registers Atlas Cloud as a new LLM provider by adding an atlascloud entry to the agent provider registry, mapping its icon in the renderer, and prepending a large promotional block to the README. The provider entry reuses the opencode CLI without any mechanism to redirect it to Atlas Cloud's inference endpoint.

• The atlascloud definition uses commands: ['opencode'] and installCommand: 'npm install -g opencode-ai' — identical to the existing opencode provider. Both will be probed against the same binary, so any user with opencode installed will see both providers reported as available simultaneously.
• There is no env var, config file write, or CLI flag in the definition that redirects the opencode CLI to Atlas Cloud's API; users who select this provider will get a plain opencode session backed by opencode's own models, not Atlas Cloud's.
• supportsHooks: true is present on the opencode entry but absent here, so emdash session hooks (e.g. session-ID capture for reliable resume) will silently not fire for Atlas Cloud sessions.

Confidence Score: 2/5

Not safe to merge as-is — selecting this provider delivers a regular opencode session rather than an Atlas Cloud-backed one, and it pollutes the provider list by making both opencode and atlascloud appear installed at the same time.

The atlascloud entry is functionally identical to the existing opencode entry: same binary, same install command, same flags. Nothing in the registration routes traffic to Atlas Cloud's API, so the provider does not do what it advertises. The duplicate-command detection issue will also surface immediately for any user who already has opencode installed.

apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts needs the most attention — the duplicate command conflict, missing API configuration, and missing hook support flag are all concentrated there.

Important Files Changed

Filename	Overview
apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts	Adds atlascloud provider backed by the same opencode CLI binary — duplicate command detection will mark both providers as available simultaneously, there is no mechanism to configure opencode to use Atlas Cloud's API endpoint, and supportsHooks: true is missing.
apps/emdash-desktop/src/renderer/lib/providers/meta.ts	Adds atlas.png icon import and maps it in the ICONS record; straightforward and consistent with how other PNG providers are registered.
README.md	Inserts a large Atlas Cloud sponsor/promotional block (76 lines with UTM-tracked links and a 59-model table) at the very top of the README, above all existing project content.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User selects Atlas Cloud provider] --> B[emdash runs installCommand\nnpm install -g opencode-ai]
    B --> C[opencode binary on PATH]
    C --> D{DependencyManager probeAll}
    D --> E[Probes 'opencode' provider\ncommands: opencode]
    D --> F[Probes 'atlascloud' provider\ncommands: opencode]
    E --> G[Both resolve same binary\nopencode available]
    F --> G
    G --> H[Both 'opencode' AND 'atlascloud'\nshow as available in UI]
    C --> I[User starts Atlas Cloud session]
    I --> J[opencode CLI launched\nwith default config]
    J --> K{API endpoint?}
    K -->|No env vars / flags configured| L[opencode default backend\nNOT Atlas Cloud API]
    K -->|Expected| M[Atlas Cloud API endpoint]
    style L fill:#f88,stroke:#c00
    style M fill:#8f8,stroke:#080

Loading

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts:662-680
**Duplicate command detection with existing `opencode` provider**

Both `atlascloud` and the existing `opencode` provider set `commands: ['opencode']` and `installCommand: 'npm install -g opencode-ai'`. The `buildAgentDependencies()` function in `registry.ts` creates an independent `DependencyDescriptor` per provider, so both descriptors resolve the same binary. This means any user who has `opencode` on their `PATH` will see *both* "Atlas Cloud" and "OpenCode" reported as `available` simultaneously — even though they have only one binary installed. This is likely to confuse users browsing the provider list.

### Issue 2 of 3
apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts:676-681
**Missing `supportsHooks: true`**

The `opencode` provider sets `supportsHooks: true`, which enables emdash hooks (e.g. the `SessionStart` hook that captures the rollout session ID for reliable conversation resumption). The `atlascloud` entry uses the exact same CLI (`opencode`) but omits this flag, so hooks will silently not fire during Atlas Cloud sessions even though the underlying binary fully supports them.

```suggestion
    resumeWithoutSessionFlag: '--continue',
    icon: 'atlas.png',
    alt: 'Atlas Cloud',
    terminalOnly: true,
    supportsHooks: true,
  },
];
```

### Issue 3 of 3
apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts:662-680
**No actual API endpoint configuration for Atlas Cloud**

The `atlascloud` entry installs and invokes the stock `opencode-ai` CLI, which by default points at opencode's own inference backend — not Atlas Cloud's API. There is no mechanism here (no env var injection, no config file write, no extra CLI flags) to redirect the CLI to Atlas Cloud's endpoint. The description even acknowledges this gap ("Configure any OpenAI-compatible agent CLI to use Atlas Cloud as the LLM backend"), but the provider registration provides no guidance or automation for that step. Without configuration, a user who picks this provider will get a plain opencode session backed by opencode's default models, indistinguishable from choosing the `opencode` provider.

_{Reviews (1): Last reviewed commit: "feat: add Atlas Cloud as LLM provider fo..." | Re-trigger Greptile}

[greptile-apps]

Duplicate command detection with existing opencode provider

Both atlascloud and the existing opencode provider set commands: ['opencode'] and installCommand: 'npm install -g opencode-ai'. The buildAgentDependencies() function in registry.ts creates an independent DependencyDescriptor per provider, so both descriptors resolve the same binary. This means any user who has opencode on their PATH will see both "Atlas Cloud" and "OpenCode" reported as available simultaneously — even though they have only one binary installed. This is likely to confuse users browsing the provider list.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts
Line: 662-680

Comment:
**Duplicate command detection with existing `opencode` provider**

Both `atlascloud` and the existing `opencode` provider set `commands: ['opencode']` and `installCommand: 'npm install -g opencode-ai'`. The `buildAgentDependencies()` function in `registry.ts` creates an independent `DependencyDescriptor` per provider, so both descriptors resolve the same binary. This means any user who has `opencode` on their `PATH` will see *both* "Atlas Cloud" and "OpenCode" reported as `available` simultaneously — even though they have only one binary installed. This is likely to confuse users browsing the provider list.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Missing supportsHooks: true

The opencode provider sets supportsHooks: true, which enables emdash hooks (e.g. the SessionStart hook that captures the rollout session ID for reliable conversation resumption). The atlascloud entry uses the exact same CLI (opencode) but omits this flag, so hooks will silently not fire during Atlas Cloud sessions even though the underlying binary fully supports them.

Suggested change

	resumeWithoutSessionFlag: '--continue',
	icon: 'atlas.png',
	alt: 'Atlas Cloud',
	terminalOnly: true,
	},
	];
	resumeWithoutSessionFlag: '--continue',
	icon: 'atlas.png',
	alt: 'Atlas Cloud',
	terminalOnly: true,
	supportsHooks: true,
	},
	];

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts
Line: 676-681

Comment:
**Missing `supportsHooks: true`**

The `opencode` provider sets `supportsHooks: true`, which enables emdash hooks (e.g. the `SessionStart` hook that captures the rollout session ID for reliable conversation resumption). The `atlascloud` entry uses the exact same CLI (`opencode`) but omits this flag, so hooks will silently not fire during Atlas Cloud sessions even though the underlying binary fully supports them.

```suggestion
    resumeWithoutSessionFlag: '--continue',
    icon: 'atlas.png',
    alt: 'Atlas Cloud',
    terminalOnly: true,
    supportsHooks: true,
  },
];
```

How can I resolve this? If you propose a fix, please make it concise.

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]

No actual API endpoint configuration for Atlas Cloud

The atlascloud entry installs and invokes the stock opencode-ai CLI, which by default points at opencode's own inference backend — not Atlas Cloud's API. There is no mechanism here (no env var injection, no config file write, no extra CLI flags) to redirect the CLI to Atlas Cloud's endpoint. The description even acknowledges this gap ("Configure any OpenAI-compatible agent CLI to use Atlas Cloud as the LLM backend"), but the provider registration provides no guidance or automation for that step. Without configuration, a user who picks this provider will get a plain opencode session backed by opencode's default models, indistinguishable from choosing the opencode provider.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/emdash-desktop/src/shared/core/agents/agent-provider-registry.ts
Line: 662-680

Comment:
**No actual API endpoint configuration for Atlas Cloud**

The `atlascloud` entry installs and invokes the stock `opencode-ai` CLI, which by default points at opencode's own inference backend — not Atlas Cloud's API. There is no mechanism here (no env var injection, no config file write, no extra CLI flags) to redirect the CLI to Atlas Cloud's endpoint. The description even acknowledges this gap ("Configure any OpenAI-compatible agent CLI to use Atlas Cloud as the LLM backend"), but the provider registration provides no guidance or automation for that step. Without configuration, a user who picks this provider will get a plain opencode session backed by opencode's default models, indistinguishable from choosing the `opencode` provider.

How can I resolve this? If you propose a fix, please make it concise.

[lucaszhu-hue]

Good catch on the opencode binary collision. Atlas Cloud is an OpenAI-compatible API endpoint reached through the OpenCode CLI rather than a separate binary, so I've reworked the provider so it no longer duplicates the opencode command probe:

• Removed the duplicated commands: ['opencode'] / installCommand and marked the provider detectable: false, so it no longer registers a second, indistinguishable probe of the opencode binary in buildAgentDependencies. OpenCode stays the single owner of that dependency, which removes the ambiguity where any user with opencode installed would have atlascloud falsely report as available.
• Atlas routing is now done the way emdash already supports per-provider env injection: resolveProviderEnv injects OPENAI_BASE_URL=https://api.atlascloud.ai/v1 (user-overridable) and inherits OpenCode's auto-approve permission env; the API key comes from the provider's env settings (ATLASCLOUD_API_KEY / OPENAI_API_KEY). Previously a spawned atlascloud session just ran plain opencode with no Atlas routing at all.
• Also fixed a latent issue this surfaced: the atlascloud entry was missing from agentConfig (an exhaustive Record<AgentProviderId, AgentInfo>), and added test coverage for the new env behavior.

Typecheck, lint, and the provider-env/agent-command test suites all pass. Thanks for flagging!

[arnestrickmann]

Hi @lucaszhu-hue, thanks for opening this and for contributing support for Atlas Cloud.

We’ll review the wiring and the feedback above carefully, then follow up here in the comments. In the meantime, could you take a look at the comments Greptile made on the implementation?

Also curious: what made you choose Atlas Cloud as the provider to add here?