Gald3r Throne -- the Desktop App

Gald3r Throne (codename Hlidskjalf) is gald3r's desktop application: a local-first workspace control plane for your gald3r-managed projects, built on Tauri 2 + React. It gives you a visual task/bug board, a place to launch and watch agent runs, an integrated terminal and file editor, and a set of avatar/character surfaces for giving your agents a face -- all reading and writing the same .gald3r/ control-plane directory the gald3r CLI uses.

The core architecture invariant, unchanged since the app's first design: your local files always belong to you. There is no host-side write path that requires Docker, or gald3r's optional backend services, to function -- those services are off by default and explicitly opt-in. Throne is the only host-side editor; any backend it talks to is read-through, never a hidden writer to your project.

This page is written for someone using Throne, not building it -- see concepts.md and coordination.md for the ideas (.gald3r/, world_tree, Valkyrie) Throne surfaces visually.

Install

gald3r install throne

This downloads the right installer for your OS from Gald3r-Labs' public GitHub Releases and verifies its minisign signature before handing it to you -- it refuses an unsigned or tampered download unless you explicitly pass --allow-unsigned. Add --dry-run first if you just want to see what it would fetch, with no network call.

• Windows -- an NSIS -setup.exe or an .msi.
• Linux -- an .AppImage or a .deb.
• macOS -- not yet published. No Throne installer asset exists for macOS today; this is a known, documented gap, not an oversight on your end.

Run the downloaded installer once. After that, launch Throne from your OS's normal application launcher (Start menu on Windows, Applications on macOS once that build exists, your desktop environment's launcher on Linux). There is no dedicated gald3r throne launcher command wired up in this CLI build yet -- gald3r install throne covers the download-and-verify step; opening the installed app is an OS-level action today.

What you'll see on first run

Throne opens to a project picker. Point it at any folder:

• A gald3r-managed project (has .gald3r/.identity) opens straight into the dashboard.
• A Workspace-Control owner (has .gald3r/linking/workspace_manifest.yaml) opens with its member projects listed for navigation.
• Anything else gets an honest "not a gald3r project" message and a prompt to switch folders. Throne does not create .gald3r/ for you automatically -- that is gald3r setup's job.

There is no network call on launch. The status strip shows File-first mode as always on, plus the status of any optional backend connections you have not yet turned on. Anonymous, opt-out, no-content adoption telemetry (an install/first-run/continued-use ping with no file paths, prompts, or account info) is on by default and one click to disable in Settings -> Profile -> Privacy & Diagnostics.

Main areas

Area	What it's for
Tasks, Bugs, Kanban	The same task/bug board gald3r task/gald3r bug drive, rendered visually, with a board view alongside the list
Features, Releases, Plans, Subsystems, Vault	Read/edit surfaces over the matching .gald3r/ records
Terminal	A real host-side terminal (PTY) rooted at your project, with renamable, groupable tabs
IDE	File explorer, a syntax-highlighted code editor, TypeScript/JavaScript diagnostics from a locally detected language server, and a git-aware source control panel (stage, commit, review a diff against HEAD)
Active Coordinators / Collaborate	See other agents and collaborators working the same project, and open a running session to more than one person at once
Credentials	Provider API keys and local endpoints, stored in your OS keychain (Windows Credential Manager / macOS Keychain / Linux Secret Service) -- never written to disk in plain text
AI Routing	Choose local-first, cloud-first, local-only, or manual model routing, and see which local endpoints (Ollama, LM Studio, a custom OpenAI-compatible server) are actually reachable
Avatar Studio, Avatar Player	Generate and preview a talking avatar bound to a personality -- see the current-status note below
Email, Scheduler	Reading/composing mail through your own IMAP/SMTP account, and firing scheduled command sequences
Mission Control	An org/team command-center view of active swarms and claimed territory across your organization

Local model setup

Throne ships adapters for Ollama (default http://localhost:11434) and LM Studio (default http://localhost:1234) out of the box, plus a custom OpenAI-compatible slot for anything else (llama.cpp server, vLLM, a self-hosted gateway). None of them require an API key by default, and Throne never auto-downloads or auto-starts a model for you -- it connects to a service you are already running. Settings -> Providers has a Check Endpoint action for each, so you can confirm a local server is actually reachable before picking a model.

Direct cloud provider calls are a different story: the shipped desktop binary does not embed cloud AI adapters. Cloud model routing goes through your signed-in gald3r account's backend instead, consistent with keeping that routing logic out of a binary that ships to every user's machine. If you are not signed in, cloud routing simply is not available yet in that session -- local providers still work either way.

Current status -- what's gated or still being polished

• Monitors panel is gated behind a feature flag, defaulting off, pending a decision on whether the server-side monitors API it needs actually exists. If you don't see it, or it shows a "not yet available" state instead of your data, that is the current, intended behavior -- not a bug on your end.
• Avatar rendering is a work in progress. The Avatar Player surface is real and works today, but it renders a labeled placeholder SVG rig, not finished character art -- the underlying data model already supports swapping in real per-state artwork later without a contract change. A newer character-viewer/monologue sequencer exists in the source tree but is not yet wired into the running app. Avatar Studio's actual generation work happens server-side and needs a signed-in, entitled account to produce anything.
• Mission Control needs both a team/org-tier entitlement and a live, reachable backend. Without either, it shows an explicit "offline" or upgrade state rather than failing silently or showing stale data.
• No macOS build yet. Windows and Linux installers exist; macOS does not.
• Optional backend connections (Valhalla, Yggdrasil) stay off unless you explicitly opt in from Settings -> Backends. Nothing in the app requires them, and neither one ever gets filesystem access to your projects -- they process only what you pass them over an API call.

If a feature you expected is missing entirely rather than gated, it is more likely simply not built yet than deliberately hidden -- this page only documents what is verifiably there today.