oqto is still in early but very active development. Expect bugs and unfinished features. I am very much dog-fooding oqto myself and want it to work as well as possible. LLMs are still very susceptible to prompt injection. Be aware that giving an LLM-based agent unrestricted access to your personal information in combination with broad system permissions and unfiltered access to online sources (repos, web search, skills etc.) can lead to data-exfiltration, data-manipulation, installation of malware and other attacks. oqto tries to alleviate this by making isolating agents possible through fine-grained permission/sandboxing profiles. For example, an agent that can read and organize your emails does not really need access to many other tools and online sources. A single powerful agent can be very convenient but I believe that isolating multiple tasks-specific agents is the better approach for now. This has the positive side-effect of making context management easier as well. That being said, you can very much still decide to give your agents in oqto free permissions to do everything. It's your choice. I don't lock you into a walled garden, I aim to provide you with powerful tools and the freedom to do anything you want with them.
Oqto is a self-hosted, multi-user platform for working with AI agents aimed at technical and non-technical people. Each Agent workspace can be configured individually with regards to sandboxing, skills, extensions etc. It is built around pi with rpc mode as the core agentic harness, which makes it very flexible and extensible. oqto comprises a web UI for chat, file browsing, terminal access, canvas, memory and task tracking. It also includes a browser running on the server that the Agent can control which can be streamed to the frontend, enabling users to take control when necessary. Many of the tools used by oqto are built as stand-alone tools which can also be useful outside of oqto.
Current development focuses on running oqto on a Linux server but it's technically possible to run all components on macOS as well. Right now, I would recommend running it on a Linux VM on macOS as well to avoid macOS-specific bugs.
The oqto backend is responsible for user authentication and management. The backend never spawns agents directly but starts them through oqto-runner, which wraps pi processes in a sandbox using bubblewrap. oqto leverages the file-system for many configuration and isolation tasks. Each user gets an oqto workspace which is just a directory in their home dir. Each dir inside this workspaces can be thought of as a project or Agent with individual configuration options. This includes a sandbox profile, pi extensions and skills. This way, you can dial in the permissions per project. For even further isolation, oqto will support containerization but mind that this is still experimental.
The frontend uses a canonical agent protocol over a multiplexed WebSocket (/api/ws/mux). It is agent-runtime agnostic in principle -- the backend translates between the canonical protocol and agent-specific protocols like pi rpc mode.
pi: A lightweight AI coding assistant CLI used as the central agent harness. Runs in RPC mode with JSON over stdin/stdout. Supports multiple providers (anthropic, openai, google), extensions, skills, and session compaction.
| Binary | Purpose |
|---|---|
oqto |
Main backend server |
oqtoctl |
CLI for server management |
oqto-runner |
Multi-user process daemon (Linux only) |
oqto-sandbox |
Sandbox wrapper using bwrap/sandbox-exec |
oqto-browser |
brower for agents inspired by agent-broswer |
pi-bridge |
HTTP/WebSocket bridge for Pi in containers |
oqto-files |
File access server for workspaces |
| Mode | Description | Use Case |
|---|---|---|
local |
Via oqto-runner daemon |
Single-user and multi-user Linux |
container |
Inside Docker/Podman | Full container isolation |
Even in local mode, agents are spawned through oqto-runner, never directly by the backend. Container mode is still experimental, the current focus lies on making local multi-user mode as good as possible.
oqto integrates the following stand-alone tools that are being actively developmed alongside oqto. Source code available here.
| Service | Purpose |
|---|---|
hstry |
Chat history storage (per-user SQLite) |
mmry |
Memory system (semantic search, embeddings) |
trx |
Issue/task tracking |
skdlr |
CLI for scheduling tasks |
eavs |
LLM API proxy |
ears |
Realtime Speech-to-text server using the kyutai STT model and optonally nvidia parakeet |
kokorox |
Realtime Text-to-speech server using the kokoro onnx model |
sx |
Search CLI for searxng and optionally online search services |
scrpr |
Website fetcher with optional markdown conversion |
agntz |
Wrapper aournd the other tools so agents use one unified interface |
In multi-user mode each platform user maps to a Linux user (oqto_{username}). Per-user oqto-runner daemons manage agent processes and per-user mmry instances provide memory via HTTP API.
Auth uses JWT with invite codes. A progressive onboarding system with agent-driven UI unlock guides new users (planned).
This setup script has primarily been tested on an Ubuntu 24.04 VPS but targets multiple distros. Right now, many tools are still being built from source. I will provide pre-built binaries soon to substantially speed up the installation. The script also includes optional server hardening steps (firewall, fail2ban, ssh lockdown etc.)
./setup.shThe interactive script handles user mode selection, backend mode, dependency installation, building, configuration, and optional systemd services. See SETUP.md for full details.
I don't recommend manual setup due to many different moving pieces but it's of course technically possible to set everything up manually.
-
Install Rust and Bun
-
Build the backend:
cargo install --path backend/crates/oqto
-
Build the frontend:
cd frontend && bun install && bun run build
-
Install agent tools (pi, agntz, byt)
-
Configure
~/.config/oqto/config.toml -
Start services:
oqto serve cd frontend && bun dev
Open http://localhost:3000. Check backend logs for dev credentials.
IMPORTANT: I am focussing on local mode for now but will support container mode in the future as well.
docker build -t oqto-dev:latest -f container/Dockerfile .Configure the backend to use containers in ~/.config/oqto/config.toml:
[container]
runtime = "docker"
default_image = "oqto-dev:latest"backend/ Rust backend (API, sessions, auth, runner)
crates/
oqto/ Main server crate
oqto-protocol/ Canonical agent protocol types
oqto-files/ File server
oqto-browser/ Browser automation
oqto-scaffold/ Project scaffolding
frontend/ React/TypeScript UI (chat, files, terminal, canvas, memory)
deploy/ Systemd service configs, deployment scripts
docs/ Architecture docs, design specs
scripts/ Build and utility scripts
tools/ CLI tools and utilities
See backend/crates/oqto/examples/config.toml for the full reference.
[server]
port = 8080
[local]
enabled = true
single_user = false # true for single-user, false for multi-user
[local.linux_users]
enabled = true # multi-user Linux isolation
[runner]
# Pi session storage directory
pi_sessions_dir = "~/.local/share/pi/sessions"
[mmry]
enabled = true
local_service_url = "http://localhost:8081"
[hstry]
enabled = true
[auth]
dev_mode = trueVITE_CONTROL_PLANE_URL=http://localhost:8080Run ./setup.sh to generate configuration files automatically.
The primary interface is WebSocket-based via /api/ws/mux (multiplexed WebSocket). The frontend communicates over two channels:
agent-- Canonical agent protocol (commands + events)system-- System notifications
| Component | Build | Lint | Test |
|---|---|---|---|
| backend | cargo build |
cargo clippy && cargo fmt --check |
cargo test |
| frontend | bun run build |
bun run lint |
bun run test |
# Server
oqto serve # Start API server
oqto config show # Show configuration
# Control
oqtoctl status # Check server health
oqtoctl session list # List sessionsThe repo already includes a tauri-based mobile app that already works. I have only been able to test this on iOS so far but would be happy if someone could try running it on Android. My plan is to soon offer a test version via Testflight on iOS.
I have many ideas I want to try out but even with the help of AI coding agents, time is finite. Here are the things I want to prioritize:
- Properly fix all warnings especially on the rust side and remove any use of unsafe code and replace it with safe alternatives.
- UX/UI improvements especially with regards to workspace and sandbox configuration. This is currently not intuitive and requires too much internal knowledge.
- Ready-to-use iso image for easier setup. I haven't decided on the best distribution to base this one but am very much favoring arch linux. NixOS would maybe be even better suited but I haven't tried it out yet so my experience is the limiting factor here.
- Improved STT and TTS support: There are so many good new models out there that I want to try out and see if they could be integrated into my existing tools. The goal would be a good dialogue mode that can orchestrate agent tasks on the platform
- Support for remote workspaces: Apart from creating workspaces in userspace, I want to add first-class support for remote workspaces for even better isolation. This includes having clients on e.g. your laptop that can be reached via the platform for certain tasks. I am building a cross-platform launcher that shall eventually integrate with oqto for this.
The biggest support you can currently provide is trying out to set up and use oqto yourself and reporting any issues you encounter. I would also appreciate any feedback regarding the general architecture especially concerning the security aspects.
If you want to actively contribute to the codebase, I would appreciate you start a discussion beforehand to share what improvements you would like to make. I have strong options on certain aspects but am very open to suggestions in general.
- SETUP.md -- Installation guide
- AGENTS.md -- Agent development guidelines
- backend/crates/oqto/examples/config.toml -- Full configuration reference
- pi for the core agentic harness used in oqto
- opencode which served as the initial inspiration for the server/client based ai coding-agent approach
- openclaw for the markdown-based approach to user onboarding
- Jeffrey Emanuel aksk Dicklesworthstone for inspiring many of the tools built for oqto
- And many, many more people that create inspiring stuff. You can look at my github stars to find many cool things others have built!
MIT