DEV Community

correctover
correctover

Posted on

Your Failover Is Lying to You: Why Switching Verifying

#ai #reliability #llm #failover

Your Failover Is Lying to You: Why Switching ≠ Verifying

You set up failover for your LLM API. Provider A goes down, it switches to Provider B. Problem solved, right?

Wrong.

Here's what actually happens in production:

  1. Provider A returns a 500 → Failover switches to B → B returns a truncated response → Your app serves garbage to users
  2. Provider A rate-limits you → Failover switches to B → B charges 3x more for the same request → Your bill explodes
  3. Provider A returns a response → No error code → Failover stays put → But the response is a hallucinated mess → Your users get wrong answers

Failover switches. It doesn't verify.

The Problem: Failover Only Checks Transport, Not Semantics

Standard failover logic looks like this:

# Typical failover — only checks HTTP status
if response.status_code >= 500:
    switch_to_next_provider()
Enter fullscreen mode Exit fullscreen mode

This catches server crashes. It misses everything else:

  • Truncated responses (200 OK, but incomplete)
  • Schema violations (200 OK, but wrong format)
  • Cost spikes (200 OK, but 10x the price)
  • Drift between providers (200 OK, but semantically different)

A 200 status code is not a contract. It's a suggestion.

Introducing Correctover

Correctover is the correct version of failover.

Because failover switches. Correctover verifies.

It adds a 6-dimension contract validation layer on top of traditional failover:

Dimension What It Checks Example
Status HTTP-level health 5xx, timeouts
Schema Response structure Missing fields, type mismatches
Completeness Response truncation finish_reason !== "stop"
Latency Performance bounds P99 > threshold
Cost Token price anomalies Sudden price spikes
Drift Provider-to-provider variance Same prompt, different semantic output

When any dimension fails, Correctover doesn't just switch — it validates the next provider before committing, ensuring you never fall from one broken provider into another.

How It Works 

from correctover import CorrectoverEngine

engine = CorrectoverEngine.create({
    "providers": [
        {"name": "openai", "api_key": "sk-...", "model": "gpt-4o"},
        {"name": "anthropic", "api_key": "sk-ant-...", "model": "claude-sonnet-4-20250514"},
    ],
    "contract": {
        "max_latency_ms": 5000,
        "require_complete_response": True,
        "schema": {"type": "object", "required": ["answer"]},
        "max_cost_per_1k_tokens": 0.03,
    }
})

result = await engine.chat("Explain quantum computing in 3 sentences")
# Every response passes 6-dimension validation before reaching your app
Enter fullscreen mode Exit fullscreen mode

The Numbers That Matter

  • P50 validation overhead: 22µs — less than one network round-trip
  • 333 fault scenarios across 16 failure categories
  • BYOK direct connection — your keys, your providers, no middleman
  • Zero token markup — we never touch, log, or proxy your API calls

Failover vs. Correctover

Failover Correctover
Detects 5xx errors ✅ ✅
Detects truncated responses ❌ ✅
Detects schema violations ❌ ✅
Detects cost spikes ❌ ✅
Detects provider drift ❌ ✅
Validates before switching ❌ ✅
Adds verification overhead 0ms 22µs (P50)

Failover without verification is a seatbelt that only clicks — it never checks if it's actually buckled.

Get Started 

pip install correctover
Enter fullscreen mode Exit fullscreen mode 
npm install correctover
Enter fullscreen mode Exit fullscreen mode

Correctover — The Correct Version of Failover

Because failover switches. Correctover verifies.

Top comments (0)