the short answer
Classify Jev failures before retrying. Fix 401 and 422 responses rather than repeating them; back off for 429 rate limits and 529 overload; bound retries for connection, timeout and server failures within the workflow’s total deadline. The current JavaScript SDK defaults to a 10-second timeout per attempt and two retries. Explicitly define fallback behavior and keep failures separate from uncertain model answers.
- Documented API statuses
- 401, 422, 429 and 529
- JS default timeout
- 10 seconds per attempt
- JS default retry count
- 2 after initial attempt
- JS retry statuses
- 408, 429 and 500–599
- Direct rate limits
- Published as dynamic; verify current account
First Decide Whether a Valid Model Answer Exists
Retrying model uncertainty until a preferred answer appears is selection bias and destroys calibration. Likewise, converting a timeout to probability zero makes reliability incidents look like negative predictions. Preserve these outcome types separately in telemetry and policy logic.
| Class | Examples | Retry? |
|---|---|---|
| Caller defect | Invalid schema, empty questions, malformed rubric | No; fix request |
| Credential/access | Missing key, invalid key, denied resource | No; alert and correct access |
| Capacity/transient | 429, 529, 5xx, connection reset | Possibly, with bounded backoff |
| Deadline/cancel | Per-attempt timeout or caller abort | Only if remaining budget and intent allow |
| Valid uncertainty | Noul near decision boundary or diffuse Choice | No transport retry; use review/fallback band |
| Semantic error | Confident but wrong judgment | No blind retry; evaluate question/model/state |
Understand the Current JavaScript SDK Defaults
As inspected September 22, 2026, the official JavaScript SDK uses a 10-second timeout per attempt and permits two retries after the initial attempt. It retries HTTP 408, 429 and 500–599 plus connection and timeout errors. Exponential backoff starts at 500 ms, caps at 5 seconds, subtracts up to 25% jitter and respects Retry-After guidance up to 60 seconds.
These defaults are sensible transport behavior, not a workflow SLA. The source explicitly says timeout is per attempt and there is no total retry budget. A synchronous guardrail with a two-second deadline needs tighter settings and a known fallback; an offline eval worker may wait and retry longer.
Calculate a Total Deadline Before Selecting Retries
A rough worst-case budget is the sum of attempt timeouts, backoff delays, serialization and queueing. Three 10-second attempts already permit about 30 seconds before backoff or application overhead. Server-provided retry delays can be much longer. Use an outer deadline and stop launching attempts when the remaining time cannot support one.
Retries amplify load during incidents. Add concurrency limits, queues, exponential backoff and jitter, then shed or defer low-priority work. A circuit breaker can stop repeated calls after sustained failure, but its open/half-open policy must be observable and tested.
Plan Around Both Request and Token Throughput
TypeSafe’s current model page lists 250,000 tokens per second and 1,200 requests per minute for the direct service while saying limits adjust dynamically. Small requests may hit RPM first; large batches may hit token throughput first. Gate concurrency with both request and estimated token budgets, then reconcile estimates with returned usage.
Provider gateways have their own quotas and response behavior. Record provider identity and do not copy direct-service limits into an OpenRouter or Cloudflare capacity plan. The platform comparison separates these routes.
Fallback Follows Consequence, Not Convenience
A fallback model is not automatically equivalent. It needs its own question mapping, thresholds and evaluation. Never convert “Jev unavailable” into “policy satisfied.” For broader runtime design see Jev policies and abstention.
| Workload | Possible failure path |
|---|---|
| Offline evaluation | Queue for delayed retry; mark result pending rather than pass |
| Reversible low-risk routing | Use a deterministic default and record degraded mode |
| High-risk proposed action | Require approval or fail closed when the control is mandatory |
| User-facing interactive flow | Return a transparent retry/degraded message within SLA |
Measure Retries as Part of Product Behavior
Alert on logical-decision failures and latency, not only individual request success. A third attempt that returns 200 after 29 seconds may still violate the product deadline. Replay failure injection in staging and verify that audit records distinguish no answer, uncertain answer and human override.
- Attempts per logical decision and total wall-clock latency.
- Status/error class, request ID and retry delay source.
- 429/529 rate, concurrency, queued work and circuit state.
- Fallback path, dropped/deferred work and user-visible impact.
- Tokens and cost including repeated requests.
FAQ
Does the Jev SDK retry 429 responses?
The current JavaScript SDK retries 429 under its default policy and respects supported retry-delay headers. Verify the installed release.
Is the 10-second SDK timeout a total deadline?
No. Current JavaScript source defines it per attempt and allows two retries by default, so wall-clock time can be much longer.
Should I retry a low-confidence answer?
No. It is a valid model result. Route it through calibrated review or fallback logic instead of sampling until the answer changes.
Should a policy fail open or closed?
Choose by consequence and whether the semantic check is mandatory. Document and test the specific timeout, rate-limit and outage behavior.
Sources
Checked against the sources below on September 22, 2026. Model versions, prices and limits change.
- TypeSafe AI: official JavaScript SDK
- TypeSafe AI docs: HTTP API reference
- TypeSafe AI docs: Models
- TypeSafe AI docs: Jev 1.13 jaggedness