Tell HN: Our paid Claude AI subscription unavailable >1 week and no s...

A paid Claude AI subscription stayed unavailable for more than a week while support failed to provide a resolution. That is not a routine outage. For a developer or team paying for access, seven days is long enough to miss a release, block an evaluation, or discover that an “AI workflow” is really a single-provider dependency with no recovery path.

The incident surfaced as a customer escalation rather than a formal product announcement. The confirmed scope is narrow: a paid subscription was inaccessible for over a week, and the customer could not obtain effective support. It does not establish a platform-wide Claude outage, a general account suspension campaign, or an API availability incident. That distinction matters, but it does not make the failure unimportant.

In practice, account-level failures can be harder to manage than global outages. A public outage has status updates and engineering attention. An isolated entitlement, billing, or identity problem may leave the service technically healthy while one customer remains completely locked out.

What actually failed

“Claude is unavailable” can describe several different failures:

• A consumer or team subscription cannot open the Claude application.
• The account can sign in, but paid entitlements are missing.
• A workspace is disabled while individual accounts still work.
• API keys fail even though the subscription product remains accessible.
• Billing succeeds, but authorization state does not update.
• Automated abuse controls restrict an account and provide no usable appeal path.

The public complaint establishes the first-order outcome—paid access unavailable for more than a week—but not the internal cause. It would be speculation to label this a billing bug, automated suspension, policy action, or identity-provider problem without more evidence.

The operational symptom is still clear: payment did not produce dependable access, and support did not restore it within a reasonable engineering timescale.

A common gotcha is assuming a Claude subscription and Claude API account are the same service boundary. They may share branding and identity details, but interactive plans, team workspaces, API organizations, credits, keys, limits, and support channels can have different control planes. Buying a chat subscription does not automatically create API redundancy. Likewise, a working API key does not guarantee access to the hosted chat interface.

That separation should be documented in every team’s runbook.

Why one account incident matters to API developers

Developers tend to model provider risk as latency, rate limits, or HTTP 500 errors. Account availability is another failure domain:

application
  ├── model endpoint
  ├── API credential
  ├── billing account
  ├── provider organization
  ├── administrator identity
  ├── policy/abuse review
  └── support escalation

The model endpoint can be healthy while any one of the other layers prevents requests.

This is especially painful during development because teams often mix human and machine workflows. An engineer uses a paid chat subscription to inspect prompts, summarize traces, and build test cases, while production uses API credentials. Losing the interactive account may not take production offline, but it can cripple debugging and incident response. If the same identity owns the API organization, the blast radius can become much larger.

In practice, support latency is part of availability even if it never appears in an SLA. An account that could theoretically be restored but remains unusable for eight days has eight days of effective downtime.

For a five-person team, the direct subscription cost is usually the least important number. Consider an illustrative calculation:

5 developers × 2 blocked hours/day × 7 days = 70 engineering hours

70 hours × $90/hour loaded cost = $6,300

Even if only 20% of those hours are truly lost rather than redirected:

$6,300 × 0.20 = $1,260 effective disruption cost

That is why “we can request a refund” is not an adequate resilience strategy.

The current model choice does not solve account risk

Teams now have a broad set of current model options: Claude gpt-5.6-sol, Sonnet 4.6, Haiku 4.5, Fable 5 with a 1-million-token context window, GPT-5.5, and Gemini 3. The useful comparison is not merely which model gives the nicest answer. It is which operational dependency each choice introduces.

Only Fable 5’s 1M context is treated here as a supplied numeric specification. I would not invent context limits, benchmark scores, or token prices for the other models. Those details change, can vary by access tier, and must be checked against the account actually serving production.

The deeper lesson is that three Claude-family model routes are not necessarily three independent fallbacks. If they share the same organization, billing relationship, credentials, gateway, or enforcement system, one account problem can remove all three.

GPT-5.5 and Gemini 3 provide stronger provider diversification, but switching is not free. System prompts behave differently. Tool-call payloads differ. Safety refusals vary. Tokenization changes cost and truncation behavior. A fallback that has never processed a production-shaped request is only an item in a configuration file, not a recovery mechanism.

Build a fallback that can actually run

The smallest useful design separates application requests from provider-specific clients:

