An agent harness holding hours of session state or a retrieval pipeline keeping embeddings in memory needs a much higher ratio of RAM to CPU than typical request/response services. Deploying these workloads on long-running, stateful compute shouldn't mean overpaying for CPU to get the memory you need.
Today, we're adding over 15 new memory-optimized compute plans for Render services. These plans are designed specifically to help you run agents and other memory-intensive workloads efficiently.
More memory at every scale
Our new compute plans let you increase a service's memory independently of its CPU. At every 2+ CPU tier, there are now multiple memory options. For example, at 4 CPU you can choose between 8GB, 16GB, and 32GB of RAM.
You can see the full range of compute plans on our pricing page or in the Render Dashboard.
High-CPU plans
We're also introducing a 12-CPU tier for web services, private services, and background workers, with up to 96GB of RAM. These plans are built for workloads that need headroom to scale vertically.
For example, self-hosted agent platforms like OpenClaw often run many concurrent sessions on a single deployment, each holding its own state and often driving its own headless browser. Scaling up to make the agent more productive means giving it more resources on a single instance.
New, intuitive plan IDs
With more options to choose from, we are updating the naming convention for compute plans to make them more intuitive. Now, each plan has an ID referencing the relevant specs for the plan. For example the 4 CPU, 32GB RAM web service plan has an ID of 4c-32g. In practice, you only need to use this ID if you are setting your plan type through a Blueprint or using the Render CLI, API, or SDK.
Render Blueprints and the Render API, SDK, and CLI remain backward compatible with legacy compute plan values like standard, pro plus, and pro ultra. You can optionally update your code to use the new plan IDs, but no changes are required. To avoid any issues when you start using the new plan IDs, we recommend updating to the latest versions of Render clients and integrations, including the CLI and Terraform provider.
Choosing the right plan
If you're not sure whether to move one or more services to a higher memory plan, your service metrics are the best guide. The Render Dashboard shows CPU and memory usage for every service, so you can see which resource your workload actually runs out of.
If memory climbs while CPU stays flat, a memory-optimized plan gives your service the headroom it needs without stepping up a full CPU tier. A 2c-4g service pushing its memory limit, for example, can move to 2c-16g for four times the RAM with no change in CPU.
Alternatively, if one of your services is consistently only using a fraction of the CPU available to it, you may be able to reduce your costs by moving to a plan with the same RAM but lower CPU.
Whichever way you scale, it's worth sizing for your spikes rather than your average. Sustained memory pressure near a plan's limit risks out-of-memory restarts, so pick the memory option that covers your peaks with room to spare. The same logic applies if your service is CPU-bound, with request queues backing up or task throughput flattening out: move up a CPU tier, then choose the memory option that matches your footprint.
You can change a service's compute plan at any time. And if you'd like help choosing, our support team is available through the Render Dashboard.