How much to send
Use your own recent calls and the public status snapshot to decide whether to lower or raise concurrency.
Two views answer this. Your usage rows are your account. The status page and GET https://api.openbroker.gonka.gg/api/status are every customer together. A busy model is not proof that your key caused it, and a quiet card is not proof that your key is valid.
The snapshot refreshes about once a minute. It does not show host addresses.
Reduce
Send fewer calls at once when any of these is true for the model you are calling:
- Your latest rows are HTTP 429, or the message says no host is free or the request budget is exhausted. Read them on the dashboard Recent requests tab, or with GET /v1/usage.
- On the status page, Incoming is well above Served for that model, and the reason breakdown is mostly Over limit and Out of capacity.
- The model card is Elevated errors or High error rate. Those badges are timeouts and other failures that are not capacity. More traffic does not clear them.
429 and capacity refusals are not in the red percentage. A card can say Operational while Served is still far below Incoming. That gap is a reason to slow down. The gap is refused or failed attempts, not work sitting in a queue.
Increase
Raise how many calls you keep in flight only when all of these hold:
- Your own recent calls are mostly HTTP 200.
- The card for that model is Operational.
- Served is close to Incoming.
- Over limit and Out of capacity are a small share of what you see, both on the page and in your own rows.
Add a little, then look again after the next snapshot.
What is not a load signal
| What you see | What it is |
|---|---|
| 401 | A missing, deleted, or mistyped obk- key. |
| 402 | The account is not active, or available balance is 0. |
| 400 | The JSON or the model id. |
| 502 after a few seconds | Often the client gave up while waiting for headers. Raise the timeout before you change concurrency. See Streaming. |
Which statuses to send again is in Retries.
Status API
No API key. This is the same snapshot the page draws:
curl -s https://api.openbroker.gonka.gg/api/statusUse these fields. model_services[].model is a short family id such as minimax, deepseek, or glm.
| Field | Meaning |
|---|---|
model_services[].status | operational, degraded, or outage. Same badges as the cards. |
requests_5m | Incoming calls for that model in the last 5 minutes. |
served_5m | How many of those completed. |
error_rate_5m_pct | The red percentage: failures other than capacity. Above 8 is elevated. Above 25 is a high error rate. The badge uses this 5-minute rate when that window has at least 5 requests. |
error_reasons.totals[].reason | rate_limited is Over limit. no_capacity is Out of capacity. |
error_reasons.totals covers about 24 hours, so an old spike can still dominate the counts. For a decision right now, prefer model_services and your own latest usage rows.
{
"status": "operational",
"model_services": [
{
"model": "minimax",
"label": "MiniMax M2.7",
"status": "operational",
"requests_5m": 120,
"served_5m": 112,
"error_rate_5m_pct": 1.5
}
],
"error_reasons": {
"totals": [
{ "reason": "rate_limited", "label": "Over limit", "count": 40, "pct": 12.5 },
{ "reason": "no_capacity", "label": "Out of capacity", "count": 15, "pct": 4.7 }
]
}
}The numbers above are an example. Read the live payload.
On the page, Incoming vs served is the same comparison. Served share is the percent of incoming that completed, in 5-minute steps over the last 6 hours.