Build interactive video avatars with a no-code interface, APIs and configurable voices, models and knowledge sources.
Anam.ai creates interactive video avatars for conversations inside applications and websites. Its avatar models animate a character as an AI agent speaks, adding a visual interface to a text or voice assistant. Teams can build an experience through the no-code platform or integrate it into a product through the API.
Users can choose an avatar from the library or create one from an uploaded image. The platform supports different visual styles and configurable voices. Its CARA model family produces the avatar animation, while the connected language model and application configuration determine what the agent says and does.
Knowledge retrieval and tool calling allow an avatar to refer to configured information or invoke external actions. This means the experience can extend beyond a talking presentation to a two-way conversation connected to a specific service. Typical applications include customer support, sales assistance and interactive training.
Anam provides JavaScript and Python tooling, with integration paths for LiveKit and Pipecat. Developers can control sessions, choose input devices and configure aspects of the interaction. The platform also supports model version selection and LLM connections, giving an implementation team control over both the visual and reasoning parts of an experience.
The free plan includes monthly minutes and API access, with limits on conversation length, simultaneous sessions and available avatars. Paid plans increase allowances and can charge for usage beyond included minutes. A minute is based on the duration of an active session, including periods when the user is not speaking, and unused allowances do not roll over.
Commercial usage is listed on paid tiers beginning with Starter. Teams should choose a plan using their expected session duration and concurrency, then test the avatar with the actual knowledge and tools it will use before making it available to end users.
The embedded route suits a team that wants an avatar within an existing web experience, while the SDK route gives developers control over how sessions fit into application logic. The same distinction affects testing: a team can first validate the character and knowledge in the platform, then test microphone handling, session endings and connected actions in the finished interface. Plan limits should be considered during that integration, particularly when several users may start conversations at once.