What Support Escalation Changes When You Move Provider

A support escalation is not a phone number. It is a package of evidence that a provider’s triage will accept, and almost every field in that package is named differently by the provider you are moving to.

What actually breaks

The visible loss at a migration is the named contact — the account manager who used to answer, the shared channel, the person who knew your workload. That loss is real and there is nothing technical to do about it. The loss that actually costs you an incident is quieter: your runbook tells the on-call engineer to attach three things to the ticket, and after the cutover one of the three no longer exists, one has a different name, and one means something else.

Concretely, a runbook step that reads “paste the value of the x-request-id response header from a failing call” is a step your log pipeline was built to satisfy: somewhere there is an extractor that reads that header off the response and writes it to a structured log field. Point the client at a provider that returns the identifier under a different header name and the extractor writes null. Nobody notices, because nothing errors — the field is optional in your log schema. It is noticed six weeks later, at 03:00, when the ticket comes back asking for a request ID nobody has.

The request identifier is the whole ticket

Provider triage is indexed on the request identifier. Without one, a ticket describing “elevated errors around 14:20 UTC” is a ticket that cannot be looked up, and the first reply will ask for the ID rather than answer the question. So this is the single field worth verifying by hand on the day you cut over.

The shapes differ. Anthropic’s API returns a request-id header on every response, carrying a value like req_018EeWyXxfu5pfWkrYcMdjWG, and repeats the same value as a request_id field inside the JSON body of an error response; the Python and TypeScript SDKs expose it as a _request_id property on the response object, and the other SDKs through a raw-response accessor. Anthropic documents this on its errors and request IDs page. Deployments behind a cloud reseller carry two identifiers rather than one — the cloud’s own request ID, which is what its audit log is indexed on, and the model provider’s, which is what the model provider’s support is indexed on — and a ticket to the wrong party with the wrong ID gets bounced.

The practical consequence is that “request ID” is not one field in your logs. It is a small set: the identifier your own edge assigned, the identifier the gateway or reseller assigned if there is one, and the identifier the model provider assigned. Log all of them under names of your own choosing, and record which provider each belongs to, so that a year later somebody can tell which one to paste into which portal.

Tiers, clocks and who you are allowed to page

Beyond the identifier, three things about escalation are provider policy rather than API surface, and all three are worth re-reading rather than assuming.

• What counts as an incident. Elevated latency is not usually an outage under a provider’s definition; a non-2xx rate above some threshold usually is. If your alerting pages on p99 latency and their definition is availability, you will be escalating something they have no obligation to act on.
• Who may open a severity-1 ticket. Frequently a named list of people, tied to the account rather than to your rota. A migration is the moment to check that the list matches the current on-call rota rather than the people who ran the evaluation two years ago.
• The clock on a service-credit claim. Where credits exist, they are almost always claim-based rather than automatic, with a filing window measured from the incident. Miss the window and the credit is gone regardless of the outage.

The status page is the fourth item and the easiest to get wrong. Most providers publish one, most subscribe-by-email, and most are updated slower than your own monitoring will notice a problem. Treat it as corroboration for a ticket, not as detection; the detection has to be yours. That is what rewriting the synthetic check is for.

Capture evidence at the call site

The durable fix is to stop treating provider-shaped identifiers as something the log pipeline greps out of a response and start treating them as something the client adapter is responsible for producing. Every adapter, for every provider, returns the same envelope:

type CallEvidence = {
  provider: string;        // "provider-a" | "provider-b"
  model: string;           // exactly the string you sent
  providerRequestId: string | null;
  httpStatus: number;
  errorType: string | null;   // provider's own type string, verbatim
  startedAt: string;          // ISO 8601, UTC
  latencyMs: number;
  attempt: number;            // 1-based; retries share a correlationId
  correlationId: string;      // yours, stable across retries
};

Two details in that shape matter more than they look. Keeping errorType as the provider’s own string, unnormalised, means the ticket can quote what the provider actually said rather than your translation of it — and your normalised taxonomy, which the error-recovery branch needs, can be derived from it rather than replacing it. And keeping a correlationId that is stable across retries is what lets you say “this user request produced nine attempts, all of which failed this way” instead of filing nine tickets.

Clauses worth reading before you sign

Support terms are negotiated per customer and change without notice, so what follows is a list of clause types to look for in your own agreement, not a claim about what any provider offers. None of it is legal advice.

• Response-time commitments versus resolution commitments. A first-response target is common; a resolution target is rare. Know which you have before you design a runbook that waits on a fix.
• Severity definitions written by the provider. The severity you assign is a request; the severity they assign drives the clock. Ask which of your realistic failure modes maps to which severity.
• Coverage hours and region. Twenty-four-hour coverage on the top severity and business-hours coverage below it is a normal shape, and business hours are in somebody’s timezone.
• Notice periods for deprecation and for exit. These are what determine whether a model retirement is a planned project or a fire drill. They belong in the same review as deprecation grace-period planning.