<p>Most coding agents are married to one model provider. That's fine until it isn't — until the provider is overloaded at 4pm, or rate-limits you mid-refactor, or a model you relied on vanishes overnight because of an export-control change. When your agent is welded to one vendor, their bad day is your bad day.</p><p>Elyra isn't welded to anyone. It speaks to dozens of providers through one interface, and v0.9.16 finally cashes in on that. Two features ship here, and neither is possible for a vendor-locked tool. That's the whole point.</p><h2>Feature 1: Cross-provider failover — your agent doesn't die when your provider does</h2><p><strong>Why.</strong> "A model can disappear overnight" isn't hypothetical. We've watched it happen: a frontier model gets export-control-suspended and starts returning <code>404: not available</code>; another launches but is region-locked out of the EU. And the boring failures are constant — <code>503 overloaded</code>, <code>429 rate limit</code>, an expired key. In a single-vendor agent, every one of those is a dead end. You copy your prompt, wait, or switch tools.</p><p><strong>How.</strong> When a turn fails because a provider can't serve it, Elyra now retries the same turn on an equivalent model from a <em>different</em> provider you already have keys for — automatically, preserving your conversation.</p><pre><code class="language-text">You: refactor the auth middleware to use the new token service
…Anthropic returns 529 (overloaded)…
Elyra: (retries the turn on gpt-5.6 via OpenAI, continues seamlessly)
</code></pre><p>The mechanics are deliberately careful:</p><ul><li><p><strong>It knows what's worth retrying.</strong> A <code>503</code>, <code>429</code>, <code>401</code>, or a "model not available" gets a failover. A <code>400 bad request</code> or a context-overflow does <em>not</em> — those would fail identically everywhere, so Elyra surfaces them instead of burning attempts.</p></li><li><p><strong>It picks a real equivalent.</strong> The replacement comes from a different vendor when possible, in the same capability band (it won't quietly downgrade a hard reasoning turn to a cheap model), and — crucially — an image conversation only ever fails over to a vision-capable model. Your multimodal session can't break.</p></li><li><p><strong>It won't loop forever.</strong> Capped at 2 attempts, then it gives up gracefully with the original error.</p></li></ul><p>Don't want it? One setting:</p><pre><code class="language-jsonc">"providerFailover": false   // default is true
</code></pre><p>This is the individual-developer version of what big orgs call "no single-vendor dependency." Your agent routes around outages the way the internet routes around damage.</p><h2>Feature 2: <code>/review --cross</code> — a second opinion that's actually a second opinion</h2><p><strong>Why.</strong> Asking a model to review its own work has a structural flaw: the reviewer shares the author's blind spots. If Claude wrote the code and Claude reviews it, the whole exercise runs through one worldview. A genuinely independent review needs genuinely different eyes — a different <em>vendor</em>, trained differently, with different failure modes.</p><p>A single-vendor agent literally cannot offer this. Elyra can.</p><p><strong>How.</strong> The existing <code>/review</code> got a <code>--cross</code> flag. It reviews your changes with a model from a different vendor than the one you're coding with:</p><pre><code class="language-text"># You're working with Claude Sonnet 5
/review --cross

Code Review — uncommitted changes — independent second opinion from openai
Reviewing with GPT-5.6...
  • The new early-return skips the audit log write on the error path (line 42).
  • `expiresAt` is compared as a string, not a Date — this will pass tests but
    fail in production for tokens issued before noon.
</code></pre><p>That second finding is exactly the kind a same-family reviewer tends to wave through — a different model, with different instincts, catches it. If you only have one provider configured, it transparently falls back to your current model, so the command always works.</p><p>Two flavors:</p><ul><li><p><code>/review</code> — quick review with your current model.</p></li><li><p><code>/review --cross</code> — the independent, different-vendor take, for when the change matters.</p></li></ul><h2>The through-line: provider-agnosticism as a feature, not a footnote</h2><p>Both features come from the same foundation we built once and will keep reusing: a small, tested engine that understands when a model is "equivalent enough" to another and how to pick a diverse set across vendors. Failover uses it to route around trouble; cross-review uses it to find a dissenting voice. Next on that foundation: letting Elyra empirically figure out which model is actually best for <em>your</em> repo.</p><p>The industry sells you a model. Elyra gives you an agent that treats models as interchangeable parts — so no single vendor's outage, price hike, or policy change is your problem.</p><pre><code class="language-text">npm install -g @elyracode/coding-agent@0.9.16
# failover is on by default; try an independent review:
/review --cross
</code></pre><h2>An honest note</h2><p>Failover and cross-review are unit-tested and type-checked, but the truly satisfying demo — Claude handing off to GPT mid-outage, or GPT catching Claude's bug — needs keys from more than one provider to see live. If you've got two providers configured, give them a spin and let us know what the other vendor catches.</p>