Three Places to Use Ethen Code

Ethen Code is designed as one system with three doors: quick help in Chat, a full workspace in Platform, and a local environment in Desktop.

If you write software with AI help, the first question is usually where the work happens. A pasted snippet in a chat window is one kind of help. A branch with tests and a pull request is another. A local repository edited with your own toolchain is a third. Ethen's answer, as set out in the September 20 product/platform split, is that Code should appear in all three places on purpose: lightweight conversational coding in Chat, a full cloud engineering workspace in Platform, and a local coding-agent environment in Desktop. The split calls this out explicitly as intentional, not accidental duplication — one Code system exposed through different UX levels.

This article describes target product scope: where each surface is meant to fit and what each is meant to handle. Target scope is not release availability. Nothing here claims every listed feature has shipped, that any prompt becomes a merged pull request, or that deployment works the same from every surface. Where implementation evidence exists — the app registry and the Code run-persistence code — I point to it. Where only design direction exists, I say so.

The rule: one system, three UX levels

The September 20 split is organized around a single operating rule: one capability can appear on multiple surfaces, but it should have one canonical product owner and one shared backend and state. The point is to avoid separate, conflicting versions of the same product. Code is the worked example of that rule. The ownership matrix lists Code's canonical home as Platform plus Desktop, with lightweight access in Chat, and the architecture rules restate the division directly: Chat means lightweight, Platform means cloud workspace, Desktop means local agent workspace.

Neighboring capabilities are assigned differently. Computer is Platform-only: other products may use its runtime behind the scenes, but the full management surface stays in Platform. Local Models belongs primarily inside Desktop, not as a Platform web product. Studio, Research, Designer, and Founder are separate target applications, and Chat carries only limited versions of them. Code is the exception — the one capability meant to feel native in three places at once — with the constraint that all three share architecture and project state where appropriate.

The app registry anchors this on the implementation side. It records a code app at apps/code as a Next.js heavy-client editor workspace with an authenticated, browser-based surface, and a desktop app built on Electron with its own desktop lifecycle. Both are registered rather than certified, and the registry's header notes that certification state is never hand-set. Registration means the apps exist as recognized repo entries with declared shapes; it says nothing about what has shipped. The registry grounds the claim that Code and Desktop are real, structured applications, while the split describes where they are supposed to go.

Place 1: lightweight Code in Chat

Chat is the simple, general-purpose conversational product, and the plan insists it stay that way. Its canonical scope is core chat plus files, artifacts, tools, memory, and deliberately limited versions of the bigger products: limited Deep Research, a curated Studio experience, lightweight Designer, and lightweight Code. Chat should not contain the full Computer product, the full Research workspace, the full Studio catalog, or the full autonomous Founder system. That boundary is the whole point of Chat — fast and general, with an upgrade path into the specialized surface when the work outgrows conversation.

Lightweight Code in Chat therefore means conversational coding help: explain this code, write a function, fix this bug, make a React component, edit this snippet. These are the plan's own examples, and they share a shape. The unit of work is small — a question, a snippet, a single component — and the interaction stays in the thread. You bring the code to the conversation, the model responds in the conversation, and anything larger graduates elsewhere.

That graduation path is what makes the lightweight label honest. Chat's Studio section already models the pattern: a small set of flagship models with an explicit "more models" route into the full Studio app. Code follows the same logic. A developer who starts by asking Chat to explain a function and ends up planning a multi-file change has outgrown the thread; the design answer is to move into the Platform workspace, not to stretch Chat into a second-rate IDE.

What Chat Code is not matters as much as what it is. It is not a repository workspace: no branches, pull requests, builds, test runs, deployments, or environments. Those belong to the Platform Code target list. If you find yourself wishing the chat thread had a terminal, that wish is the plan working as intended — a signal to switch surfaces.

Place 2: Platform Code, the cloud engineering workspace

