Xenon v4.11.5: you choose the AI model, and a Windows install that fails finally leaves a trace
Latest
Two things in this release. Which AI model Xenon uses stops being a decision someone else made when the app was built — every provider now shows the models your own key can reach, with an "Auto" that follows the newest one without an update to install. And on Windows, a setup that goes wrong finally leaves something to read: until now the only place it ever spoke was a console window that closed over its own error message.
Beside those, a screen mounted vertically gets a layout that fits it, your supporter code is asked for once instead of once per drop, and the native shell stops closing itself without a word.
Added
You can choose which AI model Xenon uses, and it keeps itself current. Every provider now has a model list in Settings under Xenon AI, filled from your own account, so it shows what that provider offers today rather than a list written when Xenon was released. Gemini had no picker at all until now, and its four models — chat, advanced reasoning, voice, Live Voice — were fixed in the code.
Each list starts with "Auto". That is not a model, it is an instruction: use the newest model of that family your key can reach. Pick "Auto" and a model released next month is in use next month, with nothing to install. Pick a family, like Flash or Sonnet, and Auto stays inside it, so it never moves you to a more expensive tier on its own. Pick a model by name and it stays that model until you change it. When Auto is selected, the line under the list tells you which model it currently resolves to, so you can always see what is actually running.
Your existing choices are untouched. If you had picked a ChatGPT or Claude model it stays picked.
The voice models are selectable too, and the voice no longer depends on one of them surviving. Gemini's speech and Live Voice models, and OpenAI's transcription and speech models, each have their own entry under "Voice models". Gemini's speech model is a preview model, which is the kind that gets retired, and until now that would have taken the assistant's voice with it. If it ever fails, Xenon now falls back to the local Edge voice that is already installed and needs no key. The voice changes, the feature keeps working.
A screen mounted vertically gets a layout that fits it. Until now, turning a display to portrait left the dashboard on its 24 column grid, so the layout you built on a wide screen was drawn as a miniature of itself in a narrow strip. A tall screen now stacks the tiles into one full width column, one under the other, in the same order you read them on the grid. Nothing about your layout is changed or saved over: this is only how it is drawn on that screen, and the dashboard on your other screens is untouched.
There is a switch for it in Settings under General, called "Tile layout", with Automatic, Single column and Grid. It stays on the device you set it on and is not synced to the others, because the same dashboard is open on screens that want different answers. A tall screen that is still wide enough for the grid, above about 1120 pixels, keeps the grid.
Your supporter code is asked for once, not for every drop. A supporter code opens every supporter creation, but until now it had to be pasted again for each one, from the email or wherever you had kept it. There is now a place for it in Settings, under Widgets and sharing: paste it once and every supporter drop from then on unlocks with a single tap. If you have never been there, the first drop you unlock saves it on its own. Typing a different code still wins, which is what limited and purchased drops need, since those have a code of their own.
The code stays on that PC. It is never sent back to the dashboard, so it does not travel to a paired phone or to another browser, and the same Settings block says whether this machine holds one and has a button to remove it. If your code is ever replaced, Xenon notices the first time it stops working, forgets it, and asks for the new one instead of failing over and over. Nothing changes about how the code itself works: still yours, still good for up to 3 of your devices, still valid while your supporter period is active, and what you have unlocked stays unlocked for good.
The list of local models to download comes from the website. Xenon's local AI offered four models chosen when the feature was written. That list now comes from a file on xenon-app.com, so new models can be added without an app update, and it carries the real download size and hardware requirement of each one. Your machine still decides what it can run: the hardware check is local and the built-in limits always win, so nothing on the internet can talk your PC into loading a model it cannot hold. And a model you have already installed is now asked directly what it can do, instead of being guessed at by its name, so a newer model that can read images is no longer treated as text-only.
Fixed
A Windows install that goes wrong now leaves something to read. The app you download on Windows is only the screen. The dashboard engine behind it is installed by the Complete setup button on the first-run panel, in a console window that opens for it — and that window was the only place the setup ever said anything. So when it failed, or was closed, or PowerShell hit an error that ended the script and took the window down with its own explanation, nothing was left anywhere on the PC to say what had happened. What you are left looking at is an install folder holding three things — xenon-native.exe, the uninstaller and a windows folder — with no server folder, no Node.js, and no way to tell which step never ran. Reported on Discord more than once, and every time the only way forward was to ask the person to do the whole thing again and watch it happen.
Every run of the setup is now written to %LOCALAPPDATA%\Xenon\setup.log as it goes, and the run before it is kept beside it as setup.log.1 — the interesting one is often the attempt before the retry that finally gets reported. The elevated half of the install, which runs in a second window that closes the instant it ends, appends to that same file, so one file holds the whole story from the download to the last component. INSTALL.bat writes it too. Every run ends by printing where the file is, whether it worked or not, and the first-run panel names it as well when the setup did not take. The uninstaller removes it with everything else. And an unexpected error no longer closes the window over its own message: anything that stops either script the hard way is caught, named along with the line that raised it, written to the log, and left on screen with the window waiting for you.
The app no longer closes itself without a word — and when something else closes it, there is finally a record of that. The native shell was built so that a failure anywhere inside it ended the process on the spot: no window, no message, nothing written anywhere, since the app runs with no console to print to. Three of its parts poll Windows for as long as it is open — the watchdog that keeps the dashboard on the screen you chose, and the two guards that look after the mouse and the focus of a running game — and one bad answer from the operating system in any of them was enough to take the whole window down mid-session.
A failure in one of those watchers is now written down and the watcher started again, with the window left exactly where it was. And whatever happens, the shell keeps a small diary beside its settings: one line when it starts, one when it stops, one when something fails, with the tray menu's Open crash log to open it. That is what separates the two situations that look identical from the outside. A start followed by a failure line is Xenon's own fault, and the line names the exact place it failed, so pasting it into Discord or a bug report is usually all a fix takes. A start with nothing after it means nothing inside the app decided to stop — the process was ended from outside it, which on Windows is nearly always the antivirus quarantining Xenon while it is running, hours after it let the installer through. The README now covers that case as well, including the second folder the exclusion has to name: Xenon lives in both %LOCALAPPDATA%\Xenon and %LOCALAPPDATA%\Programs\Xenon, and excluding only the first leaves the half that runs all day exposed.
Xenon starts on a laptop running on battery, and no longer stops when you unplug. The task that starts the dashboard when you sign in was registered with the two conditions Windows applies when nobody says otherwise: do not start on battery, and stop if the charger comes out. On a desktop that never showed. On a laptop it meant the dashboard was missing whenever you were unplugged, and vanished mid-use the moment you pulled the cable, which reads exactly like a crash. New installs no longer carry those conditions. An install you already have keeps them until the app repairs it, which it now offers to do, or you can clear them yourself in Task Scheduler under Xenon Edge Widget, Properties, Conditions.
When Xenon's startup has been switched off, the app says so instead of spinning. Windows lists Xenon's startup in Task Manager under "Startup apps", and cleanup tools reach the same switch, so it can end up turned off without anything having gone wrong: the dashboard engine is still installed and still works, nothing simply starts it any more. The app could not tell that apart from a missing install, so it waited, then offered to install an engine that was already there, and the setup window answered "already installed, nothing to do" — a loop with no way out of it. The startup screen now recognises the case, explains it in one line, and offers a button that switches the startup back on and starts Xenon straight away. It clears the battery conditions above while it is in there, so a laptop that was affected gets both fixed at once. Reinstalling now names the same problem too: running INSTALL.bat has always re-registered the startup task, but silently, so someone whose only problem was a switched-off startup reinstalled, saw it work, and never learned why.
The "Can not find script file … open-dashboard.vbs" box no longer greets you at every sign-in. Keeping the dashboard open in a real browser registers a small logon task that opens the tab for you, and that task points at a script inside the Xenon folder. The two are set up by different halves of the app and could drift apart: an install that moved left the task carrying the old location, and a script an antivirus had quarantined left it pointing at nothing at all. Windows ran the task either way, found no file, and said so in a box you could only click OK on — once per sign-in, forever, while Xenon itself started perfectly well beside it, which is what made it look like nothing to do with Xenon. The task is now checked against what is actually on disk each time the dashboard engine starts: pointed at the right place when the folder has moved, and removed when there is no launcher left for it to run. So the box appears at most once more, at the sign-in after this update, and then stops. Reported on Discord.
"Advanced reasoning" was quietly not using the advanced model. The stronger Gemini model it asked for had been retired and was no longer in Google's list, so every request for it failed and fell back to the fast model. Nothing said so, and the setting looked like it was on. Xenon now picks the model from what your key can actually reach, and when a model does disappear it stops asking for it instead of paying a failed request every turn.
The app knows the Xeneon Edge is still an Edge when you mount it vertically. It recognised the panel by its exact size, in landscape only, so a vertical mount reported the two numbers the other way round and stopped matching. The app then opened as an ordinary window filling most of the screen instead of taking the panel full screen, and the "Xeneon Edge" mark disappeared from the screen picker in Settings, which was the one place you could have told it otherwise. It now matches the panel either way up.
Upcoming events show their name instead of their date. The strip under the calendar gave the date and time all the room they wanted and left the event name whatever was over, which on a row of five events was about thirty pixels: every entry read as a single letter and three dots. The name now gets the space. An event today shows its time, and anything later shows how far off it is, like 2d or 3w. The full date and time are on the tooltip when you hover, and tapping still opens the day.
The calendar is readable on a phone again. On a phone or a tablet the tiles leave the grid and stack, and each one gets a height worked out from how tall you made it on the desktop. The month grid is six week rows whatever that height turns out to be, so on an ordinary 8 row agenda tile each row was given about 7 pixels for a 13 pixel number: every date was drawn across the two below it, and the whole tile read as damage. A week row now has a floor of 26 pixels, which is also a size a thumb can hit, and the agenda tile has a floor of its own so the month, the tabs and the upcoming events all fit without the tile having to scroll inside itself.
The "new in the Store" card no longer paints its own buttons over its list, and a limited edition drop can no longer say "undefined of 50 left". The first: when several creations land at once the list was taller than the card and nothing was allowed to scroll, so "Open the Store" and the opt out below it were squeezed to nothing and drawn on top of the entries. The second: the number of copies still available was worked out by Xenon's own server before the Store saw it, so anywhere reading the catalogue without it — the browser demo on the website — had no number to print, and a drop whose every copy was already claimed was announced as available for the same reason. Both numbers are now worked out wherever they are shown.
The full changelog is in CHANGELOG.md.