Vercel Functions WebSocket Now Generally Available: 15 Million Daily Active Connections

Vercel Functions' WebSocket support is now GA, with 15 million daily active connections and Active CPU billing.
Vercel has announced the general availability (GA) of WebSocket support for its Functions, letting developers build real-time applications requiring persistent connections directly on the platform. Since the public beta in late June, the Vercel CDN has handled a cumulative 300 million WebSocket connections and currently sustains 15 million per day, proving it has passed the test of scaled production workloads. Typical use cases include AI chat, streaming, and real-time multiplayer apps, and Vercel's own AI Gateway real-time models are built on WebSocket. Billing follows Function invocation rules; under the Active CPU model, charges apply only when messages are actually processed, and idle heartbeats consume no CPU, lowering the cost barrier for persistent connection apps. Native support also reduces reliance on third-party services like Pusher and Ably, simplifying real-time application architectures.
Vercel has announced the general availability (GA) of WebSocket support for its Functions, meaning developers can build real-time applications requiring persistent connections directly on the Vercel platform—no more detouring through third-party services or self-hosted infrastructure.

From Public Beta to GA: The Numbers Speak
WebSocket support didn't happen overnight. According to Vercel's official blog, since the feature entered public beta in late June, the Vercel CDN has handled a cumulative 300 million WebSocket connections and currently sustains 15 million connections per day. These figures reflect real production workloads, not lab benchmarks.
For a real-time communication capability on an edge computing platform, 15 million daily active connections is a milestone worth noting. It shows that Vercel's WebSocket implementation has passed the test of scale and is robust enough to support applications with demanding latency and stability requirements.
The difference between WebSocket and HTTP polling: WebSocket is a protocol that provides full-duplex communication over a single TCP connection. The client and server establish a persistent connection with just one handshake, after which either side can send data at any time. In contrast, traditional HTTP polling requires the client to repeatedly send requests to "ask" whether there's new data, with each request carrying full header information—a significant overhead in scenarios with high message frequency or low latency requirements. WebSocket eliminates repeated handshakes and header transmission, making it better suited for low-latency bidirectional communication scenarios such as streaming token delivery in AI chat and state synchronization in real-time collaboration.
Who Uses WebSocket? Three Typical Scenarios
In its announcement, Vercel clearly listed the primary ways customers use WebSocket:
- AI chat: Large model conversations require streaming token delivery, and WebSocket maintains a persistent connection, avoiding the overhead of frequent polling.
- Streaming: Whether for real-time data push or media streaming, WebSocket's bidirectional communication is more efficient than traditional HTTP requests.
- Real-time multiplayer applications: Collaborative editing, multiplayer games, and similar scenarios depend on low-latency state synchronization, making WebSocket a natural choice.
Notably, Vercel's own AI Gateway real-time models are also built on WebSocket. This is effectively the company validating the feature's reliability with its own product line—if AI Gateway can run stably, the underlying WebSocket infrastructure is mature enough.
Token delivery in streaming: When a large language model generates a response, it produces output token by token. With ordinary HTTP requests, the client either waits for the complete response or polls frequently. WebSocket allows the server to push each token to the client the moment it's generated, achieving a "typewriter" character-by-character display effect while keeping the same connection for subsequent multi-turn conversations, avoiding the overhead of repeatedly establishing connections. This is the technical reason Vercel lists AI chat as its primary typical scenario.
Billing Logic: Pay Only for the Time You Spend Processing Messages
For developers, cost is always a key consideration. Vercel explicitly states that WebSocket connections follow the same limits and pricing rules as other Function invocations.
More specifically, under the Active CPU pricing model, CPU is only billed when messages are actually being processed. This means that when a connection is idle and only maintaining heartbeats, no CPU resources are consumed. For scenarios like AI chat—"bursty messages with long waits"—this billing approach is clearly friendlier: you don't pay for idle connection time.
This design also lowers the barrier to real-time applications. In the past, persistent connections often meant continuous resource consumption and unpredictable bills; now, developers can more confidently maintain large numbers of concurrent connections, with costs tied to actual compute load.
The Active CPU pricing model: Vercel's Active CPU billing splits function execution costs into "actual CPU time consumed" and "idle waiting time." Under traditional duration-based billing, a function that maintains a persistent connection but is idle most of the time still accrues billable duration; the Active CPU model charges only for the CPU cycles when code is actually running and processing messages. For workloads like WebSocket—"persistent connections, bursty messages"—this means heartbeat maintenance and time spent waiting for user input don't count toward CPU costs, keeping bills closer to real compute usage.
Practical Impact for Developers
The GA of WebSocket fills the gap in Vercel Functions' real-time communication capabilities. Previously, developers wanting to implement real-time features on Vercel typically had to rely on third-party services like Pusher or Ably, or move persistent connection logic to another platform. Now this capability is natively integrated, allowing architectures to be further simplified.
Of course, GA also means Vercel is making a stability commitment to the feature. For technical teams evaluating real-time backends, this is a signal worth reassessing: if your application already runs on Vercel and needs WebSocket, you can now do it all within the same platform, reducing the complexity of cross-service integration.
Vercel recommends developers start with the official documentation. As demand for AI real-time interaction grows, WebSocket's importance as an underlying transport protocol will only increase—and Vercel clearly wants to secure its place in this trend.
One-line Summary
Vercel Functions' WebSocket support is now generally available, with 15 million daily active connections and Active CPU billing.
Paragraph Summary
Vercel has announced the general availability (GA) of WebSocket support for its Functions, letting developers build real-time applications requiring persistent connections directly on the platform. Since the public beta in late June, the Vercel CDN has handled a cumulative 300 million WebSocket connections and currently sustains 15 million per day, proving it has passed the test of scaled production workloads. Typical use cases include AI chat, streaming, and real-time multiplayer applications, and Vercel's own AI Gateway real-time models are built on WebSocket. Billing follows Function invocation rules; under the Active CPU model, charges apply only when messages are actually processed, and idle heartbeats consume no CPU, lowering the cost barrier for persistent connection applications. Native support also reduces reliance on third-party services like Pusher and Ably, simplifying real-time application architectures.
Related articles

Low-Cost Abstention Strategy: How LLM Ticket Classification Reduces Misrouting Costs
Cost-aware abstention framework cuts ticket routing costs by 38.1%, reduces misrouting from 15.3% to 3.5% on 47,837 IT tickets, outperforming LLMs.

METTA: Memory-Enhanced Meta-Reinforcement Learning for Test-Time Adaptation
METTA proposes dual-timescale memory decomposition for efficient test-time adaptation in meta-RL with linear complexity, exceeding 50% success on Meta-World ML10/45 and outperforming Transformer baselines on PointMaze.

Two Major Numerical Bugs in Softmax and Cross-Entropy and Their Fixes
Standard softmax and cross-entropy have two numerical bugs: Softmax Collapse causes non-zero-sum gradients, and Softmax Cancellation produces spurious gradients in distillation. This article presents fixes and their effects on grokking, accuracy stability, and knowledge distillation.