From 84c14b3463cafb4d777781757182d305f8320379 Mon Sep 17 00:00:00 2001 From: Codex Date: Sun, 26 Apr 2026 11:09:19 +0800 Subject: [PATCH] docs: clarify OpenAIClientAsync rate-limit note --- .../src/main/kotlin/com/openai/client/OpenAIClientAsync.kt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClientAsync.kt b/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClientAsync.kt index 6bbb59fa2..d1518a8aa 100644 --- a/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClientAsync.kt +++ b/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClientAsync.kt @@ -33,9 +33,10 @@ import java.util.function.Consumer * * This client performs best when you create a single instance and reuse it for all interactions * with the REST API. This is because each client holds its own connection pool and thread pools. - * Reusing connections and threads reduces latency and saves memory. The client also handles rate - * limiting per client. This means that creating and using multiple instances at the same time will - * not respect rate limits. + * Reusing connections and threads reduces latency and saves memory. Each client also manages its + * own retries independently, so reusing one client keeps that retry behavior, connection pool, and + * thread pools in one place while multiple clients may compete separately against the same external + * rate limits. * * The threads and connections that are held will be released automatically if they remain idle. But * if you are writing an application that needs to aggressively release unused resources, then you