The model provider behind my AI agent decided to stop supporting the platform I run it on. Everything stopped.
Not "some things." Everything. The main chat session. The 14 scheduled cron jobs. The sub-agents I'd spawn for coding and research. All of it ran through one provider, one API key, one set of models.
When the provider withdrew platform support, the entire system structure was at risk of going dark.
The setup
I run OpenClaw as my persistent AI agent. It handles research, content drafting, code reviews, scheduled checks, and a bunch of automation tasks. Over the past month, I'd built up a pretty sophisticated system: 14 cron jobs running at various intervals, a brain-as-router architecture where a central model delegates tasks to specialized sub-agents, and a workspace full of memory files that give the agent continuity between sessions.
All of it pointed at one provider.
I knew this was a risk. I even had "design for provider independence" on my to-do list. But the system worked so well that the migration kept getting pushed to "next week." Classic.
The moment of truth
When the provider dropped support, I had a 3-day window to migrate. The actual switchover took an afternoon. Not because I'm fast, but because the architecture was already right.
Here's what I mean. OpenClaw separates the model from the system. Models are configured in openclaw.json. Cron jobs specify which model to use as a parameter. Sub-agents accept a model argument when you spawn them. The prompts, memory files, workflow definitions, and tool configurations don't care which model runs them.
So the migration was mostly: change the model name in OpenClaw's config, update the cron payloads, restart the gateway. Done.
The panic wasn't about the migration itself. It was about not having tested it before I needed it.
What actually breaks
When you switch providers, the obvious thing changes: the model. But there are subtle things that can trip you up.
Thinking modes work differently. One provider might use "extended thinking" as a separate visible stream. Another might handle reasoning internally. Your agent's behavior can shift even if the prompts are identical, because the model interprets instructions through different training.
Tool calling conventions vary. The way models structure function calls, handle errors, and report results isn't standardized. An agent that works perfectly on one model might fumble tool calls on another. I found this out when my first sub-agent on the new provider hung for 21 minutes after a connection drop. The old provider would have retried gracefully. The new one just... stopped.
Rate limits and pricing flip your cost model. Moving from an unlimited subscription to pay-per-token changes everything about how you think about model selection. Suddenly, routing a simple formatting task to your most expensive model feels wasteful. You start caring about which tasks actually need the premium model and which can run on something cheaper.
Context window sizes differ. Going from 200K tokens to 1M tokens sounds like pure upside, but it changes when compaction triggers, how much history the model sees, and how your memory management works. More isn't always better if your compaction strategy was tuned for a smaller window.
The architecture that saved me
Three design decisions made the migration possible in an afternoon instead of a week.
1. Models as configuration, not code.
In OpenClaw, the default model appears once in openclaw.json. Everything else references it indirectly. When I changed the primary model, every session, cron job, and sub-agent picked it up on the next run.
// openclaw.json
{
"agents": {
"defaults": {
"model": "google/gemini-2.5-pro",
"thinking": "low"
}
}
}
One line. Update the previous provider to google/gemini-2.5-pro, restart the gateway, and every session picks up the new default. No grep-and-replace across 20 files.
If your model is hardcoded in prompt templates, scattered across cron definitions, or baked into deployment scripts, you're going to have a bad time.
2. Fallback chains.
OpenClaw lets you configure a primary model and a list of fallbacks. If the primary fails (rate limit, outage, authentication error), the system automatically tries the next one.
// openclaw.json
{
"agents": {
"defaults": {
"model": "google/gemini-2.5-pro",
"fallbackModels": [
"google/gemini-3.1-pro-preview",
"google/gemini-2.5-flash",
]
}
}
}
The primary handles normal requests. If it hits a rate limit or returns an error, OpenClaw tries the next model in the chain automatically. Notice the last entry: you can keep your previous provider at the end of the fallback list as a last resort while you still have access.
This isn't just for migrations. It handles everyday reliability too. Provider APIs go down. Rate limits get hit. Having a fallback chain means your agent keeps working.
3. Task-based routing.
Not every task needs your best model. I ended up with three tiers:
- A stable, mid-range model as the "brain" that handles conversation and routing decisions
- A high-capability model for coding tasks and complex analysis
- A cheap, fast model for notifications, formatting, and simple generation
The brain decides which tier a task needs, then spawns a sub-agent on the appropriate model. In OpenClaw, cron jobs and sub-agents accept a model parameter directly:
// Cron job — runs on the cheap model
{
"label": "morning-news",
"schedule": "0 9 * * *",
"model": "google/gemini-2.5-flash",
"thinking": "off",
"task": "Deliver today's top 5 news items"
}
// Cron job — runs on the expensive model
{
"label": "weekly-review",
"schedule": "0 18 * * 5",
"model": "google/gemini-2.5-pro",
"thinking": "medium",
"task": "Run the weekly strategic review"
}
Each task declares which model it needs. Swap any tier without touching the others. During my migration, I reclassified all 14 cron jobs and discovered that 10 of them only needed the cheapest model. That alone cut my projected costs by about 60%.
What I'd do differently
If I could go back, I'd do three things from day one.
Test failover before you need it. Once a month, temporarily switch your primary model to the fallback and run your system for a few hours. You'll find the subtle incompatibilities while you still have time to fix them.
Keep a migration checklist. Not a plan. A checklist. The kind of thing you can execute under pressure when your provider announces a breaking change. Mine has 15 items. I wish I'd written it before the clock was ticking.
Track which models your cron jobs actually need. Audit this quarterly. You'll almost certainly find tasks running on expensive models that could run on cheaper ones.
The real lesson
Provider independence isn't about distrust. I liked my old provider. The models were great. The developer experience was smooth. But companies change pricing, drop platform support, shift strategy, or just have bad days where the API goes down for hours.
Your prompts, your context files, your workflow definitions, your memory system. Those are your real assets. The model is the most replaceable part of the stack. Build like it is.
The migration forced me to see my system clearly. And honestly, it's better now. Multiple models, each doing what they're best at, with automatic failover if any single one goes down. That's not a compromise. It's an upgrade.
If you're running an AI agent today and everything works great on one provider, that's wonderful. Now go test what happens when it doesn't.
This is part 1 of a series on model migration and multi-model architecture. Next up: how to set up task-based routing so different models handle different types of work.
Have you gone through a provider migration? What surprised you? I'd genuinely like to hear, especially if you found gotchas I haven't hit yet.
Top comments (0)