Build a client that handles refusals without retrying costly work indiscriminately.
Practical procedure
- Apply endpoint-specific input bounds before sending a request: Knowledge search accepts up to 1,000 query characters and at most 50 results, while memory retrieval accepts at most 20 results.
- Handle 429 as a bounded-capacity or daily-credit signal according to the actual error code. Do not turn a fixed guessed request-per-second figure into a published GoCux limit.
- For retryable reads, use bounded backoff and a cancellation deadline. For writes and paid turns, inspect operation identity and reconcile the first attempt before submitting another.
Call the supported chat contract
Normal web chat and the customer CLI use GoCux Gateway. Provider routing stays inside the service. The model catalog advertises the GoCux route alias gocux-deep, not an upstream provider identity. A compatible chat client supplies its message history and an explicit data-classification header; GoCux applies identity, policy, paid admission and credit reservation before a provider request.
Contract example
Developer examples below describe routes on an authorized, configured GoCux control-plane base URL. They are request shapes or operation references, not claims that a particular public hostname exposes the API. Use the workspace for the corresponding human workflow; availability and permissions depend on the actual deployment.
POST /v1/chat/completions X-GoCux-Data-Classification: public Content-Type: application/json
{
"model": "gocux-deep",
"messages": [
{
"role": "user",
"content": "Summarize these supplied public notes."
}
],
"stream": false,
"max_completion_tokens": 512
}Inspect the result
Read the returned choices and handle an error response before showing a completed answer. When streaming, consume complete events and distinguish connection closure from a successful terminal result. GoCux route aliases are product contracts; do not let a client-selected upstream model bypass server routing or display provider identities as customer configuration.
What to keep explicit
Capacity errors, exhausted credits and malformed input have different remedies. Preserve the server error code so a user can change the request or account state instead of watching an endless retry loop.
Handle incomplete and refused work
Declare X-GoCux-Data-Classification exactly once. A data_classification field in the chat-completions body is rejected rather than used as the declaration. Missing classification is unclassified and can be refused by policy. An optional Idempotency-Key helps identify an operation, but a paid replay can return 409 without replaying the original response or contacting the provider again.
Continue with related guides
Bring this workflow into your workspace.
Set the scope. Review the evidence. Approve the steps that need it.