dnhkng/GLaDOS: A Personality Core for a Real-Life Portal AI

What dnhkng/GLaDOS actually solves, and for whom

Most voice assistants are request-response machines. They wait for a wake word, transcribe, answer, and go quiet. The README states the opposite intent for this project: "GLaDOS doesn't wait, she observes, thinks, and speaks when she has something to say." The problem it addresses is not speech recognition or text generation, both of which are solved elsewhere. It addresses the orchestration layer between them, where a personality has to stay consistent across sessions, react to a camera feed and a clock, and still let the human interrupt.

The audience is narrow and specific. You need a Linux-capable machine with a microphone, a speaker, and either a CUDA GPU or enough CPU to run the ONNX runtime path. The pyproject.toml offers onnxruntime-gpu and onnxruntime as mutually exclusive extras, which tells you the author expects you to pick a side. The README also points at a separate branch for an 8GB Rock5b with an RK3588 NPU, so single-board computers are in scope, but through different code.

This is a maker project with a fictional character as its specification. If you want a general assistant, the personality layer is overhead. If you want a machine that comments on your posture while you work, the personality layer is the product.

The Society of Mind loop behind the personality

The architecture section credits Minsky's Society of Mind. Instead of one large prompt, several subagents write into a shared context object, and the main agent reads from it. The README names sensors, weather, emotion, news and memory as the minds that write, and the main agent owns the LLM and TTS stages. GLaDOS's self is assembled fresh for each interaction from whatever those writers left in the context.

The loop is tick-driven. On each tick the main agent reads her slots (weather, news, vision, mood), decides whether she has something to say, and speaks if she does. Two lanes feed the LLM: user speech and text input jump the queue, while the autonomy lane is the background loop. The README is explicit that the user always wins.

The audio path is documented in more detail than the rest. A 16kHz mono microphone feeds Silero VAD in 32ms chunks, triggering above a probability of 0.8. An 800ms pre-activation buffer keeps audio from before the trigger, silence detection waits for a 640ms pause, and Parakeet handles ASR. Interruption stops playback and clips the response in conversation history, which is the detail that separates a demo from something you can hold a conversation with.

Personality is split in two. HEXACO traits are the stable layer across sessions; a PAD (Pleasure-Arousal-Dominance) model supplies reactive mood. The README also mentions an Observer Agent described as Constitutional AI that monitors behavior and self-adjusts within bounds, but the roadmap still lists "Observer agent (behavior adjustment)" as unchecked, so treat that as planned rather than finished.

Installing dnhkng/GLaDOS and getting a first response

The project declares Python 3.12 or newer and ships a glados console script. The Dockerfile shows the intended flow: install uv, sync with the api and cpu extras, then run a download step to fetch models. That download step is the part people miss, because the models/ directory is copied into the image before the sync.

RUN uv sync --extra api --extra cpu --no-dev \
  && uv run glados download

If you prefer a local install rather than the container, the same two steps apply from a checkout. The optional extras matter: cuda and cpu select the ONNX runtime, tiktoken is separate, and export pulls in nemo_toolkit for ASR work.

uv sync --extra cpu
uv run glados download
uv run glados

After the download completes, the models directory should be populated and the glados entry point should start the assistant. The README does not document a first-run configuration wizard, so expect to edit files under configs/ before the microphone and camera settings match your machine.

The Docker path exposes a service instead of a local loop. The compose file maps a single port, defaulting to 5050.

services:
  app:
    build: .
    ports:
      - '${PORT:-5050}:5050'

The container command runs Litestar against glados.api.app:create_app on 0.0.0.0:5050, so this route is for driving GLaDOS over HTTP rather than sitting at the machine. There is also examples/audio_websocket_client.py in the repository, which suggests a websocket audio path exists alongside the HTTP API. The README does not spell out the websocket protocol, so read that example file before writing your own client.

Where the design assumptions bite

