Anyscale

Anyscale wraps Ray in four layers. There is provisioning: you register an Anyscale cloud against AWS, Azure, Google Cloud or a Kubernetes cluster, and Anyscale handles cluster creation, autoscaling by worker type, spot instances with on-demand fallback, and image caching so new nodes join quickly rather than rebuilding containers from scratch.

There is developer experience: Workspaces give you hosted VS Code, JupyterLab and a web terminal attached to a live Ray cluster, or you can connect a local VS Code or Cursor to the same containerised environment. Because workspaces, jobs and services share configuration, moving from interactive work to a scheduled production job is a packaging step rather than a rewrite.

There is production plumbing: Anyscale Jobs for batch training, data processing and batch inference, with job queues and schedules; Anyscale Services as an extension of Ray Serve with zero-downtime upgrades, head node fault tolerance and high availability. And there is governance — SSO, SAML and SCIM, role-based access across organisation, cloud and project scopes, audit log export, resource quotas per cloud or project or user, and spend budgets with alerts.

The observability layer is the part existing Ray users tend to notice first. Rather than generic cluster metrics, Anyscale ships purpose-built dashboards for Ray Data and Ray Train with operator-level metrics, dataset-aware logs, integrated CPU and GPU profiling, and 30 days of persisted logs so you can debug a failed run without keeping an expensive cluster alive to look at it.

Anyscale workloads do not run on stock Ray. They run on the Anyscale Runtime — the current name for what the company previously marketed as RayTurbo. It presents the same APIs and libraries, which is the explicit anti-lock-in argument, but adds proprietary behaviour underneath.

In Ray Data that means responsive cluster and actor pool autoscaling so jobs begin before the full cluster is up, job-level checkpointing that survives driver, head node or whole-cluster failure, and automatic file chunking, vectorised operations and query planning. In Ray Train it means mid-epoch resumption — restarting from the exact sample where a run stopped, so the dataset iterator still sees each row once per epoch — and elastic training that rescales worker groups when nodes are preempted. Ray Serve gets throughput and latency work. RLlib gets InfiniteAPPO, a decentralised asynchronous PPO variant, currently in beta and gated behind a support request.

Those are the features that justify the premium, and they are also the features you give up if you migrate back. Your Ray code will still run on open-source Ray; the fault tolerance characteristics you designed around will not.

Two deployment models, and the difference matters more than the pricing table suggests.

Hosted is the on-ramp: Anyscale-managed infrastructure on VMs, a limited set of regions, monthly credit card invoices, business-hours support with a cap of five case submissions. It is designed for a first project rather than a production platform.

Bring-your-own-cloud is the real product. Anyscale deploys into your account — AWS, Azure or Google Cloud, on VMs or Kubernetes, or on-premises — using a dual-plane architecture where Anyscale's control plane orchestrates and your data plane runs the clusters. Data stays in your storage, in your regions, under a documented shared responsibility model. You can point it at GPU reservations you have already paid for, and billing arrives either directly or through the AWS, Azure or GCP marketplaces, which matters if you have committed cloud spend to burn down. Enterprise SLAs with 24x7 coverage and unlimited support cases attach here.

The Kubernetes story has broadened considerably: Anyscale documents operator deployments on EKS, AKS, GKE, SageMaker HyperPod, CoreWeave, Nebius and Lambda Managed Kubernetes, plus generic clusters, with integrations for YuniKorn and Kueue scheduling. Machine pools and a global resource scheduler let you share reservations, spot instances and on-demand VMs across workloads and regions from one control plane.

Consumption, not subscription. Anyscale describes it as pay-as-you-go with no fixed monthly fee, unlocking discounts as usage grows, with committed contracts available for volume pricing.

On the Hosted tier the pricing page quotes all-in per-instance-hour rates in Anyscale Credits. As listed on 24 August 2026: 0.0135 for CPU-only, 0.5682 for a T4, 0.9542 for an L4, 1.3635 for an A10G and 4.9591 for an A100. Anything in the H100, B200 or GB families is a sales conversation. The credit denomination is a small but real friction — you cannot put those numbers next to a Runpod or Lambda rate card without first establishing what a credit is worth for your account.

On bring-your-own-cloud the structure inverts: compute is your cloud bill, and Anyscale's charge is the platform layer on top. That is the version most enterprise buyers end up on, and the one where the comparison against self-hosted Ray is cleanest, because the compute cost is identical either way and the only variable is the platform fee against the engineering time it displaces.

Nothing on Anyscale's own properties indicates a change of ownership or direction as of August 2026: the site carries a 2026 Anyscale, Inc. copyright, Ray Summit 2026 is scheduled with a published agenda, and the founding team remains the Ray authors from UC Berkeley's RISELab. Do not read that as confirmation nothing has happened — read it as the limit of what the company itself documents.

What has visibly changed is emphasis. The marketing has shifted from "managed Ray clusters" toward multimodal data processing, batch inference and agentic workloads, with named customer results — Tripadvisor on embedding generation cost, Canva on run time and cloud spend, Coinbase on fraud model training, Physical Intelligence and Runway on research workflows. The Kubernetes and multi-cloud surface has expanded well beyond the original AWS-and-GCP VM story. And Anyscale now ships agent skills for Claude Code, Cursor, Codex and GitHub Copilot that automate deploying and debugging Ray workloads, which is a fair signal of where the company thinks developer workflow is heading.

If you are choosing infrastructure from scratch and Ray is not already in your stack, Anyscale is the wrong place to start — pick the framework first, on its merits, and revisit the platform later. If Ray is in your stack and one person runs KubeRay for one team, self-hosting is cheaper and you should keep doing it.

The inflection point is contention and scale: several teams sharing clusters, training runs long enough that a preempted node costs real money, serving workloads that need zero-downtime rollout, or an organisation that needs quotas, budgets and audit logs across all of it. That is the band where the Anyscale Runtime's fault tolerance and the platform's governance features stop being conveniences and start being the reason jobs finish. Below it, you are paying for capabilities you will not exercise.