Why connect more than one AI provider?
Chapters 5–9 used OpenRouter as a single starting route. That is enough for many people. This chapter explains when a second, direct provider can add a useful capability or an independent fallback, so you can make a deliberate choice before Chapters 11–13.
Why use more than one provider?
Since Chapter 5, you have used one route: OpenRouter. It already gives you access to models from many developers and is enough for everyday conversation and simple automations. This chapter does not overturn that choice. It explains that using one route more often and for harder work exposes three practical limits, which come from depending on a single route rather than from OpenRouter itself.
Those three limits are:
- Models have different strengths—a model that is good at code may be a poor choice for image analysis, and a fast model may miss details in a difficult planning task.
- Costs vary widely—a quick household question does not need the same model as a consequential purchase or complex automation review. Check live pricing before choosing either one.
- There is no independent fallback—providers and gateways can have outages, rate limits, or account problems. A separately configured direct provider gives you another path.
The key idea is simple: think of your model list as a toolbox, not a contest for one universal winner. Keep OpenRouter as the convenient starting point, then add a direct provider only when it solves a specific problem.
What differs from one model to another?
Provider pages and comparison articles use the terms below. Treat published values as snapshots and confirm current details in the live model catalog.
| Term | Plain-English meaning | Why it matters |
|---|---|---|
| Model parameters | A rough description of model size. Providers do not always publish comparable figures. | Size alone does not prove quality, speed, or suitability. |
| Response speed (tokens per second, tok/s) | How quickly output appears. | Latency matters for short, interactive tasks. |
| Reasoning model | A model designed to spend additional computation on a problem before answering. | It may help on difficult work, but can cost more and take longer. |
| Context window | The maximum amount of input and conversation history the model can process. | A long file or Session can exceed a smaller window. |
| Multimodal | The ability to process inputs such as images or audio as well as text. | You need a compatible model to analyze a photo or screenshot. |
| Language performance | How well the model understands and writes the language you use. | Performance varies by model, language, and subject. |
Three useful model roles
Model catalogs contain many names, but most household work fits three broad roles. One model may fill more than one role.
| Role | Characteristics | Examples | Use it for |
|---|---|---|---|
| Everyday model (fast and affordable) | Low latency and a price you are comfortable using often | Choose a current lower-cost model in the OpenRouter catalog | Short questions, drafts, and low-risk household tasks |
| Reasoning model (deep and slower) | Uses extra computation; often slower and more expensive | Current reasoning models from Anthropic, DeepSeek, GLM, or others | Debugging, planning, and decisions with several constraints |
| Multimodal model (can process images) | Accepts supported images or other media | Choose a currently listed vision-capable model | Appliance labels, screenshots, and floor plans |
These roles can overlap: a reasoning model may also accept images and carry a premium price. Do not assume that a reasoning model never makes mistakes, or that every model from a named family accepts images; confirm capabilities on the exact model page.
Match the model to a household task
Use this table as a decision aid, not as a permanent ranking. Model availability and capabilities change.
| Task | Role | What to select | Why |
|---|---|---|---|
| “What should we cook tonight?” | Everyday | A current low-cost text model | The task is simple and low risk. |
| “Write a sunset automation for the entry light.” | Reasoning or capable general model | A model with reliable coding performance | You must still review and test the YAML. |
| “What model is this appliance?” with a photo | Multimodal | A model whose catalog page lists image input | A text-only model cannot inspect the image. |
| “Should we replace the whole HVAC system?” | Reasoning | A current reasoning model | Many constraints are involved; verify the result with a qualified installer. |
| “Find the error in these 200 log lines.” | Large-context analysis | A model with enough documented context | The complete input must fit in the model window. |
| “Rewrite this article in fluent English.” | Everyday or writing-focused | A model that performs well in English | Language quality matters more than deep reasoning. |
| “Explain this Home Assistant error.” | Reasoning | A model with good technical performance | Ask it to cite the relevant log line or official documentation. |
| “Help me think through an idea.” | Personal preference | The model whose responses you find useful | There is no single objective winner for conversation style. |
The pattern is clear: no provider covers every need perfectly. Start with the OpenRouter route you already configured. Add a direct provider only for a documented feature, independent availability, or separate account controls.
Compare costs without relying on stale prices
Providers usually meter input and output in tokens. A token is not exactly a word, and tokenization differs by language and model. Long prompts, files, tool results, reasoning output, and repeated Session history can all increase usage.
Pricing changes too quickly for a converted local-currency table to remain authoritative. Compare the live provider page using the same workload and the exact model ID:
| Model class | Typical role | Check for input | Check for output | Also verify |
|---|---|---|---|---|
| Small or low-latency model | Everyday work | Current price per token unit | Current price per token unit | Free-tier and rate-limit terms, if any |
| General model | Balanced work | Cached and uncached rates | Standard output rate | Image or tool-call pricing |
| Multimodal model | Image analysis | Image-input calculation | Text-output rate | Supported formats and limits |
| Premium reasoning model | Difficult analysis | Prompt and cache rates | Reasoning and answer rates | Reasoning controls and maximum output |
| Open-weight model through a host | Low-cost or fast work | Host-specific rate | Host-specific rate | Availability and model retirement policy |
The same model family can have different prices and features through different routes. Check the exact model ID and provider before estimating a budget.
A cheap answer is not automatically good value, and an expensive answer is not automatically correct. Match effort to risk, then verify consequential advice independently.
Three risks of relying on one route
“Single point of failure” sounds abstract until it interrupts a real task.
-
The selected model cannot handle the task
A text-only model cannot inspect an image, and every provider applies its own safety and product policies. Without another suitable model or route, the task stops there.
-
Every task uses an unnecessarily expensive model
If one premium model is your only choice, routine questions can consume a budget intended for difficult work. Keep a lower-cost option available and monitor actual usage.
-
The route is unavailable
A gateway or direct provider can experience an outage, rate limit, or account issue. A separately configured route may let you continue, but it is not a guarantee of availability. Check official status pages such as
status.anthropic.comorstatus.openai.comwhen diagnosing an outage.
Five benefits of multiple providers
An additional provider is useful when it gives you one of these concrete benefits:
- Specialization: Use a lower-cost model for routine work, a reasoning model for difficult analysis, and a multimodal model for images.
- Fallback: Continue through an independent route when the primary route is unavailable or rate-limited.
- Comparison: Compare important answers, while remembering that agreement between models is not proof.
- Account separation: Keep usage and access controls separate for different purposes.
- Better judgment: Learn which model characteristics matter for your own work instead of following a generic ranking.
OpenRouter is an API gateway or aggregator: one key and one endpoint can reach many models. Because this guide starts with OpenRouter, you may already have enough breadth. Use a direct provider as a focused addition when its native API features, terms, or independent route matter to you.
Before you add a direct provider
The workflow resembles Chapters 5–6: create an account and key, enter the documented API mode and endpoint, add an exact current model ID, run Test, and save. Add one direct provider only once you can name the requirement it meets.
| Step | What to verify | Ongoing maintenance |
|---|---|---|
| Create the provider account | Current eligibility and account requirements | Review provider notices |
| Create and copy an API key | Scope and storage location | Rotate or revoke it when needed |
| Add it in the pi-web Models panel | API mode, base URL, and exact model ID, following the pattern in Chapter 6 | Update retired model IDs |
| Give the provider card a clear name | Distinguish direct routes from OpenRouter routes | Keep names understandable |
| Save and select it when needed | Test with a low-risk prompt | Monitor live usage |
For security, remember that provider keys are stored in plaintext—not encrypted at rest—in /data/pi-agent/models.json. Pi Agent uses the selected route's key when sending a request to that route's configured endpoint. Anyone who can read the file can read every key stored there, so protect Home Assistant and host access, verify each base URL, limit key scope where supported, and revoke a key if you suspect exposure. Provider budget controls vary; confirm them in the current dashboard rather than assuming they exist.
Common concerns
-
“I will lose track of several keys.”
The practical answer is simple: name each provider card clearly, such as “OpenRouter — household” or “Anthropic — direct.” Store keys in a password manager and never put the key itself in the display name.
-
“Usage could increase without my noticing.”
Review usage in each provider dashboard and use any current limits or alerts the provider offers. Do not assume Pi Agent automatically enforces a monthly budget. Chapter 12 explains how reasoning can affect usage.
-
“Do I need to understand every API?”
No. Pi Agent handles several API modes for you. Choose the mode and base URL documented for the provider; do not assume every endpoint is OpenAI-compatible.
-
“Does Nabu Casa include these model APIs?”
No. Nabu Casa is Home Assistant's cloud service, and it is not a third-party model provider. Check the current Home Assistant and Nabu Casa documentation for included features; a Pi Agent provider still requires the credentials for that route.
-
“What if I choose the wrong provider?”
Test with a small, low-risk task. If the route does not meet your needs, remove it from Pi Agent and revoke its key in the provider dashboard. Account and payment terms vary, so check them before signing up.
Provider FAQ
Do I need several providers?
Which direct provider should I add first?
Which provider types does Pi Agent support?
Can one provider see another provider's key?
/data/pi-agent/models.json, so anyone who can read that file can read every stored key. Other providers do not receive unrelated keys through this request flow. The main risk is unauthorized access to Home Assistant or the host itself, so secure both and revoke exposed credentials.