From 36b9170e1ee55bcc163459ceb8fba08375ee94e2 Mon Sep 17 00:00:00 2001 From: mukunda katta Date: Tue, 21 Apr 2026 08:19:14 -0700 Subject: [PATCH] docs(client): clarify rate limit coordination --- .../src/main/kotlin/com/openai/client/OpenAIClient.kt | 6 +++--- .../src/main/kotlin/com/openai/client/OpenAIClientAsync.kt | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClient.kt b/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClient.kt index 4ca78004e..679b68ca2 100644 --- a/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClient.kt +++ b/openai-java-core/src/main/kotlin/com/openai/client/OpenAIClient.kt @@ -33,9 +33,9 @@ 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. Reusing a single client also + * centralizes retries and connection reuse in one place, but it does not proactively coordinate + * rate limiting across multiple client instances. * * 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 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..e6618adc9 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,9 @@ 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. Reusing a single client also + * centralizes retries and connection reuse in one place, but it does not proactively coordinate + * rate limiting across multiple client instances. * * 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