What We’ve Changed Since Ethen V4

Ethen V4 is the name we use for the previous generation of Ethen, when more capabilities shared fewer places. Since then, as of October 2026, we have changed six things. Every capability now has one canonical home. Chat, Code, Studio, Research, Designer, Founder, the Platform products and Desktop are separate surfaces for separate kinds of work. A shared reliability foundation sits underneath them: durable jobs, completion that depends on evidence, honest handling of unknown outcomes, and approvals bound to specific actions. Model knowledge is organized by family, with missing facts shown as unknown. Research and releases follow explicit evidence discipline. And each surface has been simplified. Several migrations are still open, and this record lists them. It describes changes documented in our published posts; it is not a launch announcement.

Key takeaways

• One home per capability. Other surfaces link or hand off instead of keeping their own copy.
• Separate apps for separate work. Conversation, code, creative work, research, design, jobs and operations each have their own surface.
• Reliability became shared infrastructure. Every app draws on the same durable-job and evidence foundation.
• Models are described by family. Thousands of endpoints became hundreds of understandable families.
• Claims carry evidence. Research is labeled by evidence status; releases are certified by scope and date.
• Not everything is finished. Research separation, Founder verification and other migrations remain open.

What do Ethen V4 and Ethen V5 mean?

Ethen V4 and Ethen V5 are generation labels, not release numbers with dates. V4 refers to the earlier generation of the Ethen experience. V5 refers to the direction we are building toward now, which we describe in The Road to Ethen V5 and Ethen V5: What We're Rebuilding and Why.

This article looks backward. It records what has changed so far, using only changes described in our published posts. That matters because version labels invite inflation: it is easy to describe a direction as though it had shipped. Here, a change is listed only if a public Ethen post documents it, and anything described in those posts as a target rather than a finished state is labeled that way. Figure 1 summarizes the six areas.

Change 1: every capability has one canonical home

The most important change is an ownership rule: a capability can appear on several surfaces, but it has one canonical owner and one shared backend and state. Before, capabilities could accumulate wherever they were first built. A design workspace, for example, lived as a route inside another app's shell, inheriting that host's layout, navigation and release assumptions.

The rule exists to stop competing copies of the same capability from drifting apart. When a feature lives in two places, fixes land in one of them; the other quietly ages. Our post How Upcube Is Organizing Ethen Across Specialized Apps describes the ownership map in detail, along with an important caveat: the map is design authority, not a shipping record.

The clearest completed example is Ethen Designer. It moved out of a route inside another app and into its own standalone application, with its code moved intact where possible, shells rewritten, and the moved code re-tested in its new home. The old location now hands off to the new one rather than keeping a second copy. We describe the move, and what it did not prove, in Moving Ethen Designer Into Its Own App. That move was verified locally; it was not a public launch.

Change 2: separate apps for separate kinds of work

The ownership rule produced a product map in which each kind of work has its own surface. Figure 2 shows where each kind of work now lives.

Chat stays deliberately small. It is the fast conversational surface, with lightweight entry points into research, creative work, design and code, and hand-offs to the app that owns each. We explain the boundary in Keeping Ethen Chat Focused.

Code is one system with three doors. Light help in Chat, a full cloud workspace in Platform, and a local environment in Desktop, sharing architecture and project state where appropriate.

Founder is its own product. It is shaped around a job — goal, plan, research, execution, approvals, verification, outcome — rather than a conversation. We explain why in Why Ethen Founder Is About Outcomes, Not More Chat.

Platform operates intelligence; it does not absorb apps. Computer, Automation, the AI Gateway, GPU Compute and security tooling live there, and Platform links to the specialized apps rather than duplicating them.

Desktop owns local AI. Local models live in Desktop rather than in a web console.

We give the reasoning for this structure in Why Ethen Is a Family of Specialized AI Apps, Not One App.

Change 3: reliability became a shared foundation

Reliability moved from something each product handled on its own to a foundation every product draws on. Our September 2026 engineering posts describe the pieces:

• Durable jobs. A shared job service lets AI work survive a worker crash without being run twice, using leases that stop stale workers from changing state and reconciliation for uncertain outcomes. See Inside Ethen's Durable Job Service.
• Completion that depends on evidence. In our early mission system, the component that performs a task cannot mark it successful on its own; an independent check backed by evidence decides.
• Unknown outcomes as a state. When an action's result is unclear, it is recorded as unknown and reconciled, not blindly retried.
• Verification budgets. Capacity for checking work is reserved before capacity for doing it.
• Approvals bound to actions. A computer-use approval applies to one specific action in one run and attempt, not to "keep going."

Several of these posts describe early-stage systems with stated limits. We summarize the direction across products in Improving Reliability Across Ethen.

Change 4: model knowledge is organized by family

Ethen now describes models by family rather than by raw endpoint. A snapshot of our media-model catalog grouped 1,499 provider endpoints into 491 model families, of which 128 qualified for a public, indexable page; see From Provider Endpoints to Ethen Model Families. The point is that a long list of endpoints is not knowledge. A family groups what is really one model offered in several ways, so people can compare things that are actually different.

We also changed how missing information is shown. When a benchmark value lacks a source, a date or a methodology, Ethen Model Intelligence displays "Unknown" with the reason attached, instead of filling the gap.

Change 5: research and releases follow evidence discipline

Two publishing changes reflect the same principle: say exactly what the evidence supports.

Ethen Research Lab publishes in public, with every publication labeled by type and evidence status — proposal, protocol, benchmark design, synthesis, or measured result. The research pages were redesigned around those labels; see Inside the Redesign of Ethen's Research Publications. Research is kept separate from product claims, so a research proposal is never presented as a shipped feature.