The latency target is the clearest constraint in the README: getting round-trip response time under 600 milliseconds. The author describes this as a threshold below which conversation stops feeling stilted. That number is a design goal, not a measured result, and the README does not report hardware-specific timings. If your GPU is slower than the one the author used, the threshold is the first thing to go, and the project offers no documented fallback for a degraded pipeline.

Proactive behavior is the second constraint, and it is a social one rather than a technical one. A system that speaks when it has an opinion is harder to live with than a wake-word assistant, and the README does not describe a mute policy, a quiet-hours configuration, or a maximum interruption rate. The Observer Agent that would police this is still on the roadmap.

The roadmap itself is candid about what is missing. Streaming ASR using nvidia/multitalker-parakeet-streaming-0.6b-v1 is unchecked, so the current recognition path is chunked rather than streamed. The 3D-printable enclosure and animatronics are also unchecked, which means the physical GLaDOS in the demo video is not something you can build from this repository alone.

Finally, this is the wrong tool if you need a stable integration surface. The project has one release, 0.1 from 2024-12-29, and the README describes multiple refactors as better models appeared. The last push was on 2026-09-17, so the code is moving, but the version number tells you the API is not frozen.

How it differs from a Home Assistant voice pipeline

The obvious comparison is a Home Assistant voice setup with Whisper and Piper. The difference is in the control flow. A Home Assistant pipeline is intent-driven: you say something, an intent is matched, an action fires, and the assistant stops. GLaDOS inverts that. The autonomy lane runs whether or not you spoke, subagents keep writing into context, and the main agent decides on its own tick whether to produce output.

That inversion changes what the tool is good at. Home Assistant is reliable because its scope is bounded and its intents are testable. GLaDOS is interesting because its scope is deliberately unbounded: the README lists researching neurotoxin recipes online as an example of what the minds get up to. You cannot write a regression test for that.

The tool-use story is also different. GLaDOS uses MCP, and the pyproject.toml pins mcp>=1.25.0,<2.0.0. The README points at docs/mcp.md for the tool system, and names home automation and system info as examples. So the two projects can overlap on controlling lights, but GLaDOS reaches that through a general tool protocol rather than a fixed integration list.

If your goal is a dependable voice front end for a smart home, the Home Assistant route has more documentation and a narrower failure surface. If your goal is a character that inhabits a room, the loop here is the reason to pick it.

Licence, upgrades and what maintenance costs you

The repository is MIT licensed, with the licence text in LICENSE.txt. That is permissive and unsurprising for a project of this kind. The practical implication is not legal but operational: the model weights the download step fetches are separate artifacts, and the README does not state their licences. Check those before you ship anything built on top of this, and do not treat the MIT file as covering them.

Upgrade cost is driven by the model churn the README describes. The author writes that the system has been refactored multiple times as better models came out, and the roadmap says models will keep being swapped. Each swap can change the audio path, the vision path, or both. The dependency list is broad, spanning sounddevice, opencv-python, textual, numba, pydantic and mcp, so a Python upgrade or an ONNX runtime bump can move several of those at once.

The project pins requires-python to >=3.12 and targets py312 in the Ruff configuration. That is a recent floor, which reduces the chance of running on an older distribution but also means you are tracking a moving interpreter target. There is no documented migration guide, and the README does not describe rollback. If you deploy this, keep the previous working set of model files alongside the new one, because the download step is the only documented way to obtain them.

Editorial conclusion

Adopt dnhkng/GLaDOS if you want a proactive, camera-aware voice assistant and you are willing to supply the microphone, speaker and GPU it assumes. Do not adopt it if you need a documented, stable API surface or a wake-word-only assistant, because the README describes autonomy as the point and the roadmap still lists streaming ASR as unfinished. Before you build anything on it, check the pyproject.toml dependencies and the models/ directory to confirm which model weights your machine can actually run.

Frequently asked questions

Official sources

1. dnhkng/GLaDOS on GitHub
2. Issues
3. License: MIT
4. README
5. Releases