AI Agent Server Sizing
Cloudways AI Agent Size Calculator: Scout, Operator, Squad or Swarm
The Cloudways AI Agent Size Calculator is for the part of the buying process most hosting pages skip: deciding how much server you actually need. Cloudways offers Scout, Operator, Squad and Swarm for Managed AI Agents, but a plan name alone does not tell you whether your OpenClaw or Hermes workload will be light, active, parallel or continuously busy. The practical signals are concurrency, channels, sub-agents, runtime pattern and the amount of local files and logs the agent keeps.
This calculator scores those signals and maps the result to the smallest sensible Cloudways starting tier. It is intentionally conservative about certainty. No browser calculator can see your real CPU or memory use before deployment, so the output should be treated as a planning baseline. Start there, monitor a representative period and then scale from evidence.
Interactive tool
Cloudways AI Agent Size Calculator
Estimate the smallest sensible Cloudways instance from workload, concurrency, channels, sub-agents and runtime pattern. The result is a planning recommendation, not a benchmark guarantee.
Quick answer
How do you choose the right Cloudways AI Agent instance size?
Choose Scout for light checks and one or two simple workflows, Operator for an active agent doing focused daily work, Squad for multiple workflows or sub-agents, and Swarm for many agents and tools running continuously. Then adjust that starting point upward when concurrency, several live channels, heavy local files or frequent scheduled jobs make the workload more demanding.
The calculator below uses those workload signals rather than only asking how many users you have. One user can create a heavy agent with parallel tasks, while a small team can use an agent lightly. After deployment, check usage over time and scale only when sustained pressure or workload growth justifies it.
Cloudways AI Agent sizing reference
Use the plan labels as workload descriptions, then validate with the interactive calculator and real monitoring.
| Plan | Compute | Storage / bandwidth | Standard price | Best starting fit |
|---|---|---|---|---|
| Scout | 1 vCPU / 2 GB RAM | 50 GB SSD / 2 TB bandwidth | $9.99/mo standard | Light checks, testing and one or two simple workflows |
| Operator | 2 vCPU / 4 GB RAM | 80 GB SSD / 3 TB bandwidth | $19.99/mo standard | An active agent doing focused, regular work |
| Squad | 4 vCPU / 8 GB RAM | 160 GB SSD / 5 TB bandwidth | $39.99/mo standard | Multiple workflows or coordinated sub-agents |
| Swarm | 8 vCPU / 16 GB RAM | 320 GB SSD / 6 TB bandwidth | $79.99/mo standard | Many tools, agents and continuous production activity |
Current standard pricing
Cloudways Managed AI Agent instance plans
LLM provider usage is billed separately.
- 1 vCPU
- 2 GB RAM
- 50 GB SSD
- 2 TB bandwidth
- 2 vCPU
- 4 GB RAM
- 80 GB SSD
- 3 TB bandwidth
- 4 vCPU
- 8 GB RAM
- 160 GB SSD
- 5 TB bandwidth
- 8 vCPU
- 16 GB RAM
- 320 GB SSD
- 6 TB bandwidth
Why user count is a weak sizing metric for AI agents
Traditional web hosting often starts with visits or users because page requests are a reasonable workload proxy. AI agents behave differently. One person can launch a long research workflow, open a browser, run code, call external tools and delegate several tasks at once. Ten people can also share an agent that receives only a handful of simple requests each day. Human count is therefore not enough to size the server.
Concurrency is more informative because it captures how much work overlaps. A single task can be heavy but manageable if it runs alone. Several tasks running together compete for CPU, memory and process slots. Sub-agents amplify the same effect. Messaging channels matter because they create more ways for work to arrive asynchronously. Scheduled jobs matter because they can overlap with interactive use even when nobody is actively chatting.
The calculator uses a score rather than pretending that one factor has a universal conversion to RAM. It starts with the general workload level, then adds pressure for concurrency, channels, sub-agents, continuous runtime and local storage. That approach is simple enough to understand and transparent enough to challenge if your real measurements tell a different story.
When Scout is the correct answer
Scout gives you 1 vCPU, 2 GB RAM and 50 GB SSD storage. Cloudways describes it for light checks and one or two simple workflows, which is exactly how it should be used. A test agent, personal assistant with occasional requests or proof of concept can start here without paying for capacity that may never be needed. It is also useful for learning the platform before a production architecture is decided.
Scout becomes less comfortable when the agent is active throughout the day, runs several background jobs, connects to multiple busy channels or uses sub-agents. None of those factors guarantees failure on 2 GB, but together they reduce headroom. If you already know the agent will be a core daily tool, starting at Operator can be more efficient than testing Scout only to resize immediately.
The main advantage of Scout is disciplined validation. Deploy the smallest meaningful version of the workflow, observe it, and ask whether the agent itself creates value. Do not begin by optimizing a large infrastructure bill for an automation idea that has not yet proved useful. Capacity can be added after usefulness is established.
When Operator is the best default
Operator provides 2 vCPUs, 4 GB RAM and 80 GB SSD storage. Cloudways positions it for an active agent doing focused real work, which makes it a strong default for a production-minded single agent. The additional memory and CPU give room for more persistent activity, overlapping jobs and helper processes without jumping directly to the multi-agent tiers.
Choose Operator when the agent is expected to be used every day, especially if it connects to one or two communication channels, runs scheduled tasks or performs browser and terminal work. It is also a sensible starting point when you are unsure whether Scout will be too tight and the monthly price difference is less important than avoiding early resource pressure.
Operator is not a universal sweet spot. If several sub-agents are central to the design or the system will handle many concurrent workflows, Squad is more aligned with the workload. If the agent is truly light, Scout remains cheaper and adequate. The best default is the smallest tier that matches the way the agent will actually be used.
Why sub-agents push workloads toward Squad
Squad provides 4 vCPUs and 8 GB RAM, and Cloudways explicitly associates it with multiple sub-agents coordinating on tasks. That matters because delegation creates hidden concurrency. A user may see one request, but the agent can split it into several pieces that run in parallel, each with its own context, tools, temporary files and model calls. The server experiences the parallel work even though the interface shows one conversation.
If sub-agents are occasional, Operator may still handle them. If the architecture assumes regular delegation, Squad gives more predictable headroom. It is also appropriate when several independent workflows run at the same time, such as monitoring, research, channel responses and scheduled jobs. The goal is not to eliminate every spike but to keep the normal operating pattern within comfortable resource limits.
Sub-agents also increase model spend, so sizing should be paired with cost controls. More CPU makes it easier to run parallel work, but it can also make it easier to create unnecessary parallel API calls. Set delegation rules and evaluate whether parallelism shortens meaningful work or simply multiplies activity. Infrastructure and orchestration should be optimized together.
When Swarm becomes reasonable
Swarm provides 8 vCPUs, 16 GB RAM and 320 GB SSD storage. Cloudways describes it for many agents and tools running continuously. That is the key phrase: continuously. Swarm is not the plan to choose because you want the most powerful option. It is the plan to choose when heavy parallel activity is a normal operating condition and the cost of constrained resources is visible in latency, reliability or operational attention.
Examples can include a production automation environment with many agents, multiple channels, scheduled work, substantial local artifacts and frequent tool use. An agency may choose Swarm for a heavily used internal agent platform, while an individual developer may need it for a persistent multi-agent coding or research environment. The number of people is still secondary to the actual workload.
Before upgrading to Swarm, identify the sustained bottleneck. If memory is consistently high and tasks overlap, more RAM is reasonable. If storage is filling because logs are never cleaned, fixing retention may be better. If one workflow loops, scaling can hide the problem rather than solve it. Swarm should be an answer to measured demand, not an insurance policy against understanding the system.
How channels and scheduled jobs affect sizing
Channels make an agent more accessible, which usually makes it more active. An OpenClaw agent connected to WhatsApp, Slack, Discord and Telegram can receive work from several places even when its owner is not in the dashboard. A Hermes agent may receive remote requests while also running technical tasks. Each channel is not a fixed resource cost, but it increases the probability of overlapping sessions and background processing.
Scheduled jobs create a similar effect. A daily report may begin while a user is running an interactive research task. Monitoring may continue while another workflow is writing files. When these overlaps are predictable, size for them. If the agent is quiet most of the time and only one short job runs nightly, do not inflate the plan solely because scheduling exists.
Use timing as an optimization lever before scaling. Stagger heavy jobs, avoid launching every recurring workflow at the same minute and limit unnecessary channel-triggered automation. Good scheduling can flatten the workload and make a smaller tier comfortable. The calculator adds points for frequent and continuous runtime because poor overlap is common, but thoughtful orchestration can reduce the actual pressure.
How to validate the calculator after deployment
The calculator is a pre-purchase tool, not a replacement for monitoring. After launch, observe the instance over several representative days. Look for sustained CPU pressure, memory exhaustion, growing storage, slow task completion and repeated failures. Compare those symptoms with the moments when channels, schedules or sub-agents are most active. The pattern matters more than a single peak.
Cloudways recommends evaluating usage over time before scaling, which protects against overreacting to a one-off spike. If the system is generally healthy and one large job briefly consumes resources, you may not need a bigger plan. If every afternoon shows memory pressure because several workflows overlap, the evidence supports scaling or changing the schedule.
Keep a small sizing log: initial tier, reason for the choice, normal workload, observed bottleneck and date of any resize. That turns future decisions into an operating history rather than memory. If the agent later grows from one workflow to several, you can see whether the resource change came from real adoption, a new integration or inefficient behavior.
A sizing checklist before you trust the recommendation
Use the calculator with the busiest normal day in mind, not the quietest test session and not an extreme event that happens once a year. Estimate how many useful tasks can overlap, how many channels can generate work and whether scheduled jobs run during interactive use. This produces a more realistic starting tier than entering the lowest possible values simply to reach the cheapest recommendation.
Then challenge the result with architecture choices. Could heavy scheduled jobs be staggered? Could large files live outside the agent server? Could a workflow that launches many sub-agents be simplified? Good architecture can reduce resource pressure before you buy more capacity. The calculator assumes typical overlap, but thoughtful orchestration may allow a smaller plan to perform comfortably without reducing useful work.
After deployment, replace estimates with measurements. Compare the calculator inputs with what really happened: actual concurrency, storage growth, channel activity and the number of parallel agents. If reality differs, update the assumptions and reconsider the tier. A sizing tool is most valuable when it starts a measurement loop rather than when its first answer is treated as permanent.
Methodology and primary sources
Cloudzat bases plan resources, pricing, deployment requirements and supported workflow claims on current Cloudways product and help-center documentation. Last verification date: August 26, 2026.
- Cloudways Managed AI Agents getting-started guide
- Cloudways Managed AI Agent instance sizing guide
- Cloudways OpenClaw managed hosting
- Cloudways Hermes managed hosting
- Cloudways Managed AI Agents general availability announcement
- Cloudways communication channels guide
- Cloudways MCP connection guide for Managed AI Agents
Frequently asked questions
What is the best Cloudways AI Agent plan for beginners?
Scout is the natural beginner and testing tier because it is designed for light checks and simple workflows. If the agent will be active every day from the start, Operator may be a better baseline.
How much RAM does Scout have?
Scout has 2 GB RAM with 1 vCPU and 50 GB SSD storage.
When should I choose Squad?
Choose Squad when multiple workflows or sub-agents are a regular part of the design, or when 4 GB Operator resources leave too little headroom for normal concurrency.
Is Swarm necessary for a team?
Not automatically. Team size is a weak proxy. Choose Swarm when the workload includes many agents and tools running continuously or when monitoring shows sustained resource pressure.
Can I resize later?
Yes. Cloudways documents upscaling and downscaling Managed AI Agent instances. Use real usage over time to decide rather than one short spike.
Does the calculator include LLM cost?
No. The calculator sizes Cloudways infrastructure. Your model provider bills API usage separately and that cost depends on models, token volume and workflow behavior.
Cloudzat may earn a commission if you sign up for Cloudways through links on this page. This does not change your price. Managed AI Agent features, integrations, plan resources, model-provider costs and promotions can change, so confirm critical details in Cloudways before purchase or production deployment.