Releases are certified by scope and date. An Ethen release certificate records which checks ran, against what, on what date, and with what result — and distinguishes build evidence from evidence that a product is publicly available. See What a Release Certificate Actually Proves at Ethen.

Change 6: each surface does less, more completely

The last change is simplification. Giving each capability one home lets each surface drop what it does not own. Chat no longer needs to be a creative suite, a research workbench and a code environment. Studio can qualify a small number of creative workflows on verified routes rather than exposing every model behind a button. We explain the reasoning in Why We're Choosing Depth Over Feature Count.

Why we made these changes

The six changes share one cause: AI work got longer and more consequential, and a structure built for quick answers stopped fitting it.

Work started outliving conversations. When a task takes seconds, a chat thread is enough. When it takes an hour, involves several tools and produces artifacts someone must review, the work needs a home that persists, shows progress in phases and survives interruptions. That pushed long-running work out of the conversation and into apps built around jobs, projects and repositories.

Copies of the same capability drifted. A capability built in one place and copied into another tends to diverge: one copy gets the fix, the other keeps the bug. One canonical owner was the simplest rule that stopped this.

Fluent output was not enough. As models improved, their output looked finished more often, including when it was wrong. That made evidence — what was done, what was checked, what is unknown — more valuable to people reviewing the work, not less.

Lists were not knowledge. A catalog of endpoints, or a menu of model options, told people what existed but not what to choose. Grouping by family and showing unknowns honestly was a response to that.

The same request, before and after

The following example is illustrative and simplified.

In the earlier generation, someone asking for a researched competitive summary with a few supporting charts would typically do everything in one conversation: ask, wait, read a long answer, ask for charts, copy results elsewhere. If the session ended, much of the context went with it. If a step failed, the simplest recovery was to ask again.

In the current direction, the same request starts in Chat, where a quick answer is still the right first step. If the person wants to go deeper, the work hands off to Research, where sources, branches and history persist and can be revisited. Charts or visuals become a Studio task with its own inputs and record. If the work is a goal rather than a question — "keep this summary current every month and tell me when something important changes" — it becomes a Founder-shaped job with approvals and evidence. Each step happens in the surface built for it, and each surface knows where to send the person next.

Not every hand-off in that example exists as a finished product today; several are the open migrations listed below. The example shows the shape the changes are aiming for.

What has not changed

Some things are deliberately the same as in the V4 generation.

The goal. Ethen exists to help people finish real work, not to maximize time spent talking to an AI.

Many models, chosen by task. Ethen still works with multiple model providers and chooses among them by what the work needs.

People approve consequential actions. Delegation is bounded, and actions with real consequences require a person's approval.

Honesty about limits. We still try to say what we do not know, in products and in writing.

What is still unfinished

A historical record should say what has not finished. Figure 3 summarizes the status as of this writing.

Our published ownership map lists the migrations still needed. Research as a standalone app is a target, not an established fact. Founder must move from direction to a verified product. Computer management must consolidate in Platform. Studio's catalog boundary in Chat needs ongoing enforcement; our Chat post notes that the current model picker lists more than the curated design calls for. And public availability must be established product by product, with its own evidence, rather than inferred from architecture.

What we learned along the way

Rebuilding by moving, not rewriting, keeps history readable. Moving working code intact, rewriting only the shells, and re-testing in the new home made it possible to tell "this moved" from "this changed." Martin Fowler's "strangler fig" pattern, described in 2004, captures the same idea: grow the new structure around the old one and retire pieces gradually, rather than replacing everything at once.

Software that is used must keep changing. Manny Lehman's 1980 laws of software evolution observed that a system in real use must be continually adapted, and that its complexity grows unless work is done to reduce it. Much of this generation's work was that reduction work.

A new generation is tempted to do everything. Fred Brooks warned in 1975 about the "second-system effect": the tendency of a successor system to be overloaded with every idea deferred from the first. Holding to one owner per capability, and to depth over breadth, is partly a defense against that.

How to read this record

This is a dated historical record. We will not silently rewrite it as things change. When a migration listed here completes, or a statement here turns out to need correction, we will add a dated update note below and leave the original text visible. For the current state of a specific product, look for that product's own release evidence rather than this summary. For the broader October 2026 picture, see What We're Building Across Ethen: October 2026 Update.

FAQ

What changed between Ethen V4 and Ethen V5? Ethen gave every capability one canonical home, separated its apps by kind of work, built a shared reliability foundation, organized model knowledge by family, adopted evidence labels for research and releases, and simplified each surface. Several migrations remain open.

Why did Ethen split into separate apps? Because different kinds of work need different state, controls and evidence. One owner per capability stops copies of the same feature from drifting apart.

Is Ethen V5 released? V5 is a direction, not a dated release. Individual products become available with their own release evidence; this article makes no availability claim.

What is still unfinished? A standalone Research app, Founder as a verified product, Computer consolidation in Platform, the Studio catalog boundary in Chat, and per-product public availability.

Will this article be updated? Only through dated update notes. The original record stays visible.

Update notes

• October 2026: Original record.

Related reading

• The Road to Ethen V5
• Ethen V5: What We're Rebuilding and Why
• What We're Building Across Ethen: October 2026 Update
• How Upcube Is Organizing Ethen Across Specialized Apps
• Ethen Research Lab

References

1. Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060–1076. https://doi.org/10.1109/PROC.1980.11805
2. Fowler, M. (2004). StranglerFigApplication. martinfowler.com. https://martinfowler.com/bliki/StranglerFigApplication.html
3. Brooks, F. P., Jr. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley (chapter "The Second-System Effect").