From c8697cc459635644e1e6c139f589e47d45f64129 Mon Sep 17 00:00:00 2001 From: Pierre LE GUEN <26087574+PierreLeGuen@users.noreply.github.com> Date: Wed, 23 Sep 2026 12:05:35 +0000 Subject: [PATCH] docs: say direct instances can't be pinned reliably Indexed hostnames exist, but they map to a position among healthy instances that changes as instances come and go. --- cloud/experimental/direct-completions.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cloud/experimental/direct-completions.mdx b/cloud/experimental/direct-completions.mdx index 4d82c46..554cbb0 100644 --- a/cloud/experimental/direct-completions.mdx +++ b/cloud/experimental/direct-completions.mdx @@ -11,7 +11,7 @@ tag: "Experimental" Current verification limitations: - **An attestation report covers one instance.** Several instances can serve the same direct hostname, and separate connections can reach different ones. `GET /v1/attestation/report` returns the report of the instance that answered, and `all_attestations` contains only that report. You can't verify every serving instance before a completion, so a TLS key pinned from one report fails when a later connection reaches another instance, even a legitimate one. Tracked in [cloud-api#1087](https://github.com/nearai/cloud-api/issues/1087). - - **Signature lookups can return `404`.** Each instance keeps response signatures in its own memory. `GET /v1/signature/{chat_id}` can reach a different instance than the one that served the completion, and clients can't choose the instance. + - **Signature lookups can return `404`.** Each instance keeps response signatures in its own memory. `GET /v1/signature/{chat_id}` can reach a different instance than the one that served the completion, and there is no stable way to choose the instance. A direct completions endpoint sends your request straight to one model's TEE at its own hostname, without the Gateway in between. It accepts the same API key as the Gateway. Use it only when you maintain an existing direct integration.