Elyra · · 4 min read

The Two Things a Single-Vendor Agent Can't Do. Elyra v0.9.16

Two features ship in v0.9.16, and neither is possible for a vendor-locked tool: cross-provider failover, so your agent doesn't die when your provider does, and /review --cross, a second opinion from a genuinely different vendor. Provider-agnosticism as a feature, not a footnote.

The Two Things a Single-Vendor Agent Can't Do. Elyra v0.9.16

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.

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.

Feature 1: Cross-provider failover — your agent doesn't die when your provider does

Why. "A model can disappear overnight" isn't hypothetical. We've watched it happen: a frontier model gets export-control-suspended and starts returning 404: not available; another launches but is region-locked out of the EU. And the boring failures are constant — 503 overloaded, 429 rate limit, an expired key. In a single-vendor agent, every one of those is a dead end. You copy your prompt, wait, or switch tools.

How. When a turn fails because a provider can't serve it, Elyra now retries the same turn on an equivalent model from a different provider you already have keys for — automatically, preserving your conversation.

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)

The mechanics are deliberately careful:

  • It knows what's worth retrying. A 503, 429, 401, or a "model not available" gets a failover. A 400 bad request or a context-overflow does not — those would fail identically everywhere, so Elyra surfaces them instead of burning attempts.

  • It picks a real equivalent. 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.

  • It won't loop forever. Capped at 2 attempts, then it gives up gracefully with the original error.

Don't want it? One setting:

"providerFailover": false   // default is true

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.

Feature 2: /review --cross — a second opinion that's actually a second opinion

Why. 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 vendor, trained differently, with different failure modes.

A single-vendor agent literally cannot offer this. Elyra can.

How. The existing /review got a --cross flag. It reviews your changes with a model from a different vendor than the one you're coding with:

# 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.

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.

Two flavors:

  • /review — quick review with your current model.

  • /review --cross — the independent, different-vendor take, for when the change matters.

The through-line: provider-agnosticism as a feature, not a footnote

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 your repo.

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.

npm install -g @elyracode/coding-agent@0.9.16

failover is on by default; try an independent review:

/review --cross

An honest note

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.