A streaming avatar platform can support concurrent customer sessions only when it is designed as a session-based real-time system—not simply as a single avatar demo. Look for APIs that create, inspect, and close isolated sessions; server-side authentication; real-time transport credentials; observable lifecycle events; and an enterprise process for capacity planning.
AKOOL Streaming Avatar provides the building blocks for this architecture. Its live avatar APIs create individual sessions, return real-time connection credentials, expose session records, and support explicit session closure. The exact number of simultaneous sessions available to your account should still be confirmed with AKOOL for your plan, regions, avatars, and traffic pattern, then validated with a load test.
Do Not Choose a Platform by One Concurrency Number
A headline limit rarely tells you whether a platform will succeed in production. Ten long customer-service calls behave differently from ten brief product consultations. Text input, microphone audio, selected resolution, voice, language, geography, and session duration can all affect system load and user experience.
Evaluate the complete operating model instead:
- How is each customer session created and authenticated?
- Can your backend list active and historical sessions?
- Can it close abandoned sessions quickly?
- What happens when capacity is reached?
- Which latency, failure, and reconnection signals are available?
- How are regional, language, avatar, and data requirements handled?
Capability 1: An API-Controlled Session Lifecycle
Every customer should receive an isolated session with a clear beginning and end. AKOOL’s Create Session API lets a backend specify the avatar, voice, language, duration, streaming mode, and other session settings. This makes it possible to allocate a session only after your own application authenticates the customer and confirms available capacity.
A platform should also provide a reliable cleanup path. When a browser closes unexpectedly, a customer abandons the conversation, or an application timeout is reached, your backend should close the session and release resources rather than waiting indefinitely.
Capability 2: Backend Orchestration
Do not let thousands of browsers independently manage production credentials. Put a session service between customers and the avatar API. That service can enforce rate limits, assign priorities, choose the correct language or avatar configuration, and reject or queue requests when a safety threshold is reached.
Follow the security guidance in AKOOL’s JavaScript SDK best practices: keep keys on the backend, issue only short-lived session information to the client, and design for token expiration, errors, and reconnection.
Capability 3: Visibility Into Active Sessions
A scalable service needs a source of truth for what is running. AKOOL’s Get Session List API returns session records and statuses that a backend can use for monitoring and reconciliation.
Combine platform status with your own metrics. At minimum, track active sessions, session creation attempts, successful joins, startup latency, conversation duration, disconnect reason, reconnect attempts, and close success. A customer-facing dashboard should distinguish between a model delay, an avatar session failure, and a local network problem.
Capability 4: Real-Time Transport and Client Events
Concurrent sessions depend on more than REST endpoints. The client must join a real-time room, receive media, send microphone or text input, and react to lifecycle events. The AKOOL JavaScript SDK uses real-time communications and provides event-driven controls for the avatar experience.
Your interface should expose connection state instead of leaving a frozen avatar on screen. Add visible states for connecting, listening, thinking, speaking, reconnecting, and unavailable. If real-time video cannot recover, offer text support, a callback, or a human-agent handoff.
Capability 5: Capacity Controls and Backpressure
Even an enterprise platform needs application-level protection. Define a maximum number of new sessions per second and a separate ceiling for active sessions. When demand approaches that threshold, your orchestrator can:
- place low-priority visitors in a short queue;
- route customers to a text experience;
- reserve capacity for authenticated or high-value workflows;
- limit idle time and close abandoned sessions;
- degrade optional visual features before failing the entire conversation.
This is called backpressure. It protects active customers from a sudden traffic spike and makes system behavior predictable.
How to Run a Meaningful Concurrency Test
Start by documenting the real traffic profile: expected peak active sessions, arrival rate, average and maximum duration, target regions, supported languages, and the percentage using microphones. Share that profile with the platform provider so account capacity and test boundaries are explicit.
Then test in stages:
- Single-session baseline: measure startup time, media quality, and full conversational latency.
- Gradual ramp: add sessions steadily and watch for changes in join success or response time.
- Expected peak: hold realistic conversations for a representative duration.
- Short burst: simulate a campaign launch, flight disruption, or product announcement.
- Recovery: disconnect clients, expire tokens, and verify that sessions close and capacity returns.
Use synthetic conversations with controlled content and duration. Do not infer enterprise readiness from many idle browser tabs: an active speaking and listening session is the behavior that matters.
Questions to Ask Any Streaming Avatar Vendor
- Is concurrency limited by account, region, avatar, or project?
- Are limits hard caps, reserved capacity, or burstable quotas?
- Which real-time providers and geographic regions are available?
- How are session status, errors, and usage exposed?
- What load-testing process is permitted?
- What support and escalation path applies during a production incident?
Choose for Operability, Then Prove Capacity
The best platform for concurrent customer sessions is the one your team can operate safely under real traffic. AKOOL documents the session APIs, SDK events, and server-side patterns needed to build that system, while account-specific capacity should be confirmed rather than guessed.
Contact AKOOL with your peak-session forecast and use case, then run a staged capacity test before launch.
