OmniSpace: a local-first AI workstation that keeps the model on your own GPU

What it is, and the five modules

OmniSpace is a local-first, full-stack AI creation workstation, version 2.5.0 at the time of the README, and the tagline is a five-part product line: AI chat, AI comics, comic-drama creation, a writing desk and knowledge learning.

The stated principle is that by default all inference runs on your own GPU, and if you need a stronger model you can bring your own key and optionally connect a cloud API, which is clearly labelled in the interface and can be switched off.

That default is the whole argument for the project. A browser-based AI creative suite that calls someone else's model sends your prompts, your reference images and your storyboards to a third party. One that runs vLLM, llama.cpp or Transformers on your own card does not, and the README frames local-first as the default rather than a privacy bolt-on.

The primary language is Python, the default branch is main, and the last push was on 2026-09-20 with the project not archived. The repository publishes no GitHub releases, and the version is carried in the README and the code rather than in tags. The licence field on the repository listing is not a standard identifier and the badge in the README says Proprietary, so the licensing position is the first thing to sort out before use.

There is also a notable limitation stated in the repository description itself, and it is worth reading before you plan anything around the code. The latest progress, apart from the plugin system, is restricted from being committed to the repository. So the repository is not a complete picture of the application, and a reader should expect the tree to be behind the running product.

The stack badges give the versions: Python 3.12.10, React 19.0, FastAPI 0.141.1, PyTorch 2.13 with CUDA 13.0, vLLM 0.27.1, and the licence badge marked Proprietary in red.

The VRAM scheduler, and why it is the load-bearing piece

The feature table lists eight highlights, and the second one is the one that makes the rest possible.

The first is genuine multimodality, with text, image, video, voice and a knowledge graph in one creation pipeline. The second is local-first, with the note that the cloud API is an optional tier you supply a key for, configured through an in-page badge.

The third is the VRAM scheduler, described as an in-house video memory coordinator with a ledger, an admission controller and a single orchestrator, which lets a 16 GB consumer graphics card run every creation path, with automatic loading, unloading, mutual exclusion and yielding, and it is explicitly marked as under continuous tuning.

That last detail is the whole problem in one clause. A local AI workstation runs a language model, a diffusion model, a video model and a training job, and on a 16 GB card you cannot hold them all at once. The scheduler's job is to decide which model occupies the card and when, and to move things out of the way when a different path needs the memory. The four mechanisms named correspond to that: load a model on demand, unload it when it is finished, hold a mutex so two heavy models do not fight, and yield the card when something more important arrives.

The ledger and admission controller are what make it a coordinator rather than a script. The admission controller is the gate that decides whether a request fits in the remaining memory, and the ledger is the record of what is loaded and what it cost. A single orchestrator on top of those two means the rest of the application never has to think about VRAM, it asks for a model and gets one, or is told it cannot have it.

This is also the piece that explains the other design choices in the project. If the scheduler can be made to fail gracefully, then a heavy request can be queued rather than rejected, which is why the chat module has queueing with an automatic downgrade notice rather than a flat refusal. The same reasoning explains the per-module health ledgers, since a scheduler that swaps models under load can produce states a single module has to recover from.

Isolation, self-healing, and the two health checks

The fourth highlight is bulkhead isolation with a self-healing ladder, and it is the most operationally interesting feature in the list.

Each heavy module, meaning chat, painting, video and training, keeps an independent health ledger. Consecutive anomalies push a module into a recovery ladder, which restarts the engine, then verifies, then falls back to a recovery guide and safe mode. And there is a one-click check, with eight read-only items, and a deep check with twenty-seven environment-level probes. The promise is that errors always come with a way out.

The design is worth reading closely because it is a specific answer to a specific failure mode. When a single process hosts a language model, a diffusion model and a video model, a crash in one takes the others with it, and the user sees a stack trace rather than a reason. Bulkheading each module means a failure in the video path does not corrupt the chat session, and the ledger means the system knows which module is unhealthy rather than inferring it from a log.

The ladder ordering is the interesting part. Restart the engine first, because most failures are a wedged process rather than a broken one. Verify next, because a restart that does not fix it should not be repeated. And only then fall back to a recovery guide and a safe mode, which is the human-facing last resort. The ladder is bounded, which is what stops a self-healing system from looping forever.

