foxora

RFoxora Runtime · the R in WRAP · Private preview

Run every agent job inside your rules.

Foxora Runtime is the engine you host yourself. Every job goes through six checks, stays inside a budget it cannot raise, and waits for a person before a risky step.

Private preview · macOS, Linux, Windows through WSL2 · Needs Docker

Example board · the states are the engine's, the jobs are not

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.

  1. 01It checks every job

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

  2. 02It keeps to the budget

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

  3. 03It waits for a person

    Before a step that changes something, the job pauses until a named person decides.

RRuntime · 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

RRuntime · 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

RRuntime · 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.

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. L5
    RunsIt owns the outcome and directs other agents.
    In build
  3. L4
    OwnsIt owns a whole job type. You read the weekly number.
    In build
  4. L3
    OperatesIt works on its own and flags the exceptions.
    Live in Studio
  5. L2
    ExecutesIt finishes the job, then stops for your approval.
    Live in Studio
  6. L1
    DraftsIt proposes. You do the work.
    Live in Studio
In Studio today
Levels 1 to 3 are live: agents draft, execute and operate, and flag the exceptions to you.
In the self-hosted Runtime
No 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 ladder
In build An agent will move up a level on its track record, never past the ceiling a person sets.

Sheet R-3 · levels 1–3 live in Studio · levels 4–5 in build · the top rung is always a person

RRuntime · 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

RRuntime · 5 of 5 · Install

One launcher, on a machine you control.

Runtime starts with one command, foxora up. It makes this installation's own keys and certificates, starts the engine and its database with Docker Compose, and gives you the console address once the console answers.

  • 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 your jobs in Foxora's cloud. Runtime runs where you put it.

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 in Foxora's cloud, in your browser, on the desktop or in the CLI.

A PLAN YOU CAN FOLLOW
Read the briefResearcher · complete
02Draft the proposalWriter · in progress
03Price three optionsPlanner · next
04Check the workVerifier · final review
Step 2 of 4 0:19 elapsed
Illustrated workflow · Sample scenarioA plan and the credits left

Free plan · 200 credits a month · No card required

Status · Private 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.

Private previewBuilt into the 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 buildNot 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, live on the web, desktop and CLI.

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.

Can I use Foxora Runtime today?

It's in private preview. 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.

How is it different from Studio?

Studio is the workspace: you brief agents, answer their questions and accept the work, on the web, on the desktop or in the CLI. It runs your jobs in Foxora's cloud, so there is nothing to host.

Runtime is the engine you run yourself, on machines you control, with the six checks, the budgets and the waitpoints on this page.

What do I need to run it?

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.

Which models does it 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.

Where is my data kept?

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.

Can an agent raise its own budget?

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.

What if a job is held back?

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.

Does Runtime set autonomy levels?

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.

What does it cost?

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

Private preview · Self-hosted · macOS, Linux and WSL2