How Upcube Is Organizing Ethen Across Specialized Apps

Upcube's September 20 architecture map gives every Ethen capability one canonical home — and leaves several migrations visibly unfinished.

Ethen is not being built as one application. The September 20 product/platform split document, the current design authority for how Ethen is organized, lays out five surfaces — Marketing Web, Chat, specialized apps, Platform, and Desktop — and assigns each capability to exactly one of them. The operating rule is stated plainly: one capability can appear on multiple surfaces, but it should have one canonical product owner and one shared backend and state. The point of the rule is to avoid separate, conflicting versions of the same product.

This article explains that ownership map and the migrations it still requires. Two caveats apply to everything that follows. First, the September 20 document is a design authority, not a shipping record: describing a target home for a product does not establish that the product has launched or that any migration has completed. Second, the repository's app registry, dated September 14, predates the map by six days, so its entries describe repo structure as of that earlier date — useful corroboration of direction, not proof of the finished state.

The map at a glance

The top-level structure has five branches. Marketing Web covers discovery, education, publishing, and model intelligence. Chat is the simple general-purpose conversational product. The specialized apps — Studio, Research, Designer, and Founder — each own a focused professional workflow. Platform is the operational control plane with seven products: Auto/Cortex, Code, Computer, Automation, Sentinel, AI Gateway, and GPU Compute. Desktop is the local environment with Chat, Code, and Local Models.

The document also gives each surface a one-line mental model. Marketing Web means "discover Ethen and intelligence." Chat means "interact with intelligence." The specialized apps mean "do focused professional work with intelligence." Platform means "operate intelligence." Desktop means "run intelligence on your own machine." These lines matter because they are boundary statements: when a feature proposal does not fit its surface's sentence, it probably belongs somewhere else.

Marketing Web: discovery, publishing, and the Model Library

Marketing Web is the public front door. Its canonical scope includes the home page, product pages, pricing, docs, the Model Library, Model Intelligence, the Blog, and the Ethen Research Lab. Two ownership decisions here are worth noting because they run against the instinct to put everything operational inside Platform.

First, the Model Library and Model Intelligence live on Marketing Web, not in Platform. The Model Library is the canonical home for model discovery, organized into sections such as All Models, Open Source, Closed Source, Text, Image, Video, Audio, Embeddings, Providers, Benchmarks, Comparisons, Pricing, Capabilities, and individual model pages. Model Intelligence is the data system behind the library; the user-facing term is primarily "Model Library." A model page is designed as a distribution surface: from it, a user should be able to try the model in Chat, open it in Studio, run it locally, deploy it on Ethen GPU, or use it through the AI Gateway. That single design makes the library a routing point into nearly every other surface.

Second, the Blog and the Ethen Research Lab are separate publications with separate questions. The Blog answers "what is Ethen building" — launches, feature updates, architecture changes, engineering milestones, model releases, infrastructure updates, and company announcements. The Research Lab answers "what is Ethen researching and learning" — research articles, technical reports, model evaluations, benchmark studies, experiments, and datasets across areas from agents and autonomy to economics and infrastructure. The split document is explicit that the Research Lab should not be treated as merely another Blog category.

Chat stays deliberately small

Chat is defined as the simple, general-purpose conversational product, and the document insists it remain intentionally limited rather than becoming the full Ethen ecosystem. Its canonical scope is Core Chat plus a model selector, files, artifacts, tools, memory, limited Deep Research, limited Studio, lightweight Designer, and lightweight Code.

The exclusions are as important as the inclusions: Chat should not contain the full Computer product, the full Research workspace, the full Studio catalog, or the full autonomous Founder system. Each "limited" or "lightweight" entry is a boundary with a named escape hatch into the canonical app:

• Limited Deep Research in Chat is a fast, conversational experience powered through the OpenAI Deep Research API — prompt, research run, sources, citations, final answer or report. The full Ethen Research application is a different product for users who need more power, and Chat can link into it.
• Limited Studio in Chat is a curated experience using flagship models — image, video, audio, and a voice entry — with a small set of recommended options such as Recommended Image, Fast Image, Recommended Video, Fast Video, and Recommended Audio. The full catalog lives in Studio, reached through "More models → Open Ethen Studio."
• Lightweight Designer in Chat handles quick requests such as "design this page" or "turn this screenshot into a UI." The full design and build workspace — projects, canvas, components, design systems, code, preview, deploy, domains, version history — belongs to the Designer app.
• Lightweight Code in Chat covers conversational help such as explaining code, writing a function, or fixing a bug. Repository-scale work belongs to Platform Code or Desktop Code.

