LLMTornado

LlmTornado sits in the abstraction-layer category, and the case for that category is strongest when you have more than one model vendor and more than one person writing the integration code. The documentation is unusually concrete about what the abstraction buys you: a single TornadoApi constructor that takes an array of ProviderAuthentication entries, a chat request object whose Model field is the only thing that changes between vendors, and a Conversation object that carries message history so you are not hand-rolling a message list for each provider. The Ollama example is the tell — a library that lets you swap a hosted model for a model on localhost by changing the constructor is doing real work, not just renaming HTTP calls. The add-on packages are where the proprietary surface lives. LlmTornado.Agents provides an agent framework with function tools, response tools, MCP tools, persistent conversation and guardrails. LlmTornado.Mcp implements Model Context Protocol for standardized tool communication. LlmTornado.VectorDatabases plus the ChromaDB connector gives you retrieval without pulling in a second ecosystem. The sidebar also documents per-provider specifics, structured output, embeddings, images, audio, vision, files, moderation, reranking and thread management — a breadth of modality coverage that a thin chat wrapper would not bother with. Where it does not fit: this is a .NET-only library, so Python and TypeScript teams get nothing from it. Multi-provider abstraction also imposes a lowest-common-denominator risk — vendor-specific features that no other provider has are the hardest to expose through a unified API, and the docs suggest the abstraction is deliberately conservative. Teams doing a single integration with a single vendor are paying a learning cost for flexibility they will never exercise. Everything else — pricing tiers, free allowances, release cadence, the full integration list, on-premise terms — was not reachable in this research pass and I am not going to guess at it.