The two tiers of health check fit the same logic. The quick check is read-only, so it is safe to run on demand and cheap enough to offer as a button. The deep check is twenty-seven environment probes, which is a diagnostic rather than a repair, and the number suggests it covers the things that actually differ between two otherwise identical machines: driver versions, whether an external model endpoint is reachable, and the sort of environment detail that explains most installation problems.

The fifth highlight is the plugin system, and the sixth is the data lifecycle work: graded deletion confirmation with three elements, a storage cleanup centre, encrypted backups with daily automatic backups and power-loss recovery, an operation audit log, and a consolidated inventory of junk artefacts. The seventh is engineering quality, and the numbers in it are specific: 376 HTTP endpoints with a real-time reconciliation gate, four WebSocket status channels, 1132 pytest cases with GPU integration behind an explicit switch, 101 vitest cases, and a documentation reconciliation gate.

The reconciliation gate is the detail that shows how the project keeps itself honest. A gate that checks the documentation against the code will fail the build when an endpoint exists but is not documented, which is a mechanical way to stop a large API surface from drifting.

The plugin system and its trust model

The plugin system is called CuteMamen, and it is the part of the project with the most unusual design, and also the part the repository description says is exempt from the restriction on committing recent progress.

The package format is a self-contained tar.gz holding a manifest, weights and three levels of memory, and it supports both pure-data packages and packages that include source code. The security model is graded, and the grading is by where the code runs. Factory components run in-process and are audited. User pure-data packages run in-process. And user packages that include source code run in a subprocess sandbox, with a hard kill on timeout, a memory cap, and a crash that does not take the backend down with it.

That third tier is the interesting one. Running untrusted code inside the same process as the server that holds your conversations and your API keys is the failure mode every plugin system has, and the answer here is a subprocess with two resource limits and isolation from the parent. A crash in a plugin takes down the plugin, not the application.

The import chain is described in four steps: an AST static safety check, a plain-language confirmation gate, a test load, and a cleanup of the failed state. So the sequence is inspect, then ask the user, then try, then clean up if it did not work. The confirmation gate being in plain language is a small thing, and it is the right one, because a security check the user cannot understand is a security check the user will click through.

The trust badge system makes the grading visible at the point of use, with three levels: a blue shield for factory components, a green one for pure data, and an orange one for packages that include source code. So the user can see the risk classification of what they are about to run without reading a document.

The product wiring is a set of skill sockets across the three ends that use plugins, chat, novel and comic, with the note that the factory skill surface is empty, on the principle of better to have none than to have bad ones. There is also a Rust compile error classifier as a demo component, which is an oddly specific piece of tooling and a hint about the intended developer audience.

The stack, and the requirements file as a design document

The backend requirements file is unusually well annotated, and the comments in it describe decisions and their reasons rather than just listing packages.

The web framework group is fastapi at 0.115 or newer, uvicorn with the standard extra, pydantic and pydantic-settings, python-multipart, aiofiles, aiohttp, httpx, sse-starlette, websockets and pyyaml:

fastapi>=0.115
uvicorn[standard]>=0.32
pydantic>=2.10
pydantic-settings>=2.2
python-multipart>=0.0.9
aiofiles>=23.2
aiohttp>=3.9
httpx>=0.27
sse-starlette>=2.1
websockets>=12.0
pyyaml>=6.0

The AI inference group is where the local-first claim is cashed out:

torch>=2.8
transformers>=4.46
diffusers>=0.31
accelerate>=0.29
safetensors>=0.4
einops>=0.7
omegaconf>=2.3
timm>=0.9
sentencepiece>=0.2
Pillow>=10.0
opencv-python>=4.9
imageio>=2.34
imageio-ffmpeg>=0.4

So torch, transformers, diffusers, accelerate, safetensors, einops, omegaconf, timm, sentencepiece, Pillow, opencv-python and imageio with its ffmpeg extra. The presence of diffusers and timm alongside transformers is what makes image and video generation possible, and imageio-ffmpeg is what handles video frames.

The data and vector group is chromadb, sentence-transformers and modelscope:

chromadb>=0.5
sentence-transformers>=2.7
modelscope>=1.16

And the system monitoring group is pynvml, psutil, pystray, pywin32 and cryptography:

