One Python interface now covers chat, agents, and MCP
aisuite began with a simple proposition: use an OpenAI-shaped chat API while selecting the provider through a string such as openai:model or anthropic:model. The current README goes further. Plain Python functions can become tools, max_turns can run the tool loop, and a separate Agent and Runner layer adds policies, saved state, artifacts, and tracing. MCP servers can enter the same tool list through an optional package.
That breadth changes the buying decision. This is no longer only a convenience adapter for a weekend model comparison. Our checkout contained 747 files and roughly 115,616 lines of source. An application can depend on aisuite for request translation, streamed chunks, tool schemas, approvals, and conversation state. Each layer saves application code, but it also makes provider differences harder to see when a request goes wrong.
Provider switching works best with a contract test for each model
The chat interface standardizes messages and familiar controls such as temperature, maximum tokens, and tools. Provider extras keep the base package smaller, and adding an adapter follows a documented module and class naming convention. This is useful when a team wants to compare models without rewriting every call site or needs an Ollama option beside hosted APIs.
The common shape does not guarantee common behavior. The README limits documented streaming support to OpenAI, Anthropic, Ollama, and OpenAI-compatible endpoints. Streamed tool calls return fragments that the caller assembles and executes manually, and streaming cannot be combined with max_turns. Those are reasonable boundaries, but they mean a provider swap needs tests for streaming, tool arguments, stop reasons, errors, and any model-specific parameters your product uses.
What happened when we ran it
Our sandbox installed aisuite in 78 seconds, pulling 136 packages and occupying 521 MB on disk. The build completed in 7 seconds. Pip-audit reported 1 known vulnerability in the installed environment. These figures come from commit 531b5b8 in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets.
Tests failed with exit code 1 after 48 seconds. Pytest's final summary was 435 passed, 43 failed, 47 skipped, and 27 warnings in 38.07 seconds. The log tail showed failures across Gemini, Google, OpenAI, streaming, and async tool utilities. Each displayed failure ended with the same plain message: async functions are not natively supported. The log does not tell us why that support was missing, so we cannot fairly label the library's async implementation broken from this run alone.
Repository signals are mixed in a useful way. There were 2 CI workflow files and a dedicated tests directory, but no Dockerfile. The install and build were clean, and hundreds of tests passed. Still, a developer evaluating async clients or streams should reproduce the suite in the intended environment before trusting those paths. Forty-three failures are a result to investigate, even when they share what may be a harness-level message.
Automatic tool loops still expose provider differences
Passing max_turns lets aisuite call a model, execute requested functions, return their results, and continue. The response retains intermediate messages, which is useful for resuming or auditing a run. The Agents API builds on that loop with file, git, and shell toolkits. It also supplies allow and deny lists plus approval policies, controls that matter when model output can trigger code or filesystem actions.
Open issue 369 gives a concrete warning. Its reporter found automatic tool execution failing with Groq because of an unsupported reasoning_content field and with Ollama because tool calls came back empty. The same report says a manual Ollama loop worked. That does not prove every model or current branch behaves the same way, but it does show why the 2-line provider switch needs integration coverage when tools can change files, call services, or run shell commands.
MCP support makes the security boundary wider. A configuration can launch an MCP server with a command and arguments, then let the selected model request those tools. The explicit client supports reusable connections, filtering, and tool prefixes. Those facilities help, but the application owner still decides which executable runs, what directory or service it can reach, and which calls require approval. Installing the MCP extra is the easy part.
Current work is active, while the release record is untidy
GitHub showed 16,178 stars and 147 combined issues and pull requests when we fetched the repository. The last push was August 13, 2026, and an open provider pull request was updated on August 27. That combination indicates current contribution activity; the 147 figure is not a bug count. The MIT license is straightforward for commercial and private use.
The latest-release endpoint returned tag v0.1.3, published July 20, 2026, with the name OpenWorker 0.1.3. Its notes span aisuite provider work and a long set of OpenWorker changes, even though the README says OpenWorker now lives in its own repository. Releases remain usable evidence of activity, but the naming and mixed scope make them a poor guide to which Python-library changes belong to one install. Pin a tested commit or package version rather than reading the release title as a compatibility promise.
Use the abstraction where switching has a measurable payoff
A team comparing several hosted models can get real value from one client, especially when it also needs local Ollama, MCP servers, and approval-aware Python tools. The documentation gives enough code to understand the boundaries, and the provider adapter convention is approachable. The cost is a larger behavior matrix than the unified method signature suggests.
Our 78-second install and 521 MB environment make a trial cheap enough, but the failed async-heavy test run should be resolved in the team's own CI before adoption. For one provider, its official SDK keeps errors and features closer to the source. For several providers, aisuite earns a trial if you are prepared to test the exact models, streams, and tool loops users will depend on.