When your coding tool changes owners.

The engines folder almost vanished.

Luminair is built inside Luminair, and the idea in this post came from a scare. On 16 August 2026 a commit titled “Track the engine registry in git” admitted that the whole engines folder had never been added to the repository. All seven engine files of the time, the shared runner, the loader and the template “lived only on this Mac”. A clean checkout built an app with no engines at all.

That commit put 3,037 lines under version control. It also made the design visible: each vendor was already a separate file, shaped by one template, with nothing else in the app hard-wired to a particular company. Since then the folder has grown to fifteen engine files, and every one of them followed the same path in.

Coding tools get bought.

On 14 August 2026 Cursor's blog put it in one line: “Cursor has officially been acquired by SpaceX.” The post says the process started in April with a partnership with SpaceXAI, and that the company will now have “access to the largest fleet of GPUs in the world”. It also points to Grok 4.6 as “an early look at what we can now build together.”

TechCrunch filled in the rest the next day. The April deal gave SpaceX the option to acquire Cursor for $60 billion, and SpaceX had already acquired xAI earlier in the year.

Nothing in the announcement says anything will get worse for Cursor's users. It promises “more capable models at lower cost”. That is not the point. The point is that the tool many developers open first thing in the morning now has a new parent with its own models, its own compute and its own plans. Pricing, default models and priorities are decided by whoever owns the tool.

The market is also moving fast underneath. JetBrains surveyed more than 15,000 professional developers for its August 2026 report on coding agents. Between January and May to July 2026, Claude Code use at work went from 18% to around 39%, Codex from 3% to 16%, and Cursor from 18% to 12%. In the same survey, 90% of professional developers used AI coding agents at work at least weekly.

The sensible response is not to pick the winner. It is to keep the switching cost low. In software, that has a familiar name: treat the thing as a dependency.

Adding a vendor is one file.

Luminair calls each vendor's agent an engine. Claude, Codex, Gemini, Kimi, Antigravity, Grok, DeepSeek, local models through Ollama and LM Studio: each is one file in desktop/engines. The loader reads every file in the folder, with a few exceptions it spells out:

if (f === 'index.js' || f === 'runner-cli.js' || f.endsWith('-run.js')
    || f.startsWith('_') || f.startsWith('.')) continue;
try {
  const mod = require(path.join(__dirname, f));
  ...
} catch (e) {
  // A broken engine file must never take the app down with it.
}

The template, _TEMPLATE.js, starts with the whole job in three steps: copy the file, fill in the parts marked TODO, restart. Its header lists what then comes for free: “The model picker, the account menu, the ‘add account’ list, badges, colours, per session engine memory, the run, Stop, queues, live mirrors and token meters all pick it up.”

Every field is optional except id. An engine whose tool is not installed reports itself unavailable instead of crashing a send. And a vendor that streams JSON lines from a command-line tool only has to translate one line at a time into Luminair's small vocabulary: session, text, thinking, tool, usage, done, error. The shared runner handles the rest.

This is what makes a change of owner survivable. If a vendor's terms, prices or tool change, the blast radius is one file. If a new vendor appears, it is one new file. The template's comments even ask for one hue per engine so you can tell at a glance which company is running a turn.

New versions arrive on purpose.

Most engines drive the vendor's own command-line tool. Those tools are not downloaded behind your back at run time. They are regular npm dependencies of the desktop app, with version numbers in package.json, unpacked next to the app so they can be launched.

The repository has Dependabot switched on for the desktop folder, checking weekly. In September it proposed new versions of all four vendor tools, including Kimi Code jumping a major version from 0.36.0 to 2.1.1. Here is the part that surprised us when we counted: of the 35 pull requests Dependabot has opened on the repository, none was merged. They work as a notice. The bumps that shipped were made by hand, in the app's own commits.

Why not just merge them? Because a vendor tool is not a library you call; it is the agent itself. A new version can change how it prints events, what models it accepts, or how it logs in. Luminair has 55 conformance tests that replay recorded vendor output through the real parsers and runner, but a recording only proves something about the version that produced it. A new version is a new thing to check.

There is a catch, and it bit us. On 4 September a new OpenAI model, GPT-6 Astra, came out, and the bundled Codex 0.147 could not run it until an app release carried 0.153. The comment at the top of lib/cli-updater.js records exactly that. The fix, from 7 September, is a second path that is still deliberate:

The conversation is yours.

Switching tools usually costs you the thread. Each vendor keeps its own session files in its own format, and they do not read each other's.

Luminair keeps a copy of its own. Since August 2026, every line it sees in a session transcript is copied once into an append-only session ledger on your Mac, which neither the vendor's compaction nor Luminair's archive clean-up is allowed to trim. It was built to fix lost recall on long sessions, and it has a second effect: the record of a conversation does not depend on which company ran it.

When you move a session to another engine, Luminair builds a handoff from that record: up to 16,000 characters, filled newest turn first, each turn cut at 4,000. For Claude it can go one step further and write a native session file from the ledger, so the Claude SDK can resume a session that was born on another engine.

A switch on one vendor must not move another.

Using several vendors means holding several logins. Luminair shows the one in use as an account chip. For a while that chip was a single global setting, and in the first week of September that caused a quiet, expensive bug.

When Codex failed over from one of its accounts to another, or you simply picked a Codex account, the chip moved to Codex. From that moment no Claude account was “active”, so every open Claude session fell back to the account it was born on. The code comment describes the result: three panes kept hammering a maxed-out Primary account while the user had already switched.

The fix keeps a small map, activeByEngine, updated every time the settings are saved. Each engine remembers the last account you chose for it. Choosing a Codex account now says nothing about Claude, and the reverse.

A regression test pins this down with a Codex chip selected and a second Claude account remembered: an old Claude session routes to that second Claude account. The same test file asserts the opposite guard too. If you have no account for a vendor, Luminair will not quietly run your Claude turn on someone else's model. Its message in the test reads “never substitute another brand”.

What we checked, and what we can't fix.

For how Luminair picks a model per turn once several engines are connected, read One window for every model.

Sources

• Cursor · 14 August 2026Cursor is now a part of SpaceX
• TechCrunch · 15 August 2026SpaceX officially closes its Cursor acquisition
• The JetBrains Blog · August 2026AI Coding Agents: Adoption Trends