Most teams that adopt AI inside Odoo start by wiring a single provider into a single flow — a lead summary here, a product description generator there. It works until it doesn't: the one provider has an outage, its price changes, its data-residency terms don't fit a regulated customer, or a heavy batch job (bulk translation, invoice OCR, thousands of description rewrites) makes a frontier model prohibitively expensive for what is essentially routine work. Odoo core has no notion of an AI provider at all, and a typical off-the-shelf apps.odoo.com module hard-codes exactly one vendor and one API shape, so the moment you need a second option you are back to writing glue code. There is no native place in Odoo to say "use the cheap model for bulk classification, the strong model for customer-facing drafts, and our own on-prem endpoint for anything touching regulated data."

This is what we build for you. The AI Provider Pool is a first-class Odoo application that introduces a configurable ai.provider model and a routing layer sitting behind a single internal service. Each provider record carries its own endpoint URL, credentials (stored via Odoo's config parameters / encrypted fields, never in plain XML), model identifiers, token limits, and cost weighting. A ai.provider.pool defines routing policy — round-robin, priority-with-failover, or per-task pinning — resolved by an ORM service method (compute/@api.depends driven where usage stats are aggregated) that any other module can call. Because every provider speaks to us through one normalized adapter interface, a hosted frontier model, a cost-efficient hosted alternative, and a self-hosted OpenAI-compatible endpoint (your own vLLM/Ollama/text-generation-inference server behind your firewall) are interchangeable at the policy level. Calls, latency, token counts and estimated cost are logged to an ai.request.log model so you get real QWeb/list reporting on spend and reliability per provider.

Technically, the module ships as a clean addon: __manifest__.py declaring dependencies and data files, models under models/ with proper field types and computed usage rollups, security defined in ir.model.access.csv plus record rules so only the right groups can read credentials or see the request log, OWL/XML settings views under Settings, and automated actions (or scheduled ir.cron) for tasks like async batch processing and daily failover health checks. It exposes its routing service both to server-side Python (so your other custom flows can request env['ai.pool'].generate(...)) and, where you need it, over the JSON-RPC/XML-RPC API so external systems can borrow the same governed pool. It is built and tested against Odoo 17.0, 18.0 and 19.0, and works on both Community and Enterprise (Enterprise-only widgets are used only where you already run Enterprise).

Because this is made to order, nothing is downloaded today. After a short scoping call we confirm which providers you want in the pool, your routing rules, whether a self-hosted endpoint is in scope, and which Odoo flows should consume the service. We then build your version, test it on a staging clone of your database, run UAT with you, and deploy with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); the number of providers integrated, self-hosted endpoint setup, multi-company routing rules, and how deeply it is wired into your existing custom flows increase the quoted scope. You receive a fixed quote after the scoping call — the from-price is a starting point, not a firm figure.