Mark LV replaces hard coded model names with a nine model ladder

One application, three operating systems, one file to run

Mark LV is a real time voice assistant, described as an extension of your digital life rather than a library. It is a Python application with a flat layout: `main.py` at the root alongside `ui.py`, and directories for `actions/`, `config/`, `core/`, `dashboard/`, `memory/` and `plugins/`.

The cross platform claim is real in the packaging rather than aspirational. The `requirements.txt` file says pip skips any line whose `sys_platform` marker does not match your OS, so one file serves Windows, macOS and Linux without pulling the wrong libraries, and `setup.py` installs the dependencies for the current operating system only.

The README describes it as running on Windows, macOS and Linux, built on the Gemini Live API for native audio streaming, and delivering what it calls zero subscriptions. That last phrase deserves care. There is no subscription to the assistant, but the Gemini Live API is a metered API, so the cost moves rather than disappears.

The voice interaction is push to talk on Ctrl+Space, globally on Windows and window scoped elsewhere, with a self echo guard that drops the tail of the assistant's own speech so it does not answer itself. A local wake word exists as an opt in rather than default: the setup script deliberately does not install it, and the README points to a settings entry inside the app for a one click opt in.

The model ladder replaces sixteen scattered hard coded names

This is the release's actual engineering change, and it is described more concretely than the feature list usually is.

Every Gemini call in the app now goes through one ladder of nine models, ordered by measured response time rather than guesswork. When a model hits its quota, times out or disappears, the next rung takes the call, and the failed one is put on a cooldown so nobody pays for it twice.

The before and after numbers are given: previously, sixteen files named their own model, twenty six times, with no timeout at all, so one unwell alias could hang a request forever. Now there is one list, and a timeout exists.

Read that as a reliability property rather than a performance one. An application that streams audio has no good failure mode for a stalled API call, and a fallback ladder with per model cooldowns is the standard answer. The ordering being measured rather than guessed also means the ladder is only as good as the measurement behind it, and the README does not say when or how that measurement is refreshed.

The live engine itself runs on Gemini 3.1 Flash Live, which the README describes as roughly twice as fast to first word as the previous model. The voice list is five native Gemini voices, switchable from the interface without a restart. Conversation length is handled by sliding window context compression so a session can run for hours, and a dropped connection, a voice change or a device change no longer wipes the conversation.

The software avatar is drawn in software, on purpose

The interface has an animated human head rendered in the HUD. Both `requirements.txt` and `setup.py` explain why it costs nothing: PyQt6 and numpy were already dependencies, the head is rendered in software with QPainter and posed with numpy, and there is no GPU, no OpenGL and no extra package. `setup.py` states explicitly that it installs nothing for the avatar.

The lip sync is described as around fifty mouth shapes a second, derived from the audio's formants and from the transcript, distinguishing closures, spreads and rounds rather than moving a volume meter.

The part with a real design decision is language independence. Articulation is derived by Unicode reduction, so Latin, Cyrillic and Greek scripts all work from one rule set, and scripts that hide pronunciation fall back cleanly. That is a pragmatic answer to the fact that a phoneme based approach needs a pronunciation dictionary per language, and it explains why the same rule set covers three scripts without a language switch.

The face also carries state, which is the part that is more than decoration. It looks away while thinking, meets your eyes while listening, its lids fall while asleep, and it glances down when new content arrives. Brows track the phrase being spoken, gaze saccades between fixations, blinking is automatic, and stressed syllables get a small nod.

The HUD itself reacts: a waveform driven by real audio, your microphone while listening and the assistant while speaking, plus theming from a hue wheel or a hex value where the avatar retints with the interface.

It controls the machine, and the safeguards are the interesting part

The README's framing is that everything bundled now drives the computer: applications, files, the browser, the desktop and the screen. Five skills that served one hobby or one trade were removed from the list, which the README describes as a thousand tokens the model no longer reads on every connection and five fewer wrong tools to reach for. That is a sensible reduction, and it also indicates that the skill list is curated rather than complete.

Skills are self describing. Each bundled skill declares its own `TOOL` dict plus a handler and is auto discovered at launch, so adding one is a single file, and the plugin system extends the same idea: drop a single `.py` file into `plugins/` and the assistant learns a new skill on the next launch.

Two safeguards are named specifically and both are worth checking against your own policy.

Undo takes back what the assistant did: files it moved, renamed, created or wrote, and settings it changed.

Real confirmation makes shutdown, restart and WiFi wait for a button you press, with the stated reason that the model cannot confirm its own irreversible actions. That is a narrow but sensible carve out.

