Per-seat AI pricing scales with headcount because the vendor is running the software on their infrastructure, and you are paying for your share of it. This guide covers AI agents without subscription fees: what changes when the orchestration runtime lives on a server you control, and what replaces the seat fee.
Short answer: You can run AI agents without subscription fees by deploying the orchestration runtime on a server you own or rent. The per-seat fee disappears because the software runs on your infrastructure, not a vendor's. Infrastructure hosting and model inference costs take its place, and neither scales with the number of people using the system.
How this works, in plain terms
The subscription is an operational artifact of who runs the software, not a feature of it. On a self-hosted multi-agent platform, the orchestration runtime, task queue, conversation history, agent configuration, and documents run on a dedicated machine you own or rent. The vendor ships the software and its updates; it does not host your installation and does not meter your usage. Nothing counts how many people log in, because there is no billing surface that does the counting. The tenth user costs the same as the second in licensing terms, which is to say nothing.
Two cost categories replace the seat fee. The first is fixed: a server, plus the attention needed to keep Linux patched and backups running. The second is variable: per-token charges when an agent calls an external frontier model gateway such as Anthropic Claude, Google Gemini, or OpenAI, or the cost of power and hardware if the model runs locally on your own CPU or GPU. Neither category is a function of headcount. Add five people and the server invoice does not move; the inference invoice moves only if those people generate more agent work.
| Aspect | SaaS AI subscription | Self-hosted node |
|---|---|---|
| Cost structure | Per seat, scales with headcount | Infrastructure cost, independent of headcount |
| Where the runtime lives | Vendor's servers | Your server or rented VPS |
| Who controls stored data | Vendor | You |
| Model inference cost | Bundled into the seat fee | Per-token gateway cost, or local compute |
| Who manages the software | Vendor | You or your integrator |
A worked example
An operations team of twenty wants agents to triage inbound email, draft documents, and route internal tasks. They rent a VPS with 2 vCPU, 4 GB RAM, and 20 GB SSD running Ubuntu, and configure the agents to send reasoning to an external model gateway. Two lines appear on their books. The VPS is a flat figure, identical whether five people use the node or fifty. Per-token gateway charges are variable and follow task volume and task complexity rather than the payroll.
Grow that team to forty people with the same workload and neither line changes. Ask the agents to draft four times as many documents and only the token line moves. The cost follows the work, not the org chart.
The decision point is data residency. If prompts must never leave the server, the same node is reconfigured to run local open-weight models on dedicated CPU or GPU hardware sized to the chosen weights. Everything moves into the fixed column and external gateway charges fall to zero. In both configurations, other outbound traffic still crosses external networks by design: an email sent through SMTP, a Telegram message, or a voice call over a cloud service.
The architecture behind both configurations is described in the self-hosted AI agents overview.
Steps to apply it
Order matters here. The two decisions that shape everything else, hardware and model strategy, come before any installation work begins.
- Choose your deployment target. Rent a VPS running Ubuntu or Debian, at minimum 2 vCPU, 4 GB RAM, and 20 GB SSD, if agents will route inference to an external gateway. Reserve dedicated hardware for local model inference. After this step you have a server with a known owner and a known monthly cost.
- Decide your model strategy before you install anything. Gateway inference keeps the hardware bar low and adds a per-token cost; the context payload of each inference request leaves your server for that provider's API. Local open-weight inference keeps inference inside your network and moves the cost into hardware. After this step you know which of the two bills you are signing up for.
- Deploy the node. Follow the installation runbook at /docs/install on the server you chose. After this step the runtime is running on your infrastructure and reachable by your team.
- Configure your agents. Give each one a role, grant its tools under a least-privilege allowlist, and connect a channel: browser web chat, internal agent mail, SMTP/IMAP email, Telegram, or voice. Each agent runs as its own isolated system user, so one agent cannot reach another's files, mail, or credentials. After this step every agent has a defined job, a bounded set of tools, and a way to be reached.
- Load credentials into the local secret store. API keys, mailbox passwords, and database tokens stay on the server and are resolved from that store; they are not injected into model prompts. After this step agents can act on external systems without your credentials passing through a prompt.
- Run one test task end to end. Confirm the task completes, and confirm that a human-in-the-loop gate appears before any action that sends an external message, deletes a record, spends money, or runs a privileged command. After this step you have evidence that the boundaries hold, not just documentation saying they exist.
Common mistakes
Two mistakes account for most of the disappointment in self-hosted deployments, and neither one surfaces during installation.
Warning: Choosing gateway-based inference lowers the hardware bar. It does not keep all data local. When an agent calls an external frontier model, the context payload for that request travels to that provider's API under their commercial zero-retention API policies. Documents, conversation history, agent configuration, and credentials stay on your server; the in-flight context of that one request does not. If full local data residency is a requirement, gateway inference is the wrong configuration.
Warning: Self-hosting transfers operational responsibility to your organization. Operating system updates, backups, system monitoring, and recovery procedures are yours, or a managed hosting partner's. That is ongoing work rather than a licensing fee, and it is where many self-hosted plans stall. If nobody on the team can administer a Linux server, arrange an integrator or a managed host before installation begins.
Frequently asked questions
Do I really pay nothing ongoing if I self-host?
No. Infrastructure hosting and per-token model gateway costs remain. What disappears is the per-seat licensing fee, and the useful part of that change is that neither remaining cost grows with the number of people using the system.
How many people can use one node?
A single node serves an entire team, with no per-user licensing cost and no seat count to raise. Headcount-independent licensing is an architectural property of running the runtime yourself, so adding the fiftieth user adds nothing to the licensing line.
What happens to my data when agents use an external AI model?
Data stored on your server stays on your server: documents, conversation history, configuration, and credentials. The part that leaves is the context payload of a specific inference request sent to an external gateway, which travels to that provider under their commercial zero-retention API policies. Hold onto that distinction between stored data and in-flight inference context.
Can I run this on a cloud VPS, or does it need a physical server?
A VPS running Ubuntu or Debian is sufficient for gateway-based inference at the minimum specification of 2 vCPU, 4 GB RAM, and 20 GB SSD. Dedicated hardware is required only when you want fully local open-weight model inference.
Does self-hosting make me GDPR or HIPAA compliant automatically?
No. Compliance depends on the overall infrastructure configuration, access policies, data retention practices, and administrative procedures you put in place. Installing the software is one component of a compliance posture, not a substitute for the rest of it.
What if I want no prompts to leave my server at all?
Configure the node with exclusively local open-weight models on sufficient CPU or GPU hardware. That removes external inference egress entirely. Expect a substantially higher hardware requirement than a gateway-based deployment.
Next step
The Smart Node engineering team builds and documents the platform.
Deploy the runtime on a server you control: Set up your node.