For people who want the keys.

What you can do

• Bring your own key

  Point your worker at your own provider account instead of ours. You pay the provider directly at their rates, your usage sits on your own bill and your own rate limits, and our credits stop being part of the equation for those calls.

  • Use the accounts and pricing you already negotiated
  • Usage and logs stay on your provider account
  • Mix it — your key for the heavy models, our credits for the rest

• Run the model yourself, on your own server

  You do not have to use anyone's API. Ollama is a free program you download and install on a machine you own — your own server, a box in your office, or a rented instance — and it runs open-weight models on that hardware and nothing else. It exposes an HTTP endpoint you point your worker at, and from then on the thinking happens on your metal rather than on a provider's. To be precise about what that does and does not buy you: the model and the inference are yours, and no prompt reaches a third-party provider. Your worker still assembles the prompt on its own instance before sending it to you, so this is model independence rather than a full data-residency guarantee — if residency is the requirement, talk to us about where the instance itself lives.

  1. 1Install Ollama on your own server — one download, Linux, macOS or Windows
  2. 2Pull the open-weight model you want with one command — it lives on your disk, not ours
  3. 3Expose the endpoint to your worker over your network or a private tunnel
  4. 4Paste that address into your worker's model settings and it uses it from then on
  • Not only Ollama — any endpoint speaking the same standard API works
  • Smaller open-weight models run on a single GPU; the flagship ones need more
  • No credits are spent on those calls — the hardware is the bill
  • The weights and the thinking stay on your hardware, not ours

• Run your own channel connectors

  By default we handle the messaging plumbing for you: connect a channel, and your worker turns up in the chat app you use. If you would rather own that layer, you can. Bring your own numbers and your own credentials, register your own webhook endpoints, and keep the whole conversation path inside accounts that belong to you.

  • Your own WhatsApp Business number and credentials
  • Your own Telegram, Slack or Discord app registration
  • Point message webhooks wherever you need them to land
  • Add or remove a channel without touching the rest of the worker

• Tools, APIs and MCP

  Your worker ships with more than sixty built-in tools — web search, browsing a real page, reading images, files, code, speech. Beyond those it speaks MCP, so any MCP server you point it at becomes another set of things it can do, and you choose which of that server's tools it is actually allowed to call. Anything with an HTTP API is reachable whether or not anyone has written a connector for it.

  • Connect any MCP server, local or remote
  • Filter a server's tools rather than taking all of them
  • Call a plain REST or GraphQL API with your own credentials
  • One-click connectors stay available alongside all of this

• Skills — download them or write them

  A skill is a plain markdown file describing how to do something, which your worker loads only when it is relevant. It writes its own as it goes: work out a fiddly procedure once and it saves the method. You can also write them by hand, install ready-made ones from public registries or a URL, or point it at documentation and tell it to go and learn.

  1. 1Let it write one — it saves a working method the first time it finds one
  2. 2Write one yourself — a SKILL.md file, frontmatter and prose, nothing exotic
  3. 3Install one — from a public registry, a repository, or a direct link
  4. 4Teach it one — hand it documentation and it authors the skill for you
  • Follows the open agentskills.io format, so skills are portable
  • Installed skills are security-scanned before they land
  • Skills live on your server, and they are yours to export
  • Only the one being used is loaded in full, so a big library stays cheap

• It is your server

  Every worker already runs on its own isolated instance rather than a shared pool. That is what makes the rest of this possible — your keys, your endpoints, your data, in a space nothing else shares.

  • Isolated per customer, not multi-tenant
  • Your connected accounts, revocable in one click
  • Full deletion on request, not just cancellation