The model also gets a runtime self description of its own name, OS, abilities and limits, generated from the live system each session, so renaming it or adding a plugin changes what it says about itself.

Visual awareness means screen capture and webcam vision are piped into the main Gemini session, labelled by source. That is the line to read carefully before installing this on a machine with anything sensitive on screen.

Memory that is searchable, and a panel to delete it

Persistent memory is described as having no size limit and nothing silently forgotten: the prompt carries what fits, and the rest is looked up on demand from a local search. The `memory/` directory at the repository root is where that lives.

A memory panel lets you see every fact the assistant has stored about you, when it learned it, and delete any of it in one click. For an assistant that reads your screen, that panel is not a nicety.

Session memory is separate and self consuming: each conversation is summarised, mentioned naturally the next morning, and then consumed after use so it does not repeat.

Around that sit the scheduled behaviours. Proactive check-ins are described as time aware and context aware, knowing the time of day, your projects and what you have been discussing. Background monitoring watches user configured topics, checks for new headlines once a day and alerts naturally. Reminders are OS native, using Windows Task Scheduler, a macOS LaunchAgent or a Linux systemd unit, which is the right choice over an in app timer because the notification survives the app.

A morning briefing runs on first boot: it greets you, reads the time, recaps yesterday and fetches live news.

Python 3.11 to 3.13, one unbounded dependency, and no releases

`setup.py` sets a hard floor and a tested ceiling: `MIN_PY = (3, 11)` with a comment that below it the syntax used will not parse, and `MAX_PY = (3, 13)` as the highest version actually tested. Newer is a warning rather than a wall, and the reasoning is given: turning away someone who installed today's Python is a worse first impression than a version that turns out to work, and if a wheel really is missing pip says so plainly.

It also fetches the Playwright browsers needed for web automation, current OS builds only, which is the price of the browser control skill.

The version bounds in `requirements.txt` follow a stated policy: the lower bound is what the app is developed against, and the upper bound stops the next MAJOR release of a dependency from breaking every fresh clone on the day it ships, while minor and patch updates flow in freely. The core set is PyQt6>=6.6,<7, sounddevice>=0.4,<1, numpy>=1.24,<3, google-genai>=2.8.0,<3, requests, beautifulsoup4, playwright>=1.40,<2 and yt-dlp.

`yt-dlp` is the exception, and the comment explains why in detail. Qt plays local files and direct media URLs on its own because QtMultimedia ships with PyQt6, but a YouTube page is not a video file, so yt-dlp is what turns one into a stream Qt can play. Without it the HUD still plays files and URLs and YouTube links open in the browser with an explanation instead of failing. Because YouTube changes what it serves without notice, the dependency is deliberately unbounded, with the instruction to keep it current.

The last push was on 2026-09-27. There are no GitHub releases, so there is nothing to pin, and the licence is a custom one that GitHub cannot classify.

Where a system assistant or a scriptable agent fits instead

The comparison with a general purpose assistant built into the OS comes down to what you can audit. A system assistant is a known binary from a vendor who ships it with the operating system. This is a Python application you run with your own API key, which means the code is readable and the model calls are yours, and also means the update path is a git pull rather than a vendor patch.

The comparison with a scriptable agent framework is about shape. A framework gives you tools, a loop and a trace, and you write the prompts and the control flow. Here the prompts, the skills and the tool surface are already written, and the cost of control is that you accept the tool surface that ships.

Against writing your own voice front end, the parts you would write first are all here: audio capture, an echo guard, a wake word, a voice model with low latency, and a reconnect path. The parts that remain yours are the actions and the memory, both of which are extension points rather than fixed code.

The boundary to check before adopting is the screen capture. Visual awareness piped into a remote model session is the feature that turns a local assistant into one that sees your work, and that is a decision about your data rather than about the software.

Editorial conclusion

Adopt Mark LV if you want a desktop assistant that can hear you, see the screen and drive applications on Windows, macOS or Linux, and if you are willing to accept that it acts on your machine. Do not adopt it as a library or a component: it is a single application with `main.py` at its root, no GitHub releases to pin, and a custom licence whose terms you have to read in the LICENSE file yourself. Verify that your Python is at least 3.11; `setup.py` warns rather than refuses newer interpreters and treats 3.13 as the highest version actually tested. Check what the real confirmation gate covers before letting Mark LV handle a shutdown or WiFi command.

Frequently asked questions

Official sources

1. FatihMakes/Mark-LV on GitHub
2. Issues
3. README