You came here by clicking through to what the preview really covers. That is what this page is: the questions I would ask in your place before installing an agent runtime, and my answers written down, including the four that do me no favours. You will not have to go hunting for those, they open the page.
Not one of them is softened. Not one waits in a footnote.
0.2.0-preview · 23 questions · A grid that works on any runtime
When you evaluate a tool seriously, the first thing you go looking for is what is missing, because that is the part that costs you three weeks later. So you may as well have them straight away, in the words I would use if you asked me out loud.
Each one is followed by what bounds the risk, where something bounds it. The bound does not replace the answer and it takes nothing away from it: it tells you what you are working with.
Nothing.
On all three systems, an agent can do anything your account can do.
It runs under your account, with your rights, like any other program you start. What holds it is not a prison, it is a counter: you set the number of steps, the number of tool calls and the duration, the runtime enforces them, and the agent code can neither raise them nor slip out from under them. Apollia bounds an agent, it does not lock it away.
None.
A booby-trapped piece of text can therefore try to give the model orders in your place, here as anywhere else. What bounds the damage is your permission rules, read again on every tool call on the conversational path: a tool that no rule allows stops and asks you, and a refusal you wrote yourself beats any permission. An installed agent that calls its own tools, on the other hand, never reaches that checkpoint.
It detects tampering, it does not prevent it.
A SHA-256 hash chain, append-only writes enforced by the database itself, a signature, verification from the programming interface as well as from the command line, and an export you can hand to someone. Two limits worth knowing: the signing key lives in a file sitting next to the database, and the tool calls inside a chat session do not enter the chain, only the envelope of the turn.
What it really guarantees: a change made by someone without access to your data directory shows up when you verify. It is not a vault, it is a witness.
No.
Treat every write as final.
What protects you sits before and after: the approval you are asked for at the moment of the action in a conversation, and the journal that keeps the record of what was done. Between the two, there is no undo button.
What costs you is not a young product. What costs you is hitting a wall three weeks after you started building on it. What this preview covers is written down before you install it.
A page like this one is true the day it goes up, and slowly false after that. The code moves, the page stays where it is, and nobody notices before the reader who trusted it does. That is the ordinary failing of the genre, and it has one cure: have the page checked by a machine rather than by its author.
You will notice that nowhere do I write how many claims it goes through. That number is something you read after running the command, not before.
git clone https://github.com/Apollia-OS/apollia-os
cd apollia-os
python3 scripts/check_claims.pyYou will not find a comparison table on this site. A grid is judged on its worst cell, and one inaccurate line about somebody else's product is enough to bring the rest of it down too. So I answer for Apollia, and I leave you the column opposite.
The 23 questions below hold for any agent runtime. Take them with you, put them to whatever else you are weighing up, and compare the answers rather than the promises.
Plain text, ready to paste into a document or a message.
This first set decides whether you can let it read your real files. It comes down to a single question: what leaves the machine, and on whose action.
On your machine, inside the program running in the background. Your Python code is called straight from the runtime, which is written in Rust, with no virtual machine and no remote service in between.
On your machine, in a program called llama-server that the runtime starts itself. The installed app carries it; if you build from source, you supply it. A remote model exists only if you configure one.
Nothing. No automatic update check, no catalogue refresh, no usage tracker anywhere in the source.
Seven things, and every one of them starts with something you do: the update check you run, downloading a model, connecting a Google or Microsoft account, a remote tool server you declare, a web search, reading a web page, and a remote AI service if you plug one in.
In a folder on your own disk, ~/.apollia, as SQLite databases, one per domain. Nothing is replicated anywhere else.
It listens on 127.0.0.1, the address that never leaves the computer. Its programming interface demands a token, the equivalent of a password, the moment it goes over the network; a local channel, kept private by file permissions, sits alongside it. Open it up beyond the machine without that token and startup fails instead of warning you.
This second set is the one that costs you if you find it out too late. The bluntest answers on this page are in here, and they are written out in full.
On Linux the child process is isolated: it cannot see the other programs running, it sees only the part of the disk you show it, and it gets cut off if it consumes too much. On macOS only the consumption limits apply, and a warning goes to the log on every call. On Windows, no confinement at all.
What still stands in front of those two tools in a conversation, on all three systems, is your approval: a call that none of your rules allow stops and asks you.
Nothing. On all three systems, an agent can do anything your account can do.
It runs under your account, with your rights, like any other program you start. What holds it is not a prison, it is a counter: you set the number of steps, the number of tool calls and the duration, the runtime enforces them, and the agent code can neither raise them nor slip out from under them. Apollia bounds an agent, it does not lock it away.
In a conversation: you are asked one tool call at a time, file paths are guarded, and an approval that never comes counts as a refusal. On the orchestrated path: the tools the agent manifest declares. An agent you installed that calls its own tools meets no checkpoint at all.
The practical rule that follows fits in one sentence: install only agents you wrote, or whose code you have read. It is the one you already apply to any script you picked up somewhere else.
No. It is live at the two lower autonomy tiers, the ones where the plan is put to you before it runs, and bypassed at the two higher tiers, by design and on the record. The tier is chosen per run, from the command line.
A higher tier grants no extra rights, it removes an interruption. What the agent is allowed to do does not change; what changes is how often it stops to ask you.
None.
A booby-trapped piece of text can therefore try to give the model orders in your place, here as anywhere else. What bounds the damage is your permission rules, read again on every tool call on the conversational path: a tool that no rule allows stops and asks you, and a refusal you wrote yourself beats any permission. An installed agent that calls its own tools, on the other hand, never reaches that checkpoint.
A SHA-256 hash chain, append-only writes enforced by the database itself, a signature, verification from the programming interface as well as from the command line, and an export you can hand to someone. Two limits worth knowing: the signing key lives in a file sitting next to the database, and the tool calls inside a chat session do not enter the chain, only the envelope of the turn.
What it really guarantees: a change made by someone without access to your data directory shows up when you verify. It is not a vault, it is a witness.
The step budget: you set the number of reasoning steps, the number of tool calls and the duration. The runtime counts them and stops the agent beyond them. The counter lives on the Rust side, out of reach of the agent code.
No. Crossing a token threshold raises an alert, it stops nothing.
What bounds a run is not its cost, it is its count of steps and calls. On a model running at your place there is nothing to bill; the token threshold only concerns remote services, the ones you plug in yourself.
No. Treat every write as final.
What protects you sits before and after: the approval you are asked for at the moment of the action in a conversation, and the journal that keeps the record of what was done. Between the two, there is no undo button.
This third set decides what you are left with in two years. It is the one people skip most often, and the one you pay for longest.
Apache 2.0 or MIT, your choice, full texts in the repository, inherited by all the code and by the development kit. No restriction on use, on redistribution or on forking.
Installers for macOS, Windows and Linux on the releases page of the repository, and a build from source for anyone who prefers that. The label is 0.2.0-preview: a preview, so judge it as one.
Linux on very nearly every automated step, macOS Apple Silicon on one blocking step, Windows on less than the other two. Windows ships, less guarded.
In practice: a regression specific to Windows has a better chance of getting through than a Linux one. The channel for reporting it is the same for all three, and it is open.
A single maintainer. Outside code contributions are closed on the v0.1.x line, and that is said up front rather than after someone has spent six weeks on one.
Issues are open, though, bugs and requests alike. And a fork asks nobody for permission: that is the recourse, and nothing restricts it.
No subscription, no enterprise edition. Recurring sponsorship that buys nothing inside the product, and a separate engagement for anyone who wants an agent built to order. There is no online service to resell, and no usage data to monetise.
In Python: an @agent decorator above a class, at least one method marked @skill or @on_message, nothing to inherit from, and a development kit that installs no third-party library. To plug in outside tools, Apollia is an MCP client, the standard protocol that exposes tools to a model, on all three of its transports.
One. Apollia runs under your account and works for you alone: no shared instance, no roles to hand out, no accounts to administer.
Nothing stops you installing it on several machines, each with its own data and its own rules. What does not exist is one instance that several people share.
The code, under a licence that cannot be taken back. Your data, in SQLite files in your own home folder, which any tool on the market opens. Your agents, which are ordinary Python and leave with you.
There is no online service to switch off, no activation key to revoke, no proprietary format to convert. That is what makes forking practical rather than theoretical.
You now know what this preview covers and where it stops. What a page cannot tell you is whether it holds up on your own work, on your own files, with your own habits. An evening answers that better than I can.
0.2.0-preview · macOS, Windows, Linux · Apache 2.0 or MIT