What is a hosted runtime for AI workers?
A hosted runtime is the managed environment that executes an AI worker's runs, so it follows its schedule with no machine of yours left running.
An AI worker that only runs while your laptop is open is not unattended, it is a script with extra steps. The runtime is what removes your laptop from the picture.
Hosted vs running it yourself
| WorkerKit hosted runtime | Rolling your own | |
|---|---|---|
| Machine to keep alive | None | A server that never sleeps |
| Credential storage | Managed, per worker, scoped | Your own secret store |
| Scheduler | Wall clock, your time zone | Cron, plus DST bugs twice a year |
| Rate and cap enforcement | Built in, hard caps | You build it |
| Retries and recovery | Built in | You build it |
| Audit trail | A receipt per run | Your log pipeline |
| Token billing | Provider list price, no markup | Direct to provider |
That table is the honest argument for a hosted runtime. Nothing in it is impossible to build; all of it is work you have to keep doing.
What the runtime is actually responsible for
Executing a run sounds like one thing and is six:
- Waking up at the scheduled minute, or when a webhook fires
- Holding credentials for connected apps, using only the access that worker was granted
- Calling the model the worker is deployed on, and metering what it costs
- Enforcing limits: the daily tool call cap, the rate shaping, the per-app access levels
- Recovering when an app is down or a run overruns
- Writing the receipt, so an unattended run is still inspectable
Engineering Pulse is the shape in practice: it reaches GitHub on a morning schedule and delivers a digest of pull requests needing review, stale branches and failing workflows. Nobody starts it, and nothing of yours is running overnight to make it happen.
Where WorkerKit runs today
WorkerKit hosts every run. There is no agent to install and no server to keep alive.
Running a worker on **your own machine or infrastructure is not available yet and is coming later.** Worth stating plainly, because self-hosting is a reasonable requirement and today the honest answer is not yet.
What a run costs
Two costs, kept deliberately separate:
| What it buys | Price | |
|---|---|---|
| The plan | Capacity: workers, tool calls, schedule granularity, log history | $0 Free, $29 Pro, $299 Team flat for up to 10 users |
| Model tokens | The thinking | Provider list price, to the cent, no markup |
The separation is the point. WorkerKit does not profit from your worker being chatty, so nothing in the pricing pushes you toward a bigger model than the job needs. Tokens come from the wallet or your own provider key.
Failing predictably
Two behaviours matter more than raw uptime once a fleet is unattended.
Reserve before run. A run reserves its token budget before it starts. A balance that will not cover the reserve skips the run and says so on the receipt. Top up and the next due run goes ahead. Nothing is half-completed.
Hard caps. At the daily tool-call cap a worker stops until the counter resets, then picks its schedule back up. Nothing is deleted and no setting changes. A runaway loop on a soft cap is an invoice; on a hard cap it is a paused worker and a receipt explaining why.
When a hosted runtime is the wrong fit
The comparison table above is the case for it. The case against is narrower but real, and worth stating plainly rather than leaving for you to discover.
| Requirement | Why hosting does not meet it |
|---|---|
| Data must not leave your infrastructure | Runs execute on WorkerKit's. Self-hosting is coming later, not available now |
| A system reachable only from inside your network | A hosted runtime cannot route to it without you exposing it |
| You already operate this | If you run infrastructure, hold secrets and carry a pager, you may fit it better yourself |
| Regulatory placement of processing | Where a run executes is sometimes the compliance question |
The first row is the one that decides most conversations, and there is no workaround to offer: if data residency inside your own boundary is a hard requirement today, this is not the right time to adopt.
The others are trade-offs rather than blocks. Building it yourself means building the six responsibilities listed above, and the honest position is that a team with existing infrastructure can do that well, while a team without one is choosing to become an infrastructure team in order to run a worker.
FAQ
Can I run a WorkerKit worker on my own server?
Not yet. WorkerKit hosts every run today, and running a worker on your own machine or infrastructure is coming later. Everything else about a worker, the instruction, the per-app permissions, the schedule, works the same way now.
Do I need to install anything to run a worker?
No. There is no agent, no daemon and no machine to keep alive. You connect the accounts a kit asks for and deploy it, and the runtime takes it from there.
What happens if my wallet runs out mid-schedule?
Nothing runs half way. Each run reserves its budget before starting, so a balance that will not cover it causes the run to be skipped with the reason on the receipt. Top up and the next due run proceeds normally.
Does WorkerKit mark up model tokens?
No. Tokens bill at the provider's list price to the cent. WorkerKit's own fees are the plan price and the wallet top-up fee of 5.5% with a $1 minimum, both stated in the open. See /pricing.
What happens when a worker hits its daily tool-call limit?
The worker stops until the counter resets, then resumes its schedule. Free allows 500 tool calls a day, Pro 5,000, and Team 50,000 pooled across the account. Nothing is deleted and no configuration changes.