Uptime commitment

Gateway monthly uptime of 99.9% or better, per calendar month in Asia/Shanghai — roughly 43 minutes of permitted downtime per month.

Per capability group, 99.5% or better. A capability group depends on upstream providers, so its figure sits below the gateway's own.

This applies to every paid subscription. Free allowances and trials are excluded.

Monthly uptime = (minutes in the month - unavailable minutes) / minutes in the month.

Unavailability is determined by periodic real inference probes issued to every capability group — currently every 15 minutes, from our own origin (we have no multi-region probe nodes yet). Downtime starts at the second consecutive failed probe and ends at the first successful one. Probes consume upstream quota; any change to the interval is noted on the status page.

A probe fails on a 5xx, a connection timeout, or time-to-first-byte over 60 seconds. 4xx does not count — that is the request's problem, not ours.

Probe data is retained 90 days and published on the status page, including every raw record (timestamp, outcome, latency, failure kind) rather than only the rolled-up percentage. It can also be exported by month.

Three parts of this method favour us, and we would rather write them here than let you find them: first, time we did not observe counts as available — so a stretch where probing itself stopped is not counted as downtime; second, if a month's probe coverage falls below 50%, that month gets no uptime figure and no credit, because asserting a whole month from a handful of probes is making numbers up regardless of who it favours; third, probe requests go straight to the upstream provider and do not pass through our own gateway, so what they measure is the upstream link rather than the path you actually call — if the fault is on our side (a bad deploy, an unavailable database, an authentication failure), you get errors while the probe still records success. The first two together mean: if an incident is severe enough to take our probe job down with it, automatic compensation will not fire. Our only hedge is keeping the probes running; yours is the monthly raw-record export, where a gap is visible. If you believe a month should have been credited and was not, contact us with your own call records.

Planned maintenance announced 72 hours ahead, up to 30 minutes cumulative per month.

Failures originating on your side: exceeding quota, an invalid key, malformed requests, your own network.

Force majeure: earthquake, war, large-scale network failure, or a service suspension mandated by a regulator.

Failures arising from your use of a model not offered in your region (see section 4 of the Terms).

Upstream provider failures are not on this list. Upstream downtime counts as our downtime — building redundancy for a capability group is our obligation, not a risk you agreed to carry.

When a model fails, the system automatically switches to a disaster-recovery model of equivalent capability and completes the request. The switch happens before the first byte reaches you, so you never receive half a response.

A successful failover does not count as downtime — the request succeeded. But every switch is recorded in your usage detail, naming the original model and the one actually used, so you can check.

You may turn automatic failover off in the console, or specify the order of fallback models you accept. With it off, a failure of your chosen model counts as downtime against this commitment.

Failover is billed at the substitute model's own multiplier, and where that is higher than the original, we absorb the difference.

Where monthly uptime falls below the committed level we credit bonus balance as a proportion of that month's subscription fee:

99.0% to 99.9%: 10% credited.

95.0% to 99.0%: 30% credited.

Below 95.0%: 100% credited, and you may instead elect a full cash refund and cancellation, free of the general conditions in the Refund Policy.

Remedies in any month are capped at that month's subscription fee. This section is our entire liability for availability and excludes indirect loss.

Automatically. No claim, no evidence, nothing for you to file. At month end the system computes uptime from probe data and credits the account, with an email explaining the calculation.

Credit issued as compensation is valid for 60 calendar days — shorter than the 90-day general default for bonus balance. Sixty days covers two full billing cycles: the credit exists so you can keep using the service, not so you can stockpile it. The exact expiry is in the crediting email and in the balance detail in your console.

This is a deliberate departure. The industry norm is that the customer must submit a written claim with supporting evidence within 30 days of the incident — which places the burden of proof on the party with the least data, and is why most customers never receive credits they are owed. We hold the data, so we should hold the obligation.

If you think a month's figure is wrong, you can pull every raw probe record for that month for up to 90 days — exportable straight from the status page, no need to contact us.

For any incident affecting more than 1% of users we publish a post-mortem within 48 hours — timeline, root cause, blast radius, remediation — signed by the person accountable.

We do not write "third-party service fluctuation". Where the root cause really is upstream we say which dependency, why redundancy did not engage, and what we are changing.

Every past post-mortem stays published. We do not take them down.