Skip to content
Foxora Runtime · the R in WARP · In development

Your machines. Your rules.

Our planned self-hosted engine brings agent work to infrastructure you control. Explore the design for budgets, approvals and a record of every job. Public access is not available yet.

Design preview · Illustrations show the planned experience, not a live service

Example: the Runtime console at 07:40. A board of jobs in four columns: Running, Waiting on a person, Stopped at budget and Done. One job, triage last night's failed test runs, is open on its six checks: three passed, the fourth waits for a person to approve posting the summary. Its budget shows four axes, all under their limits.

Foxora Runtime · consoleExample · not a live run
  1. Post the summary to #on-call?Priya S. decides
Example board · the states are the engine's, the jobs are not
Status
In development
Designed for
Infrastructure you control
Access
Waitlist
Available today
Foxora Studio
What it does

One engine, on machines you control.

A job starts only when it's allowed, spends only what you set, and stops for a person where you said so.

  • 01

    It checks every job

    Six checks stand between “do this” and “done”. The engine records each one.
  • 02

    It keeps to the budget

    Money, tokens in, tokens out and time. A charge that would pass a limit is refused.
  • 03

    It waits for a person

    Before a step that changes something, the job pauses until a named person decides.
Runtime · 1 of 5 · The six checks

Six checks between “do this” and “done”.

Each check is a state the engine records, not a line in a prompt. A job is done only when all six have passed, and every one lands on its receipt.
  • Saved before work startsWhat done means, what the job may spend and when it's due. It survives a restart.
  • Access that only shrinksA lease covers one resource and one action, for a limited time. It can narrow; it never grows.
  • Proof, not a promiseAn agent saying “done” closes nothing. The job settles on evidence that meets its test.
Example · the same job, eight minutes after the board
Runtime · 2 of 5 · Budgets

A budget on four axes, checked before the charge.

Give a job a limit on money, tokens in, tokens out and time. On every axis with a limit, a charge that would pass it is refused in the same transaction as the charge. The agent cannot raise it.
  • Set all fourOn your own machine, an axis left at zero or unset has no limit. Set every one.
  • Cheaper models for easy stepsYou choose which model handles which kind of step, so simple work doesn't pay top price.
  • What the limit coversWhat the engine meters. Fees a provider bills you directly sit outside it.
Example · amounts carry no currency sign, as in the engine
Runtime · 3 of 5 · Autonomy

Five levels of autonomy. The ceiling stays with a person.

Foxora describes how much an agent does on its own in five levels, borrowed from self-driving cars. Whatever the level, a person sets the ceiling on budget and reach, and the agent cannot raise it.
  • In Studio todayLevels 1 to 3 are live: agents draft, execute and operate, and flag the exceptions to you.
  • In the self-hosted RuntimeNo level setting today. How far an agent goes is set job by job: by its intent, its budget, the leases it holds and the waitpoints where a person decides.
  • The earned-autonomy ladderIn buildAn agent will move up a level on its track record, never past the ceiling a person sets.

Fig. 3 · The autonomy ladder

  1. The ceilingA person sets it: how much the agent may spend and how far it may reach. Reaching it hands the decision back.
    Held by a person
  2. RunsIt owns the outcome and directs other agents.
    In build
  3. OwnsIt owns a whole job type. You read the weekly number.
    In build
  4. OperatesIt works on its own and flags the exceptions.
    Live in Studio
  5. ExecutesIt finishes the job, then stops for your approval.
    Live in Studio
  6. DraftsIt proposes. You do the work.
    Live in Studio
Levels 1–3 live in Studio · levels 4–5 in build · the top rung is always a person
Runtime · 4 of 5 · Named reasons

When it won't go ahead, it says why.

Work the engine holds back always carries one of ten named reasons, each with a plain meaning and a fix. No silent failures, and no log line to hunt for.
  • Ten reasons, the complete listWork that is held back always carries one of them, shown on the board.
  • A fix with every reasonFinish the earlier work, wait for a slot, raise a limit, repair a change.
  • Waiting on you is not a failureA step that needs your approval pauses at a waitpoint instead.
Example · the ten reasons are the engine's own
Runtime · 5 of 5 · Deployment design

One launcher, on a machine you control.

