Cloud Run just stopped pretending every serverless workload is short-lived. The new Cloud Run instances (Preview) model gives you persistent, individually addressable runtimes — and Google published a working price example: continuously running 1 vCPU + 1 GiB for 30 days at $5.70. That’s not a curiosity; it’s a signal that serverless is being asked to host stateful, interactive, agent-style workloads without forcing you back into VM ops.
This matters because it changes the trade-offs teams make. Until now, Cloud Run’s economics pushed you toward ephemeral request/response patterns or expensive tricks (warmers, global caches) to keep interactive latency low. A $5.70/mo baseline for a tiny, addressable instance makes it realistic to own long-lived processes — think interactive assistants, persistent model runtimes, or single-tenant connectors — with serverless-style management and deployment. But "realistic" doesn't mean "simple."
Why the new middle ground will bite teams who don't adapt
Persistent runtimes introduce the usual VM issues under a serverless API: lifecycle and identity, patching, secrets rotation, resource accounting, and network access controls. They also create a new attack surface: an individually addressable runtime means you need instance-level identity and audit instead of relying on request-level tracing alone. If you treat these instances as ephemeral functions and skip lifecycle policies, you'll accumulate drift and blind spots fast.
Google’s release notes also flagged related items: GKE 1.35.x is rolling out as the default for new clusters in many regions, and other notes call out new metering for session-backed agent workloads and memory-resident session state. That’s the crucial accounting change: agents that keep session context or materialized memory can be metered for compute differently than short RPCs, and Cloud Run instances are a natural home for that kind of stateful agent.
Don’t think of Cloud Run instances as a cheaper VM; think of them as a new primitive with serverless ergonomics and VM responsibilities. You’ll need:
- Per-instance identity and rotation strategies (IAM bindings, Workload Identity) sooner rather than later.
- Operational playbooks for instance crash recovery, graceful shutdown, and state persistence.
- Billing dashboards that surface continuous vs. request-based costs and any session/memory-backed agent charges.
An updated Gemini Live pushes production use
Google also declared an updated Gemini Live product with Live Avatar generally available in late September 2026. Pair that with persistent runtimes and you see the obvious product fit: low-latency, interactive multimodal sessions hosted in addressable runtimes backed by metered session state. This combination encourages teams to move from ephemeral containers to persistent serverless instances, and explains why Google called out agent/session metering now. If you're building interactive agents, read this as a clearer plug-and-play path for production agent hosting — and a reminder that memory and session residency will be charged differently.
GPU economics and commitments
A pricing footnote worth watching: Google’s committed-use and discount programs have expanded to cover additional GPU families (including newer L4-class and high-end RTX-class accelerators), and those commitments can apply across supported workloads in GKE and compatible serverless offerings. That lets you amortize GPU-backed inference across Kubernetes and serverless runtimes if your persistent Cloud Run instances run GPU-accelerated model runtimes.
Final take
Cloud Run instances close a gap that’s been annoying platform teams for years. This is the right move: teams needed a managed, addressable runtime without the ops tax of VMs. But the convenience is deceptive — you now have durable state, instance identity, session metering, and the associated security surface to manage. If you’re deploying interactive agents or persistent connectors, budget engineering time to get lifecycle, telemetry, and billing right before those $5.70 instances multiply into an operational problem.
If you want reading that connects the dots on long-running agents and cost, see the platform ops discussion on long-running sessions in OpenAI Agents API public-beta and reported million-token GPT models — platform ops for long-running sessions and the cost/control perspective in Azure: The Economics of Agent Optimization (Sept 22, 2026) — AI agent governance and cost controls.
Prediction: within 12 months we’ll see a wave of managed tooling for instance-level identity, “instance pools” autoscaling policies, and serverless-friendly patching. If you treat Cloud Run instances like ephemeral functions, you’ll regret it.