Skip to main content
Auto mode picks a provider for you: LiteLLM first (100+ providers), OpenAI as a safety net. The user describes a task in auto mode; the generator picks LiteLLM or falls back to OpenAI and writes the resulting agents YAML.

Quick Start

1

Default (OpenAI only)

Install PraisonAI and set your OpenAI key:
Run auto mode:
Or programmatically:
2

Unlock 100+ Providers with LiteLLM

Install LiteLLM to use Anthropic, Google, Azure, Bedrock, Ollama, and more:
Switch to Anthropic Claude:
Switch to Google Gemini:
Switch to a local Ollama model:
3

Programmatic Use (Sync & Async)

Both sync and async paths honour the LiteLLM → OpenAI fallback:
Async version:
4

Calling from an existing event loop (FastAPI, Jupyter)

AutoGenerator.generate() can now be called from inside a running event loop — it offloads to a worker thread automatically instead of raising RuntimeError: This event loop is already running.
Prefer await generator.agenerate() when you are already in an async context — it avoids the thread-offload overhead. The sync .generate() form is provided as a safe fallback.

Tool inventory in --auto

praisonai --auto shows the planner a live list of installed tools, sourced from the canonical ToolResolver. What the planner sees always matches what your agents can actually call at run time — no drift. If the resolver is unavailable (e.g. praisonai_tools and praisonaiagents.tools both fail to import), the planner falls back to a frozen list so --auto still produces a working plan. One warm resolver cache per run. The AutoGenerator planning step and the downstream AgentsGenerator execution step share the same context-local resolver — installed-tool discovery only runs once per --auto invocation.
The list the planner sees is not the same as the list of tools you can attach to an Agent in Python — the resolver knows about many more than the frozen legacy list. If you added a tool but --auto doesn’t pick it up, check that it appears in praisonai tools list.

How It Works

The OpenAI fallback runs through the core-owned praisonaiagents.llm.openai_client.OpenAIClient, which uses beta.chat.completions.parse under the hood. This means the fallback automatically picks up SDK-level features like OPENAI_MAX_RETRIES — see OpenAI Client Retries.
The fallback warning message is: LiteLLM structured completion failed (...); falling back to OpenAI SDK. Watch your logs for this — it means LiteLLM is degrading silently.

Which Provider Should I Use?


Install Matrix


Configuration

Auto Module SDK Reference

Full API reference for AutoGenerator, WorkflowAutoGenerator, and BaseAutoGenerator

Common Patterns

Switch from OpenAI to Anthropic:
Run against a local Ollama model (no cloud keys needed):
Belt-and-braces production setup (LiteLLM + OpenAI fallback):
Async programmatic use:

Best Practices

Install both packages so transient LiteLLM failures (rate limits, network blips, provider outages) don’t break agent generation:
LiteLLM runs first; OpenAI silently catches any runtime errors.
The warning LiteLLM structured completion failed (...); falling back to OpenAI SDK. means LiteLLM silently degraded. Check:
  • Is your provider API key set correctly?
  • Does the model support response_format (structured output)?
  • Is the provider having an outage?
Investigate before relying on the fallback long-term.
If your code runs multiple AutoGenerator instances in parallel, set model names in config_list rather than OPENAI_MODEL_NAME to avoid environment variable races:
Lazy loading is on by default — litellm is never imported at module load time. Do not add import litellm at the top of your files. Let AutoGenerator pull it in on demand. This keeps startup fast and avoids import-time side effects.

Auto Mode CLI

Command-line reference for praisonai --auto

AutoAgents

Automatically create and run agents from a prompt

Structured Output

Control agent output format with Pydantic models

YAML Workflows

The agents.yaml format generated by auto mode

Turn on SDK-level retries for the OpenAI fallback path