Main idea

The context engine ported onto ChatGPT is inferior on almost every point to the one that runs with Codex or Claude Code: slower, unable to execute Python scripts or call APIs, with no perspective on what it becomes when a context grows over several weeks. Compared function by function, it loses. Yet it is not a rough draft of the first: it lifts the one constraint the first will never lift, that of depending on a machine that is powered on and reachable.

So two systems coexist, and the choice between them is made not on their capabilities but on the situation: at the desk, the full engine; on the move, the standalone mode. A degraded system becomes a mode when it is chosen for what it unblocks, and remains a stopgap when it is chosen for lack of anything better.

Why it matters

This avoids two symmetrical mistakes. The first is abandoning a poorer version because the feature comparison goes against it, when it serves a case the other does not. The second is trying to make it converge towards the full version, which costs it the lightness that made it usable where the other is not.

It also gives the right question to ask in front of a less capable alternative: which constraint does it lift, and is that constraint real in my use?

Nuances and limits

Coexistence has a cost the article does not quantify: two sets of instructions to maintain, two behaviours to know, and the risk that contexts created on one side cannot be used on the other.

And the justification falls away as soon as the constraint disappears. If the full system becomes reachable without a personal machine, the second mode loses its reason to exist — it cannot make up for it on features.

Open questions

• What has to stay common between two modes of the same system for material produced in one to remain usable in the other?