Tenvor documentation
Request troubleshooting
Start with the HTTP outcome, the client version and a sanitized error code. Keep keys, request content and account details out of public reports. Reconcile uncertain work before submitting again.
Content checked . Live limits and prices can change.
Authentication or balance failure
- HTTP 401: confirm the client is using the intended programmatic key. Browser sign-in is separate. A rotated or revoked key may need replacement through the supported Console flow.
- HTTP 402 / insufficient_quota: inspect available balance and the request's reservation estimate in Console. A funded account can still lack enough unreserved balance for this request.
For OpenCode key replacement, follow the existing alpha client checklist. Do not rotate keys repeatedly as a connection test, and never paste a raw key into a support message.
Invalid request, model or endpoint
- HTTP 400: inspect the supported fields and exact current model ID. Remove unsupported controls; do not silently reinterpret rejected options.
context_length_exceeded: reduce history, attachments or tool definitions and keep the output budget within the published limit. Use the bounded error details and limits guide; do not include the original content in a public report.- Discovery or chat HTTP 404 in JetBrains: check whether the provider appended
/v1twice. The final path must be/v1/modelsor/v1/chat/completions. Follow the version-dependent endpoint instructions. - HTTP 409 on an idempotent retry: the same key may have been used with changed terms. Reconcile the original request before creating a different logical request.
Capacity, rate limit or upstream failure
For HTTP 429, respect Retry-After when present. For HTTP 503 or HTTP 504, inspect the returned error and any accepted request reference. Check status and current catalog availability. Do not loop through retries or force a different model provider while claiming to verify Tenvor.
A disconnect, HTTP 503 or HTTP 504 alone does not establish whether work was admitted or whether a charge is due. Keep the request reference privately, check the authenticated result and account activity, and reconcile accepted work before retrying. Do not turn a partial answer into a successful completion.
Pending result, quiet stream or abrupt close
A role event or keepalive can arrive before visible content. V10 dynamic text is batched, so quiet intervals and bursts are possible. This documentation release does not promise faster first content or smoother updates.
If the request returned HTTP 202, use its authenticated result_url. If a stream closes or reports an error, use the retained x-request-id and account-scoped result lookup. Check Console Activity and the final receipt before retrying.
Do not execute partial tool-call arguments or fabricate a successful terminal response. If the server outcome remains uncertain, report it as unresolved. Read the full recovery contract.
Share a useful, sanitized report
Record the client and version, whether fallback was disabled, approximate time, selected public model, HTTP status or bounded error code, whether a tool continuation completed, and whether matching account evidence was found. Keep request identifiers and account receipts private.
Do not attach prompts, generated text, tool arguments, source files, keys or screenshots containing secrets. Use the sanitized result template and the current support instructions in your invitation or policy library.
Independent operators process requests. Some request content can be stored durably without a verified maximum deletion deadline; generated output is retained for at least 30 days and may remain longer. Review the current privacy policy. This alpha does not promise confidentiality from a hostile host administrator, zero retention or shipped private-prefix/encrypted-inference features.