from dataclasses import dataclass
from typing import Callable

@dataclass
class Route:
    name: str
    invoke: Callable[[str], str]

def generate(prompt: str, routes: list[Route]) -> str:
    errors = []

    for route in routes:
        try:
            return route.invoke(prompt)
        except (TimeoutError, PermissionError, ConnectionError) as exc:
            errors.append(f"{route.name}: {type(exc).__name__}")

    raise RuntimeError("All model routes failed: " + "; ".join(errors))

Production code needs more care. Do not fail over blindly on every exception: retrying a rejected safety request against multiple providers can violate policy, and replaying a tool call may duplicate side effects. Restrict automatic failover to classified failures such as timeouts, exhausted quotas, unavailable endpoints, or authorization incidents covered by your runbook.

Use a provider-neutral request envelope:

{
  "request_id": "req_8f31",
  "task": "summarize_support_case",
  "messages": [
    {
      "role": "user",
      "content": "Summarize the timeline and unresolved actions."
    }
  ],
  "max_output_tokens": 800,
  "requires_tools": false,
  "data_class": "internal"
}

Then translate that envelope inside each adapter. Keep provider-specific features optional rather than leaking them into every call site.

For sensitive workloads, fallback eligibility must also account for data residency, retention, contractual terms, and approved regions. Availability does not override governance.

Test the economics before an incident

Suppose a workflow handles 40 million input tokens and 8 million output tokens per month. If your internally verified blended rates were $3 per million input tokens and $12 per million output tokens, the arithmetic would be:

Input:  40 × $3  = $120
Output:  8 × $12 =  $96
Total:             $216/month

Those figures are illustrative, not prices for any named model. Replace them with current rates from your provider account, including caching, batch discounts, gateway fees, and regional differences.

Now price resilience. If a second route costs 30% more but receives only a 1% continuous canary:

$216 × 1% × 1.30 = $2.81/month

Real usage will not distribute perfectly, but the principle holds: continuously exercising a fallback is often cheap compared with discovering during an outage that its credentials expired six months ago.

A multi-model gateway can simplify this. AI Prime Tech is one option for cheaper Claude and multi-model API access, particularly when centralized billing and provider routing reduce integration work. It should still be treated as a dependency: determine whether routes have independent upstream accounts, what happens when the gateway itself fails, and how quickly direct credentials can be activated.

A practical account-resilience checklist

Before deployment

1. Create production API organizations separately from personal chat accounts.
2. Assign at least two administrators using independently controlled identities.
3. Store recovery codes and billing ownership details in an approved secrets system.
4. Maintain direct status checks for credentials, quotas, and a minimal model request.
5. Implement one same-provider fallback and one genuinely cross-provider fallback.
6. Test prompts, JSON schemas, tool calls, truncation, and refusal behavior on every route.
7. Keep a support packet ready with organization ID, request IDs, timestamps, invoices, and sanitized errors.

When access disappears

Start by classifying the boundary:

# Confirm that the credential exists without printing it.
test -n "$MODEL_API_KEY" && echo "key present" || echo "key missing"

# Record UTC time for correlation with provider logs.
date -u +"%Y-%m-%dT%H:%M:%SZ"

Then check, in order:

• Is the failure limited to the chat subscription?
• Can another workspace administrator sign in?
• Do API calls fail with authentication, authorization, quota, or server errors?
• Was billing charged, declined, or moved to another organization?
• Are production keys owned by the affected identity?
• Can the tested cross-provider route satisfy the workload safely?

Capture exact error messages and request IDs, but never paste API keys, full prompts, or customer data into a public escalation.

Practical takeaways

• Treat this as a credible account-level availability warning, not proof of a Claude-wide outage.
• Separate subscriptions, API organizations, billing ownership, and production identities.
• Include support responsiveness in operational risk; theoretical uptime does not restore a locked account.
• Do not mistake multiple models under one provider account for independent redundancy.
• Exercise GPT-5.5, Gemini 3, or another approved cross-provider route with continuous canary traffic.
• Validate current pricing, context limits, tool behavior, and account eligibility instead of relying on model-name comparisons.
• Measure the cost of blocked engineering time, not only refunded subscription fees.
• Build and rehearse the fallback before the next account problem. Seven days is too long to begin designing one.