Voice follows the same pattern: conversational voice — live conversation, questions, brainstorming, assistant interaction — stays in Chat, while voice generation, speech models, narration, and voice projects belong to Studio.

Four specialized apps, four professional workflows

Studio, Research, Designer, and Founder are the products for focused professional work, and each is a separate target application rather than a Chat mode.

Studio is the canonical home for the large creative model catalog, covering image, video, audio, voice, editing, upscaling, generation, workflows, projects, history, assets, and a Model Explorer. The Chat-versus-Studio distinction is simplicity versus completeness: curated flagship models in Chat, the full creative platform in Studio. Readers should note that the design document names a catalog size figure, but that figure is a design-target statement, not verified inventory — this article makes no claim about how many models any catalog currently contains.

Research is specified as its own dedicated Next.js application with projects, searches, sources, evidence, branches, research agents, files, notes, citations, reports, research history, model selection, and research workflows. The document says the full app can eventually use Ethen's own research runtime and multi-model orchestration. The word "eventually" carries real weight here: the claim limit on this article requires stating plainly that Research separation is not established. The September 20 map assigns Research its own home; it does not prove a standalone Research application exists or has shipped.

Designer pairs a lightweight Chat experience with a full application owning the complete design-to-deploy workflow. Founder goes further: it is not a Chat persona but the autonomous-jobs product, specified as its own dedicated Next.js application and platform. Its scope — New Job, Jobs, Runs, Plans, Tasks, Evidence, Approvals, Files, Connections, Spend, Activity, Results — supports an execution model that runs from goal through planning, research, execution with tools and browser or computer runtimes, approvals, verification, and delivered outcome. Founder can use the Missions architecture underneath — Mission Contract, Constraint Ledger, Authority Envelope, execution, verification, evidence, recovery — but the customer-facing product remains Founder.

Platform: the control plane, not the everything app

Platform is defined as the operational control plane: building, running, controlling, deploying, automating, and monitoring intelligence. Its seven products are Auto/Cortex, Code, Computer, Automation, Sentinel, AI Gateway, and GPU Compute. Just as notable is what Platform must not absorb: Studio, Research, Designer, Founder, Model Intelligence, and Local Models. Those products may be linked from Platform, but they remain separate applications.

Each Platform product has a defined scope. Auto/Cortex is the orchestration and autonomous execution control layer — agents, runs, plans, models, tools, approvals, policies, budgets, execution, verification, observability — that Founder may use internally while advanced users get the full operating surface. Computer belongs in Platform only: sessions, browser, machines, screens, actions, permissions, takeover, history, credentials, logs, and execution state. Other products such as Founder or Auto may use the computer runtime behind the scenes — a Founder job driving a website action, for example — but the full management UI stays in Platform and Computer is explicitly not a Chat surface. Automation owns workflows, triggers, schedules, runs, logs, connections, errors, retries, secrets, and status; Founder and Auto can create or invoke automations, but configuration and management belong in Platform. Sentinel is the security, policy, governance, and monitoring system whose decisions other apps can consume while the management interface stays in Platform. The AI Gateway owns providers, models, API keys, routing, fallbacks, rate limits, usage, logs, costs, latency, caching, health, quotas, policies, and analytics; the Model Library and docs can offer "use via Ethen Gateway," but operation happens through Platform. GPU Compute owns deployment, scheduling, routing, capacity, health, runtime, scaling, endpoints, usage, and cost, with its primary user flow starting at an open-source model page and its positioning framed as deploying open models rather than merely renting GPUs.

The launcher strategy resolves the tension between unity and absorption: Platform may expose a sidebar with its own BUILD, OPERATE, and INFRASTRUCTURE sections plus an "Ethen Apps" section linking out to Chat, Research, Studio, Designer, and Founder. One ecosystem, without Platform becoming a duplicate of every product.

