Best Practices

Choose the smallest sufficient model

Start with the smallest model that satisfies quality, context, and protocol requirements. Move to stronger models only when the workload requires it.

For recurring production jobs, keep a stable default model and API key route policy. Use specified provider only when the workload needs a fixed provider boundary.

Set request bounds

• Set max_tokens or the equivalent output cap when the protocol supports it.
• Use streaming where lower perceived latency matters; it works on channels that have passed streaming certification. Chat Completions streams must set stream_options.include_usage: true (see Streaming).
• Keep timeout and retry policies explicit in your server code.
• Avoid sending the same large context repeatedly when a shorter prompt will work.

Use shared capacity deliberately

Option	Use when
Shared capacity	Platform price, route health, and availability fit the workload

Shared capacity settles in USDT and is the normal AnyPath supply path. Always check its official list price, the Provider’s platform multiplier, balance, and payout status in Console before production traffic.

Handle failures by type

• Retry 429, transient 502, and route-availability 503 with backoff.
• Do not retry invalid credentials, insufficient balance, permission errors, or malformed requests without changing the input.
• Use GET /v1/models as the source of truth when a model becomes unavailable.
• Respect the Retry-After response header when it is present.

Protect keys

Keep AnyPath API keys in server-side environment variables or a secret manager. Never put them in browser code, mobile apps, public repositories, logs, or screenshots.