bmux.leverine.com · experiment status · updated 10 November 2026

Panes are great.
We have them. We sort of have them.

BMUX is a browser multiplexer: it splits one tab into panes and lets you and an agent work across them at once. We are porting it into Leverine's workspace. This page is the honest status report — what it is good for, and all the ways it is currently not working out.

status: it's complicated · commands failing at a rate we are now able to count

First, the genuinely good part

None of the problems on this page are “panes were a bad idea”. Panes are a very good idea, which is exactly why we keep flogging them. What BMUX gets right, in one go:

One tab, several pages

Compare three environments without five windows: test, staging, production, side by side, same viewport, same session, no tab gymnastics.

The agent can see all of them

Not “the active tab, if you ask nicely” — every pane, including cross-origin ones, through the same broker that gates every other read. A pane is a permission-scoped document, not a screenshot.

One grammar, two users

Every command you can type, the model can call — same validation, same refusals, same status line. There is no second, cosier path for the machine.

Scripts are data

A .mux file is a list of those commands. No expressions, no variables, nothing that can decide to do something you did not write down. Where BMUX stripped frame protections browser-wide, here it is one tab, revoked when the pane closes, and only a person can allow it.

Now the part where it is not working out

We added a flight recorder, because “so many commands are failing” is not a bug report — it is five different bugs wearing one sentence. Each op is now stamped where it happened, with a reason from a closed set. Here is what a bad afternoon looks like:

panel → ◫ → diagnostics

18:02:11 ✗ worker/panel.command:split-window 6003ms — timeout
18:02:10 ✗ content/mux.command 1ms — not_open: The workspace is not open in this tab.
18:02:10 ✗ panel.state 800ms — timeout
18:01:58 ✗ tool:open 2ms — no_receiver: the tab did not answer
18:01:58 · worker/mux.command:focus-pane 4ms
18:01:57 ✗ content/mux.command 2ms — refused: This plan allows 2 panes. Close one first.
18:01:57 ✗ content/mux.command 1ms — unknown_action: Unknown workspace op "mux.restore"
18:01:56 · worker/mux.toggle 118ms
18:01:56 … 18 op(s), 11 failed — 6× no_receiver, 3× not_open, 1× refused, 1× timeout

Excuse	What it actually means	How it feels
no_receiver	the message never reached the page — wrong tab, a restricted page, or a content script that is not there yet	you click, nothing happens, the panel is very calm about it
not_open	it arrived, but no workspace is mounted in that document	“open the workspace first” — it is open, in a different frame
unknown_action	the dispatcher does not know that command	a document said this works
refused	the workspace said no: pane limit, framing, selector	the only one that explains itself, and therefore the only popular one
timeout	nothing answered in time	a spinner, then a shrug

Three bugs worth naming, because they were ours and not BMUX's

The drawer said “no workspace on this tab” while the workspace was on that tab. The panel read a field that did not exist — the content script wraps its reply in an envelope, and we read the outside instead of the inside. Every drawer button was politely doing nothing, for two releases.
The assistant answered about a page nobody could see. With the overlay open, the page underneath is covered; the model had the page's text and no idea the panes existed. It now gets a block naming the panes before any page content.
Framing. Some sites refuse to be framed, which is their right. Ours is a card that says so, and a tier-4 decision a person has to make per origin. It turns out that “just frame it” is the whole of BMUX's product, and here it is the part we are least willing to do.

What we have done about it, so far

A dev build with no gates — every capability allowed, approvals never asking, workspace forced on, so a failing command can be reproduced without ten clicks in the way. It announces itself everywhere and refuses to be packaged.
The flight recorder — both halves: what the page received, what the worker was asked for. Copyable as JSON, which is how the tally above got to exist.
One click to a workspace, instead of a menu button and then a drawer and then a button in the drawer.
An honest envelope — one function now owns the unwrap that three call sites each got wrong.

The question this page is really about

We are not asking whether panes are nice. We are asking whether this earns its place in the product, and the numbers are not there yet:

cut itkeep it

Currently at “we would miss it, but we would also get an hour of our life back”. The decision hangs on whether the command success rate can be fixed, and whether the panes earn the framing problem they drag in.

“Open the workspace first.”
— the workspace, open in front of us, refusing a command a real afternoon in October

What this page is not

not a merger separate projects

BMUX and Leverine are kept separate. BMUX is its own project, MIT licensed, and stays that way: it is a multiplexer, it does one thing, and it is maintained on its own terms. What exists here is an experiment — a port of BMUX's ideas into Leverine's workspace, because a browser extension with an agent in it can hold both halves. Nothing on this page claims BMUX is part of Leverine, or that Leverine is BMUX, or that the two are merging. If the experiment proves itself, the relationship will be attributed properly and in writing. If it does not, the panes come out and BMUX stays exactly what it was — a good idea in a different body.

And to be fair to BMUX: the panes that do work, work. It is the plumbing between a page, a worker and a panel that keeps dropping its end of the conversation — and that plumbing is ours.

No uptime claim, no roadmap date, no “coming soon”. This is a status report with jokes, published because the alternative was a changelog nobody reads and a support thread nobody enjoys.
If the panes work for you, tell us what you were doing. If they do not, the log button is in the panel's workspace drawer, and it is the one thing on this page that has earned its keep.