A few days ago I wrote about building GISMO — a local-first AI orchestration system — on a 7-year-old laptop.
v0.5.0-beta.1 just dropped. Here's what changed, and why it matters.
The short version
Phases 0 through 3 are done. Phase 4 — the interactive experience — has started. This beta is the first release where GISMO's command center starts behaving like an operator shell instead of a UI bolted onto backend plumbing.
What phases 0–3 built
- Phase 0 — SQLite-backed state, queue, daemon, IPC, JSONL audit trail
- Phase 1 — Ollama integration, local LLM planner, ask pipeline
- Phase 2 — Deterministic risk classification (LOW / MEDIUM / HIGH), deny-by-default policy enforcement, approval gating
- Phase 3 — Persistent memory store, context injection, conversation profiles
All of that is the engine. Phase 4 is what you actually drive.
What's new in v0.5.0-beta.1
Desktop command center is live
gismo app now launches a native desktop application with a three-column command center layout and a real top menu bar — File, System, Devices, Automation, Settings, Help. Settings surface includes operator-facing controls: voice selection, model selection, and more.
It finally looks like something I'd want to leave open on a second monitor.
Chat routes to real execution
This is the one I'm most pleased about.
Previously, chat requests would report success before execution actually completed. The UI was lying to you. That's gone.
Operational chat requests now route into the full pipeline:
chat input → planning → approval → queue → worker → tool/action → state update → UI refresh → spoken/text result
GISMO won't tell you something happened until it actually happened. I work around industrial robots. Silent failures and false positives are how things go wrong.
Calendar is operational
There's a Calendar tab in the app now. Calendar actions execute through the actual queue/worker/tool path — not local UI state. GISMO's calendar is part of its operational timeline, not a sticky note widget.
Truthful system surfaces
"This computer" now reflects actual host state. The network panel separates LAN state from internet reachability. The boot flow is tied to real startup state instead of a cosmetic progress bar.
GISMO should never tell you it's ready when it isn't.
What the full stack looks like right now
These pieces are working together:
- SQLite-backed state, queue, runs, tasks, and memory
- Local Ollama-backed GISMO model
- TTS voice output
- Desktop app, web dashboard, and TUI
- Approval-gated planning
- Queue/worker execution
- Calendar and command center surfaces
What's still missing
This is a beta. Known gaps:
- Device connection and capability binding still incomplete
- Protocol adapters for real device control still being written
- Onboarding needs full in-window polish
- Daemon auto-start not wired up yet
- Adaptive model policy (routing based on weak vs. strong hardware) still being refined
What's next
- Device capability binding and protocol adapters
- Tighter operational state model beyond generic READY
- Full in-app onboarding flow
- Daemon auto-start
- Adaptive model policy and deterministic request routing improvements
The longer horizon is still the same: GISMO as a universal device orchestration layer. Drones, RC vehicles, industrial peripherals, humanoid robots — all operating under the same policy-gated, auditable framework that governs file operations today.
Try it
GitHub: https://github.com/GISMO-1/GISMO
Release: v0.5.0-beta.1
License: MIT
If you're building in the local-first AI space or have thoughts on device orchestration and policy models — drop it in the comments.
Top comments (0)