Your customers are asking for AI, and the obvious answer is one you would rather not give: open an account with a provider, route their data through it, and bill on top of tokens whose price you do not set. Apollia OS is the other road. It is a runtime, meaning the program that runs agents and hands them tools, and it installs on your customer's machine like any other piece of your product.
You embed it, you redistribute it, you charge for it. The licence says so in writing.
0.2.0-preview · MIT or Apache 2.0 · No server between you and your customers
A software vendor does not size up a runtime the way a curious developer does. You look first at what you are allowed to do, then at what could move under your feet, then at what you will have to maintain, and last at who picks up the phone the day a customer calls.
The rest of the page answers, in the same order.
The three coexist and combine. None of them asks you to write Rust, and none of them assumes you have read the code.
Three ways in, one runtime: the local API the app and the terminal also use, the Python kit to write your agents, and the MCP protocol so your product becomes a tool of the agent. They coexist and combine.
This is the front door, and it is not a service entrance: the desktop app and the command line go through exactly the same one. What your product drives is therefore the whole runtime, not a subset granted to integrators.
When to pick itYour product is not written in Python, or already runs as a service.
An agent is an ordinary class: one decorator above it, one async method inside it, nothing to inherit. The kit installs no third-party library, which means it shows up neither in your dependency tree nor in your licence review, and at a software company that is rarely a small matter.
When to pick itThe logic you want to automate is already in Python, or is about to be.
MCP is an open protocol through which a piece of software declares what it can do, in a format a model knows how to read. Publish an MCP server for your product and an Apollia agent uses it like any other client of the protocol. You write the integration once, not once per AI vendor.
When to pick itYou want to be drivable by AI without depending on which client someone picked.
The three surfaces of the runtime, in detail What an agent can act on
Yes, and commercially. MIT or Apache 2.0, you take whichever one clears your legal review, and the product you put it inside can stay closed.
MIT fits on a page and goes through anywhere. Apache 2.0 runs longer because it settles something MIT leaves open: the grant of the patents that cover the code. Publishing both keeps me out of an arbitration that is not mine to make.
The published version is 0.2.0-preview, and I am not going to sell it to you as a 1.0. What makes it workable: the API specification is generated from the code, and the version you ship moves only when you move it. Three anchors, and all three can be checked.
A breaking change arrives under a new prefix, never as a silent mutation of the one already in place.
An interface change therefore shows up in a diff, line by line, instead of being announced once and then forgotten.
The runtime runs on your customer's machine, embedded in your product. Nothing updates under your feet.
The changelog announces semantic versioning. What it does not say yet is which surface exactly that versioning covers, what the 0.x line allows itself, and what a deprecation notice would look like. I would rather tell you that than promise you a policy 0.1.0 would not keep.
Until it is written, the instruction fits on one line, and it is the one I would follow in your place: pin the version you ship. If you are building on a surface other than the HTTP interface, write to me first: I will tell you what I intend to move.
A vendor needs to know what is being added to the installer before knowing what it can do. Here is the list, unwrapped, for macOS Apple Silicon · Windows x86_64 · Linux x86_64.
Apollia OS is built by one person. What holds the quality up is therefore not a review committee, it is a chain of automated checks that lives in the repository, runs on every contribution, and that you can read before you take my word for anything.
All three systems are shippable. Two of them go through that chain on every contribution; Windows is built and published without that step.
Better said in the first sentence than in a footnote: Apollia OS is built by one person. So I sell no on-call rota, no contractual response time and no standby team, and I am not going to pretend otherwise on a page whose job is to convince you.
What makes that bearable is the shape of the product, and it is not a consolation prize. There is no remote service that can fall over underneath yours: what you ship runs on your customer's machine, without going through infrastructure I operate, because there is none. An outage on my side has no route to your users.
Looking instead for an agent designed around your line of work and built for you? That is a different need, and it has its own page. Have an agent built to order
Something written there is readable by everyone, and the answer serves whoever comes next.
Say what you are embedding, on which platform, and what is in the way.
The disclosure procedure is written in the repository and states its timelines.
They come back in almost this order, and the answers are the ones I give across a table.
The licence does not ask you to let me know, and the preview installs without you ever talking to me. But if you are seriously considering embedding it, a conversation up front will save you weeks: I know where things are going to move, and you know the constraint your own product is under.
0.2.0-preview · MIT or Apache 2.0 · macOS, Windows, Linux