Sign in

Cosmos DevKit

Cosmos Code, the Cosmos coding agent for the terminal, VS Code, and desktop, built on ADK V2

servicedeveloper-toolsclivscodeadk

Updated 2026-11-03

Verified 2026-11-03

Cosmos Code (cosmos-code) brings Cosmos agents into developer workflows. It is EY's fork of OpenCode: a signed-in user drives Cosmos-registered agents from the terminal or from the Cosmos Workbench VS Code extension, with ADK running the agent and the developer's machine running the tools.

Shipping Surfaces

SurfaceDescription
Cosmos Code CLI and TUIThe cosmoscode binary
Cosmos Workbench VS Code extensioney-cosmos.cosmos-workbench, which embeds a compiled cosmoscode binary (repository cosmos-workbench)
Cosmos Workbench desktop appElectron app that also embeds cosmoscode (repository cosmos-workbench)

ADK fixes ship as an ADK service deployment, not in the extension or desktop app.

How It Works With Cosmos

  • ADK runtime — when the selected model uses the cosmos provider with the Cosmos SDK or WebSocket transport, turns run through ADK V2 instead of the local model loop. ADK owns the transcript, context window, and compaction; the client sends only the latest user turn. The context gauge uses the token threshold ADK reports in each usage frame.
  • Client-side tools — local tools (read, write, edit, search, shell, and similar) are registered with the ADK V2 router. When the agent calls one, the request comes back over the WebSocket and the tool runs on the developer's machine against real paths, without a sandbox. ADK server-side document tools are excluded.
  • Login — browser PKCE login against the User Service with the public OAuth client cosmos-devkit-public and the callback http://127.0.0.1:19876/callback. Tokens are stored in the runtime's auth.json and refreshed automatically before ADK calls. Each organization appears as a cosmos-<orgId> provider.
  • Identity and branding — the client does not send an ADK app_name; ADK fills in the selected agent's name. The host surface is reported as source_channel for observability. Configuration lives in ~/.config/cosmos-code/ (cosmos-code.json or cosmos-code.jsonc) and per project in .cosmos-code/.

There is no REST conversation fallback: execution always uses ADK V2.

Workspace-Scoped Runtime

Managed Workbench runtimes set COSMOS_REQUIRE_WORKSPACE_CONTEXT=1. Clients then send x-cosmos-workspace on discovery and activation requests, and add x-cosmos-context-revision on catalog, session, prompt, and other execution requests. CLI and TUI clients that send neither keep the unscoped behavior.

EndpointPurpose
GET /cosmos/capabilitiesRuntime capabilities and runtimeInstanceId
GET /cosmos/workspaceCurrent binding; status ready, unbound, or auth-required
POST /cosmos/workspaceBind an organization and project, optionally resuming a session
GET /cosmos/organizationsOrganizations available to the user
GET /cosmos/projectsProjects in an organization, with search and cursor pagination

Domain failures return HTTP 409 with {code, message}; codes are auth-required, access-denied, not-found, network-error, service-unavailable, busy, context-conflict, missing-context, and unsupported.

API Overview

Cosmos Code has no Cosmos service API of its own. It calls the User Service for login, Configurator for organizations, projects, and agents, and the ADK V2 WebSocket (/api/v1/adk/converse/v2) for execution. The workspace endpoints above are served by the local runtime. See the ADK Converse API.

Development

  • Install Bun 1.3.14 or later.
  • Clone cosmos-sdk-typescript as a sibling; @cosmos/sdk resolves through a local file link.
  • Run bun install at the repository root.
  • Run tests and bun typecheck from package directories such as packages/opencode, not from the root.

Changelog

See the DevKit changelog for verified changes.