Platform is Ethen's operational control plane: the place for building, running, controlling, deploying, automating, and monitoring intelligence. Its final product list is Auto/Cortex, Code, Computer, Automation, Sentinel, AI Gateway, and GPU Compute. Platform Code is the cloud engineering workspace inside that control plane, and its target scope reads like a complete development environment: repositories, branches, agents, terminal, multi-file editing, pull requests, builds, tests, deployments, and environments.

Read that list as a design target, not a status report. It describes what the workspace is meant to contain when the work needs the full loop — from editing across files, to running checks, to opening a pull request, to deploying into an environment. The split document does not attach ship dates or availability to any of these items, and this article does not either. No claim here should be read as "type a prompt and get a merged PR" or "deploy from anywhere with one click." The honest statement is narrower: the plan gives the full repository-and-delivery loop exactly one canonical cloud home, and that home is Platform Code.

The implementation evidence supports the shape of that home without proving its completeness. The registry classifies the code app as a heavy-client editor workspace — the same heavy-client class as Studio and Designer — with authorized browser routes, session authentication, and a beta maturity label. That shape is consistent with a cloud coding environment; it is not a certificate that repositories, builds, or deployments are live. The registry also records the code app's deploy signal as none, which cuts against any assumption of a verified production deployment. The registry grounds "this is a real editor-workspace application under construction"; the split is the authority for "this is what it is for."

Platform context adds one more useful detail: Code sits alongside Computer, Automation, and Sentinel rather than absorbing them. Computer provides the Platform-only supervised browser and machine runtime; Automation owns workflows and schedules; Sentinel owns policy and audit. Because Code lives in the same control plane, the target workspace can draw on execution, automation, and governance without reimplementing them. That adjacency is architectural intent, not a shipped integration — but it explains why the cloud workspace belongs in Platform. The repository loop, the execution runtime, and the policy layer are neighbors by design.

Place 3: Desktop Code, the local environment

Desktop is Ethen's local intelligence environment, and its final structure is deliberately small: Chat, Code, and Local Models. Desktop Code is the local coding-agent environment in that trio, with a target scope of local repositories, local terminal, local models, Ethen cloud models, Git, agents, file editing, and commands. The defining difference from Platform Code is location: the repositories, the terminal, and the execution sit on your own machine.

Local Models is the pairing that makes Desktop Code distinctive. The split assigns Local Models primarily to Desktop — explicitly not as a Platform web product — covering discovery, download, installed and running models, updates, storage, quantization, hardware visibility, and local API endpoints. Model Library pages can offer a "run locally" path that launches Desktop, downloads the model, and runs it there. Desktop Code's target list includes both local models and Ethen cloud models, so the local environment is not cut off from the cloud; it is a place where you choose per task whether the model runs on your hardware or through Ethen's services. That choice is the product idea: keep the repository and the runtime nearby, and reach for cloud models when the work needs them.

The registry backs the local half of this picture at the structural level. Desktop is registered as an Electron application with a desktop lifecycle and an explicit entrypoint, distinct from every browser-based web product in the registry. That is the shape of an installable local application, consistent with a local environment that can own repositories, terminals, and model runtimes. Registration is not certification and not a launch announcement; the grounded claim is that Desktop exists as a structured local application — the intended vessel for local Code and Local Models — not that any particular local workflow has been released.

Persistence code adds a more granular piece of implementation evidence. The Code run-persistence module handles coding agent runs across two storage paths: browser localStorage for the web surface, and a file-backed JSON store under Electron userData (with a temp-directory fallback) for the Desktop path, written atomically through a temporary file and rename so a crash cannot leave a half-written store. Runs from older builds are normalized on load — every array and object field the current schema expects is backfilled — so stale data from a schema change cannot crash downstream code. None of this proves a finished local IDE. What it proves is narrower and still meaningful: the Code runtime is already engineered for runs that survive an app restart on both web and desktop, with the desktop path file-backed and crash-safe.

