Self-hosted vs hosted AI tools: what the switch really costs
Self-hosting an AI tool removes the subscription and adds an operations job: uptime, updates, credentials and security review. It wins on data residency and provider choice. It loses whenever nobody on your side owns patching, because an agent with broad permissions is a production system.
By the AI Alt Finder team
The pitch for self-hosting is simple: free software, your hardware, your choice of model provider, no per-seat fee. The pitch is true and incomplete. What the subscription was also buying was somebody else's responsibility for keeping the thing running and safe.
What self-hosting genuinely gives you
- Data residency. Documents and prompts stay on infrastructure you control, which is the only version of this argument that survives a compliance review.
- Provider choice. Open-source clients licensed Apache-2.0, including Aider, Cline, Continue and the vendor CLIs from OpenAI and Google, all run against whichever model key you supply.
- No per-seat pricing. Cost becomes hardware plus tokens, which scales differently from headcount.
- Inspectability. You can read the code, which matters most for tools granted broad permissions.
What it costs that no pricing page shows
Uptime is now yours. So are updates, dependency upgrades, credential rotation, backup and the security review. For a personal tool that is an evening a month. For anything a team depends on, it is a named person's ongoing responsibility, and if that person does not exist the tool degrades quietly until it fails loudly.
There is also a support asymmetry. When a hosted product breaks you file a ticket. When your own instance breaks you read logs, and the time that takes is the real price of the subscription you cancelled.
The security profile is different in kind, not degree
Self-hosted agents tend to be granted much wider permissions than hosted ones, because they run beside your accounts rather than inside a vendor's sandbox. OpenClaw's documented risk profile is a fair illustration: broad permissions across email, calendars and messaging, susceptibility to prompt-injection attacks, third-party skills that have not been adequately vetted, and misconfigured instances.
None of that is a reason to avoid self-hosting. It is a description of the job you are taking on. An agent that reads your inbox and runs shell commands is a production system with a large attack surface, and it should be treated like one from day one.
When does the arithmetic favour self-hosting?
- You have a data-residency rule that a hosted product cannot satisfy. This is the strongest case and it does not depend on cost at all.
- You want to switch model providers without switching tools, which an open-source client makes trivial.
- You already operate servers, so the marginal operations cost is small rather than new.
- Your usage is heavy enough that metered tokens on your own key beat several subscriptions.
When does it not?
When nobody owns operations. When the tool needs to be reachable while your machine is off, which self-hosted software on a laptop cannot do. When the team includes people who will not configure anything. And when the subscription you are replacing is bundled with something you already pay for, in which case the marginal saving may be close to zero.
A reasonable middle path is common: hosted products for team-facing work, self-hosted for the specific workload that has a residency or provider constraint. Keep the credentials separate, and do not give the self-hosted agent access it does not need for that one job.