The deployment design uses one launcher command, foxora up. The illustrated flow creates its own keys and certificates, starts the engine and its database with Docker Compose, and gives you the console address once the console answers. This is a design preview; no public installer is available yet.
  • Runs onmacOS or Linux, on x86-64 or Arm. On Windows, inside WSL2.
  • NeedsDocker with the Compose plugin, curl, and keys for the model providers you use.
  • Spends nothing at the startA fresh installation has no model set up, and spends nothing until you connect one.

Where things live

  • On machines you controlThe engine and its database: your intents, memory, evidence and receipts.
  • Sent to the providers you connectThe prompts and files each step needs. Host your own model and those steps stay on your machine.
  • Not the same as StudioStudio runs agent work on your computer. Runtime is designed for infrastructure you control.

macOSLinuxWSL2x86-64Arm

Example · the launcher's lines, shortened
Who it's for

For platform teams. Studio for everyone else.

Runtime is for teams that want agents inside their own infrastructure, with approvals, budgets and records the engine enforces rather than a prompt requests.

It fits if you

  • want agents to run on machines you control
  • need a person to approve risky steps, and a record of who approved what
  • need limits on money, tokens and time that an agent cannot raise
  • are comfortable with Docker, a terminal and API keys

Not hosting anything?

Use Studio today.

Studio has plans, approvals and credit ceilings built in, live now. There is nothing to host: it runs your jobs on your computer, in the desktop app.

Free plan · 200 credits a month · No card required

Foxora Studio V6.0 · an example session, not a live run · it asks before anything is sent
Status · Design preview

Not a framework. The whole engine.

Teams usually put together a model loop, prompts and a place for keys, then write their own approvals, budgets and audit. Runtime is one install that holds the whole job, from the intent saved before work starts to the receipt signed when it ends.

Design preview

The planned engine

  • EngineRuns every job through the six checks
  • ConsoleThe board, jobs, budgets and receipts
  • GovernanceOwners, budgets, approvals, evidence, receipts, named reasons
  • DurabilityA job's intent survives a restart
  • AgentsThe agents that carry out the steps
  • Tool grantsOne permission at a time
  • TriggersWebhooks and schedules
  • MCP toolsAgents call tools on MCP servers
In build

Not finished yet

  • SDK and public APIThe packages and the machine API, not published yet
  • ChannelsWork arriving by phone call, WhatsApp, Telegram and email
  • Earned-autonomy ladderAgents move up a level on their record, never past the ceiling
  • Analytics and pluginsNot finished yet

No adopters to quote yet.

The self-hosted Runtime has no outside users yet, so there are no logos or quotes on this page. What you can read today: GRIP 1.0-draft.2, our written rules for agent work, published for review; and Foxora Studio, available on your desktop.

Want these rules on your own jobs?

Join the waitlist and we'll tell you when access opens. We only use your email for that.

Questions

What platform teams ask us.

It's in development; public access is not available yet. Join the waitlist and we'll tell you when access opens.

If you want agents that answer to you today, Foxora Studio is live, with a free plan of 200 credits a month.

Studio is the desktop workspace: you brief agents, answer their questions and review the work. Jobs run on your computer while Studio is open.

Runtime is the planned engine for your own infrastructure, on machines you control, with the six checks, the budgets and the waitpoints on this page.

The proposed host targets are macOS or Linux on a 64-bit machine, x86-64 or Arm. On Windows, install it inside WSL2 (Windows Subsystem for Linux).

You also need Docker with the Compose plugin, running, plus curl and keys for the model providers your agents will use.

The ones you connect. You choose which model handles which kind of step, so easy steps can go to cheaper models. A fresh installation has no model set up and spends nothing until you connect one.

Your intents, memory, evidence and receipts are stored in the database you run. Prompts and files go to the model providers you connect. If you host your own model, those steps stay on your machine.

No. A person sets the limits. A charge that would pass one is refused before it is made, and reaching a limit hands the decision back to a person.

It carries one of ten named reasons, each with a plain meaning and a fix, and the board shows it. A step waiting for your approval is not held back: it pauses at a waitpoint and shows as Waiting on a person.

Not today. The self-hosted Runtime has no level setting: how far an agent goes is set job by job, by its intent, budget, leases and waitpoints. The earned-autonomy ladder is in build.

There is no public price for the self-hosted Runtime yet. Talk to us about your team and what you want to run.

Your machines. Your rules.

Not a developer? Start free in Studio ↗In development · Self-hosted · macOS, Linux and WSL2