Identity scoping in the same module shows similar care about boundaries. Coding runs are stored under a per-owner scope: signed-in callers read and write only their own scope, anonymous use keeps a legacy global key, and owner transitions — sign-in, sign-out, account switch — discard the legacy key plus the previous owner's scope rather than adopting it. Sign-out runs a named sweep before any redirect, and a cross-tab broadcast tells follower tabs to fail closed. This is account isolation for run history, implemented in code. It does not claim cross-device sync or shared team state — only per-user scoping on the device, plus cleanup on identity change.

Choosing between the three

With the map in place, the practical question is which door to open. The split's answer follows from the shape of the work:

• Open Chat when the unit of work fits in a thread: understanding code, drafting a function, fixing a small bug, generating a component, editing a snippet. If the thread starts accumulating files, branches, or test output, that accumulation is the signal to move.
• Open Platform Code when the work is the repository loop: branches, multi-file changes, agents working across the tree, builds, tests, pull requests, deployments, environments. This is the target cloud home for everything Chat deliberately excludes.
• Open Desktop Code when the work belongs on your machine: local repositories, local terminal and Git workflows, file editing with local commands, and tasks where you want a local model — or a deliberate mix of local and cloud models — close to the code.

Two examples make the boundaries concrete. Onboarding to an unfamiliar codebase: start in Chat with explanations of specific functions, then move into Platform or Desktop Code once you begin changing files — explanation is conversational, change is workspace work. A bug fix with a test: the diagnosis might start as a pasted stack trace in Chat, but the fix itself — branch, edit, test run, pull request — is Platform Code's target loop, or Desktop Code's if the repository lives locally. The surfaces compose rather than compete: Chat for the question, the workspace for the change.

That composition depends on the shared-state constraint holding. The persistence module is early evidence of the instinct: one run model, normalized the same way, stored per-user, on both web and desktop paths. But shared run history is not a synchronized repository, and nothing in the inspected sources describes how — or whether — in-progress workspace state moves between Platform and Desktop today. Treat seamless handoff as design intent until release evidence says otherwise.

What this article does not promise

Because Code spans three surfaces, it is easy to overread the map as a menu of shipping features. Four limits keep the reading honest.

First, scope is not availability. The September 20 split is dated design authority: it defines canonical homes and boundaries, not launch status. The Platform workspace list and the Desktop environment list describe what each surface is for. They do not establish that repositories, builds, pull requests, deployments, or local-model execution are available to any particular user today.

Second, there is no universal prompt-to-PR story here. Moving from a conversational question to a merged change crosses surfaces, tools, and review steps by design — Chat for the question, a workspace for the change, and the repository's own checks in between. Any claim that a single prompt produces a pull request would need end-to-end evidence this article does not have and does not assert.

Third, deployment is the thinnest part of the map. Deployments and environments appear only inside the Platform Code target list; Chat Code has no deployment surface at all, and Desktop Code's target list centers on local execution rather than hosted delivery. Do not carry the word "deploy" from the Platform list into the other two surfaces.

Fourth, registration is not certification. The registry records Code as a beta heavy-client editor workspace and Desktop as an Electron application, both registered, with the code app showing no deploy signal. That grounds the applications as real and structured — it does not certify them, and the registry's own rules forbid treating registration as certification. Target separation is likewise not proof that any migration has shipped.

A three-surface design is only useful if readers can tell the plan from the product. The plan says: one Code system, lightweight in Chat, full in Platform's cloud, local in Desktop. The product question — what works today, for whom — belongs to release records, not to this map.

One system, three doors

Ethen Code's bet is that developers should not have to choose between conversational help, a cloud workspace, and a local environment — they should get one system that meets each kind of work where it lives. Chat keeps quick questions quick. Platform holds the repository loop. Desktop keeps the local repository, terminal, and models nearby. Shared architecture and per-user run state tie the three together, and the boundaries between them stay explicit so no surface swells into a second copy of the others. That is the target. What ships, and when, is a separate question — and worth asking surface by surface.