VisvoAI Docs
visvoai-ai

visvoai-ai

One interface to any provider's chat model, plus a live model registry

visvoai-ai is the model layer: one call signature to Gemini, Claude, GPT, and every OpenAI-compatible endpoint (Together AI, Groq, OpenRouter, vLLM, LM Studio, llama.cpp servers, or any custom base_url) — and a model registry most provider facades skip entirely: pricing, context window, capabilities, and normalized thinking/reasoning levels, per deployment, kept current by a live models.dev sync instead of hardcoded constants that go stale the day a provider ships a new SKU.

from visvoai.ai import build_chat_model

model = build_chat_model("anthropic:claude-sonnet-4-5", level="high")
for chunk in model.stream("Explain attention in one sentence."):
    print(chunk.content, end="", flush=True)

This is examples/02_choose_and_meter.py running for real — listing real deployments from the registry, then a live call metered afterward:

Every build_chat_model(...) call returns a standard LangChain BaseChatModel.invoke(), .stream(), .astream(), .bind_tools() all work exactly as LangChain users already expect. Nothing here is a competing abstraction over LangChain; it's the plumbing LangChain doesn't provide: provider selection, key resolution, deployment ids, cost, and reasoning normalization.

What's in this section

  • Providers & the model registrybuild_chat_model, the Provider facade classes (Gemini, Anthropic, OpenAI-compatible), the provider:model[@effort] deployment id codec, and how the baked + live models.dev catalog work together.
  • Cost, usage & thinking levelscost_of, usage_from, and the normalized ThinkingLevel scale that maps one vocabulary (low/medium/high) onto Gemini's thinking_budget, Claude's extended-thinking token budget, and OpenAI's reasoning_effort.
  • Grounded search & URL fetchrun_search / fetch_url, native provider-side grounding (Gemini Google Search) instead of a second scraping stack.

Why a registry, not just a client

Every "unified LLM client" on PyPI solves the calling problem — one .invoke() across providers. Almost none solve the choosing problem: which deployment is cheapest for this job, does it support thinking, what's its context window, will this call blow the budget. visvoai-ai treats that as a first-class API (list_deployments, cost_of, usage_from), not an afterthought you bolt on with a spreadsheet of hardcoded prices.

Install with the providers you actually use:

pip install "visvoai-ai[gemini]"      # Google Gemini
pip install "visvoai-ai[anthropic]"   # Anthropic Claude
pip install "visvoai-ai[openai]"      # OpenAI + every OpenAI-compatible endpoint
pip install "visvoai-ai[all]"         # everything

Pairs naturally with visvoai-core for the agent loop, but stands alone — use it anywhere you'd otherwise hand-roll a provider switch statement: a batch script, a Jupyter notebook, a FastAPI endpoint, a LangGraph app that isn't built on visvoai-core at all.

On this page