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