Kaidera OS
How Kaidera OS works
A deeper look at the local console, Cortex API, app database, worker harnesses, run-state streaming, packaging, and extension boundary.
Based on the Kaidera OS design overview, architecture docs, Cortex integration docs, harness docs, and distribution roadmap.
Local runtime architecture
Your team, memory and controls stay together
Kaidera OS runs the harness on your machine, connects the project workspace to Cortex memory, routes work to approved model providers and keeps every worker inside one governed operating boundary.
Your project
Kaidera OSHarnessdispatch · policy · run stateApproved connections
Local topology
Kaidera OS runs as a local control plane. The operator uses the console, the console talks to Cortex and the app database, and workers run through configured harnesses against the selected project workspace.
Core services
The console is a web application served locally. Cortex is the memory backend. The app database stores settings and operational state. Harnesses execute model-backed or deterministic work on behalf of configured workers.
- Console: local operator UI for Dashboard, workers, Dispatch, Runs, Settings, and Help.
- Cortex API: memory, project context, registry, handoffs, and evidence.
- App database: settings, local overrides, autonomy flags, and run state.
- Harness layer: local or remote execution path for model-backed workers and deterministic jobs.
Ports and local services
The standard local console address is http://localhost:8765. Cortex and the app database run as local services, commonly on separate ports. Operators should use Settings and health checks instead of guessing which layer is failing.
Run-state streaming
When a worker runs, the console streams state so operators can see progress, logs, decisions, and failure points. This is the live operational surface behind Dispatch and Runs.
Extension boundary
Project-specific behavior should load through project data, project packs, or explicit extension modules. The core product should stay clean, reusable, and project-agnostic so updates do not require customer-specific forks.
Desktop and headless shapes
The same control-plane idea can run as a local browser console, a native-wrapped desktop app, or a headless service on a controlled VM. The security and networking posture should match the deployment shape.
Update design
The update path is designed to replace the application package while preserving Cortex data, app database state, and project files. This keeps routine updates separate from customer workspaces and long-lived memory.
Website context
Connect this guide back to the product story
The technology docs map links this page to the public technology narrative and helps buyers move from a capability overview into the right operating guide.
Open technology docs map →