Desktop: local Chat, Code, and models

Desktop is the local intelligence environment, structured as Chat, Code, and Local Models. The key ownership statement is that Local Models is not a Platform web product — it belongs primarily inside Desktop, combining local model running with discovery, download, installed and running inventories, updates, storage, quantization, GPU, CPU, RAM, and local API endpoints. Model Library pages can offer "Run locally," launching Desktop to download and run the model. The repository registry corroborates this direction structurally: it records a desktop app and a local-runtime daemon as separate registered entries, though as always, registration is not release.

Code lives in three places by design

Code is the deliberate exception to one-surface thinking, and the document stresses this is not accidental duplication: one Code system is exposed through three UX levels. Chat Code is lightweight conversational coding — explain, write, fix, generate a component, edit a snippet. Platform Code is the full cloud engineering workspace — repositories, branches, agents, terminal, multi-file editing, pull requests, builds, tests, deployments, environments. Desktop Code is the local coding-agent environment — local repositories, local terminal, local models alongside Ethen cloud models, Git, agents, file editing, commands. All three should share architecture and project state where appropriate.

What the repository registry already shows

The app registry inspected for this article, a repo-truth snapshot dated September 14, records the structural side of this story. It lists separate registered apps for chat-core, code, computer, designer, founder, infrastructure, local-runtime, missions-core, platform-core, studio, voice, web, desktop, and supporting services — consistent with the direction of specialized applications rather than one monolith. Several entries carry maturity labels such as production, beta, preview, or skeleton, and the registry's own header warns that certification state is never hand-set to certified.

The details that matter most are the humble ones. Most entries show a deploy signal of "none," and chat-core, auth-api, and platform-core are among the few with vercel configuration signals. The creative entry is explicitly a skeleton with no production routes moved. The desktop entry carries a note about a stale default renderer URL. The founder and computer entries sit at preview maturity. And no standalone research app entry appears in the registry at all — consistent with the claim limit that Research separation is not established. None of this is a launch announcement in either direction; it is repo metadata describing structure at a date, and this article treats it strictly as that.

The migrations still needed

Reading the September 20 target against the September 14 repo snapshot produces the migration list this article promised:

1. Research needs its own application. The map specifies a dedicated Next.js Research app with projects, evidence, branches, agents, and workflows, but separation is not established, and Chat's limited Deep Research via an external API is the only research surface the map describes as Chat-scoped.
2. Founder must graduate from direction to verified product. The map specifies a standalone Next.js autonomous-jobs application on missions infrastructure; the registry shows a preview-maturity founder app with no deploy signal.
3. Computer management must consolidate in Platform. The map makes Computer Platform-only with other apps as runtime consumers; the registry shows a preview computer app, and any Chat-embedded computer surface would contradict the target.
4. Studio's catalog boundary needs enforcement. Chat is supposed to show only curated flagship models with a handoff to Studio; keeping the full catalog out of Chat is an ongoing migration, not a one-time statement.
5. Local Models must live on Desktop, not Platform. The map is explicit, and Model Library "Run locally" links are the bridge — a flow that requires Desktop distribution to exist.
6. Platform must resist absorption. Every out-of-scope product — Studio, Research, Designer, Founder, Model Intelligence, Local Models — needs links rather than duplicated management surfaces, per the launcher strategy.
7. Deploy and certification evidence must catch up everywhere. Registry entries at REGISTERED state with "none" deploy signals describe code organization, not availability; each product still needs its own verified path to production.

What this article does not claim

No product launch, availability date, access condition, metric, customer, or partnership is claimed here. The September 20 map is design authority: it says where things belong, not what has shipped. Research separation and all product launches are explicitly not established. Catalog size figures, GPU infrastructure sources, and universal promises such as deploying any model are design-target language in the source document, repeated here only as design intent where mentioned at all. Readers evaluating any Ethen product should look for that product's own release evidence, not this architecture map.

Upcube's organization of Ethen is a bet that specialized surfaces with one owner each will beat both the single overloaded app and the pile of disconnected copies. The map is drawn; the migrations are the work.