pynvml>=12.0
psutil>=6.1
pystray>=0.19
pywin32>=306
cryptography>=41.0

pynvml is the NVIDIA management library, which is how the hardware health centre reads VRAM. psutil covers memory, temperature and disk. pystray is the system tray, which is where the wallpaper-style background process and the notifications live. pywin32 is Windows-specific. And cryptography is what the AES-256-GCM field-level encryption and the key vault use.

Three details in the comments are worth reporting because they are exactly the kind of thing that only shows up in a project that has been running for a while.

The first is the numpy constraint. The comment says the upper bound was opened on a 2026-09-01 decision, because the lock file pins 2.2.6 and the installed tree actually runs on 2.x, so the original constraint of under 2.0 conflicted with reality.

The second is the relationship between the two requirement files. The comment states that requirements-lock.txt is the single authority, with exact pins and the actual runtime environment exported, while requirements.txt is a development-intent reference with loose lower bounds that is not guaranteed to match the actual environment. The instruction for rebuilding the environment is to install from the lock file, and explicitly not from this file. That is a careful distinction and an unusual one to see written down.

The third is the TTS section, where the comment says the AI text-to-speech weights have been isolated pending a decision on the speech direction, so synthesis currently goes through comtypes talking directly to SAPI5 on Windows, with librosa and the rest kept until the route is settled.

The training group is just peft and datasets, which is the LoRA fine-tuning path, and the visual group is ultralytics and segment-anything, which is object detection and the background removal used by the asset library.

How to evaluate it, and what to check first

There are five things to consider, and the first is licensing, because it is the one that is not clear from the documentation.

The licence field on the repository listing records a custom one GitHub cannot classify, and the badge in the README says Proprietary in red. For a project that asks you to run a large stack on your own machine and to hand it third-party plugin code, that matters. Read the licence files before you install it.

Second, the fact that the repository is behind the running application. The description says the latest progress, apart from the plugin system, cannot be committed for protocol reasons, so the code you can read is not the whole product. That has two consequences. You cannot use the repository to judge the current state of the code, and if you are evaluating whether the project is actively developed, the commit dates will mislead you in one direction or the other.

Third, the hardware. A 16 GB consumer graphics card is the stated target for the VRAM scheduler, and that is a floor rather than a comfortable margin. The whole system is designed around the assumption that you cannot hold everything at once, and the scheduler is the thing that makes that workable. If you have less than 16 GB, expect the automatic downgrade path to be the normal case rather than the exception. If you have a lot more, you are buying headroom for the video and training paths.

Fourth, the plugin system in particular. The subprocess sandbox with a hard timeout and a memory cap, and the AST check before import, are the right ideas, and the trust badge makes the risk level visible at the point of use. But a third-party plugin running source code on your machine, with your conversations and your API keys in the parent process, deserves the same caution you would give any code from that source.

Fifth, the data handling. The README claims field-level AES-256-GCM encryption for conversation text and behaviour logs, DPAPI key protection on Windows, encrypted backups, and a key vault that stores cloud keys encrypted and redacts them from logs and diagnostic bundles. Those are good defaults for an application holding your drafts and your generated images, and they are worth confirming in the code rather than taking on trust.

What you get is an unusually complete attempt at a local AI creative suite, with the resource scheduling treated as a first-class problem rather than an afterthought, and with the operational failures designed for rather than ignored. The caveats are the licence, the gap between the repository and the running product, and the fact that a 16 GB card is the design point rather than the comfortable case.

Editorial conclusion

Adopt OmniSpace if you want a self-hosted creative suite for text, image, video and voice where your prompts and reference images stay on your own machine, and if your hardware is around a 16 GB card, since the VRAM scheduler is designed around exactly that constraint. Do not expect the repository to tell you the current state of the product, because the description says the latest progress apart from the plugin system cannot be committed, and read the licence files first, since the badge says Proprietary and the repository metadata does not name a standard licence. Before you commit, look at the two requirement files carefully, because the lock file is the authority and the loose one is only a development reference, and treat the plugin system with the caution it deserves, since a package that includes source code runs on your machine even though it is sandboxed in a subprocess.

Frequently asked questions

Official sources

1. Issues
2. README
3. Yzw202011/OmniSpace on GitHub