Roadmap

45%of the road is shipped

22 of 59 steps done on the road ahead

  1. Behind us15 shipped itemsShow them
    • No-screen mode
    • Make it yours
    • Change a website from its address
    • Message Loki from any AI app
    • Watch it work
    • One account through OrangeCat
    • Roles, hand-over and invites
    • Approvals from Telegram
    • Found a Solon organization from a project
    • Take a site down
    • Crew
    • Fleet command center
    • Fleet Runner desktop app
    • The feedback loop, end to end
    • OrangeCat project handoff
  2. You are here

    Private builders

    One sealed builder per account on the box you already have: its own Linux user, home, token and agent sign-ins, and the rule that whoever asks for a change pays for it with their own engine — a Loki plan, their own key, or their own subscription signed in with the CLI's /login. Nobody's request runs on another person's subscription. Plan: docs/architecture/private-builders.md.

    Next step The runner reads projects through the API and carries no database password

    6/9 steps
    • Design note: tenant model, credential handling, what a request without an engine becomes — done
    • A request on a shared project from someone with no engine goes to the owner as a suggestion; the per-site allowance is retired — doneShipped2026-10-20
    • Agent terminals get an allowlisted environment, never the runner's whole one — doneShipped2026-10-20
    • The runner reads projects through the API and carries no database password — not doneWorked on2026-10-20
    • new-tenant.sh: user, dev root, loki-box-runner@<tenant> unit, token per tenant, reconciled from the account's flag — doneShipped2026-10-20
    • The owner's runner on the same template — not done
    • Eligibility is a flag on the account, not an environment allowlist; a project with no stored builder routes to the connected one — doneShipped2026-10-20
    • Settings → Your engine: a key marked for building reaches your builder; /login in your own Sessions signs in your subscription — done
    • The first tenant who is not the owner builds on their own sign-in — not done
  3. Also being built

    Partner track

    bitbaum owns the systems design course and partner approval. Loki supplies scoped application and assigned-delivery infrastructure; qualification does not enrol a partner in the whole ecosystem. OrangeCat or Solon handoffs remain optional and require their own purpose and consent.

    Next step The candidate build is an ordinary project with an approval control in Control

    1/4 steps
    • Request-scoped application evidence, separate course review and studio approval with visible reasons; bitbaum owns the course and public profile consent — done
    • The candidate build is an ordinary project with an approval control in Control — not done
    • Self-serve "Go live" for a tenant's site through the existing runner channel — not done
    • The not-approved path: the docs and scripts to run the stack yourself — not done

  4. Sealed builds

    After private builders: each build in its own throwaway box (a container, then a microVM when the box exposes KVM), so a tricked agent cannot reach even its own tenant's other work. SandboxExecutor is the seed.

    Next step A container per build with the agent CLIs inside, on the same machine

    0/3 steps
    • A container per build with the agent CLIs inside, on the same machine — not done
    • Per-build CPU, memory and network limits — not done
    • A microVM per build where the hardware allows it — not done

  5. One box becomes a pool

    Runners on several boxes claim from the one queue; each site knows which box serves it.

    Next step new-site.sh --host, and a register that records the host per site

    0/3 steps
    • new-site.sh --host, and a register that records the host per site — not done
    • Runner units on a second box claiming from the shared queue — not done
    • Deploy reconciler that targets the right box — not done

  6. Bring your own key, metered by default

    The builder pays their model vendor directly and pays Loki for the platform; every run records the tokens it spent, per tenant, from day one.

    Next step BYOK as the default execution path for new accounts

    6/8 steps
    • Loki's own chat runs on your key when you paste one in Settings — done
    • Several providers per account, in your own order; the composer's picker shows your models first and links to adding a key — done
    • Passes paid in Bitcoin: the Billing tab shows the pass, its end date, the Buy button and the ledger; the operator grants, extends and revokes from System → Plans — done
    • A key marked "for building" reaches your private builder, not only your chat — done
    • Tokens per run per tenant recorded and shown on the run, and which engine paid for it — done
    • BYOK as the default execution path for new accounts — not done
    • Welcome changes: a few free builds for a newcomer on Loki's key, under a monthly cap in CHF — done
    • A metered pool (wholesale tokens sold inside a plan) once the numbers say so — not done

  7. Signed installers and native channels

    Make Fleet Runner trivial to install on every platform, including for builders who never open a terminal.

    Next step Apple-signed and notarized macOS builds, and a signed Windows executable

    1/3 steps
    • Headless CLI install path for servers and CI runners — done
    • Apple-signed and notarized macOS builds, and a signed Windows executable — not done
    • Homebrew tap, winget, and a .deb apt repository — not done

  8. Remote control channel

    Web and mobile become genuine remote control surfaces, not eventually-consistent dashboards.

    Next step The local app opens an authenticated outbound WebSocket when remote control is on

    1/3 steps
    • When your computer is offline, its work waits in a visible queue instead of going somewhere else — done
    • The local app opens an authenticated outbound WebSocket when remote control is on — not done
    • Scoped credentials through the existing agent token system — not done

  9. Mobile fleet control

    Native iOS and Android apps on the remote control channel, made for steering and approval rather than authoring. No-screen mode (shipped) is the web form of this; a native shell is what it needs if the browser suspends the page when the screen locks.

    Next step Push notifications when an agent needs you

    1/3 steps
    • Push notifications when an agent needs you — not done
    • Swipe to approve or reject agent output where a human is actually needed — not done
    • Voice capture for commands and approvals — done
  10. On the horizon
    • Loki as a GitHub App — Builders work in their own GitHub organization: repositories, secrets and CI minutes are theirs, and Loki acts through an app installation rather than as the studio's account.
    • Own inference for routine work — Reviews, walkthrough scripts, second opinions and briefs on an open-weight model on rented GPUs, once monthly API spend passes roughly thirty thousand dollars and most of it is routine.
    • The academy — The studio-owned transferable course is developed in bitbaum. Loki provides optional building tools and the application evidence API; course content and teaching priorities remain in the studio roadmap.
    • Builders on other people's sites — A builder found on Bitbaum is an OrangeCat account with a seat on one project and their own engine; the client pays them through the builder's own OrangeCat service. Bitbaum is the directory and the door.
    • The fleet learns from its own runs — The evidence that decides whether a run was done also decides how the next one is briefed, with a human gate on every learned change.
    • Team and multi-machine surfaces — Same control plane, several operators, several machines: shared fleet views, per-operator permissions, per-project autonomy ceilings.
    • Stakeholder graph — Each project's competitors, collaborators, investors and customers as typed edges in OrangeCat's entity graph, surfaced on Loki for the agent to act on. Essay: https://loki.orangecat.ch/thoughts/where-stakeholders-live
    • Funding-triggered work orders — Verified OrangeCat settlements connected to owner-approved project work, with explicit controls and an audit trail.
    • Physical robotic fleets — The same control patterns — an on/off autopilot, approvals, handoff, queues, visibility, override — on a different execution substrate.

What stays constant

  1. The execution location is visible and chosen.

    Projects run on their configured builder. Eligible accounts can use the cloud builder; Fleet Runner runs work on your computer when you choose it.

  2. Open-weight models, not one vendor.

    Open-weight models — gpt-oss and qwen — answer Loki's own chat first, and you can bring any lab's key. A model on your own machine works too: expose Ollama or LM Studio on an https address and point Loki at it.

  3. Autonomy is a user-controlled switch.

    Pause all, or build all — with per-project overrides. Per project. Per moment. Never forced.

  4. Outbound connections only.

    The local client connects out to the control plane, not the other way around. Easier to firewall. Easier to reason about. Credible to security-conscious operators.

  5. Nothing hidden.

    Every agent's state is legible. No black boxes inside your own fleet.

Nothing here is dated; the order carries the argument, and every change to it is a reviewed commit. This page renders ROADMAP.md from the repository, through the same fleet record every site uses, read October 29, 2026.

Changelog →Thoughts →

Start a project.

Free while Loki is in beta. Open source under the MIT licence.

Start a project

Or have it built — with a partner, or by the studio →