[minimaxir]

A pro-tip for using the OpenAI API is to not use the official Python package for interfacing with it. The REST API documentation is good, and just using it in your HTTP client of choice like requests is roughly the same LOC without unexpected issues, along with more control.

[rockostrich]

I've found this happens with a lot of first party clients. At work, we use LaunchDarkly for feature flags and use their code references tool to keep track of where flags are being referenced. The tool uses their first party Go client to interact with the API but the client doesn't handle rate limiting at all even though they have rate limiting headers clearly documented for their API.

[klooney]

First party clients are typically an afterthought, and you can't add features without getting a PM to sign off, which strangles the impulse to polish & sand down rough edges.

[rattray]

Agreed. Any in particular come to mind that you'd like to see improved?

(my company provides first-party clients with a lot of polish; maybe we could help)

[rattray]

Hey minimaxir, I help maintain the official OpenAI Python package. Mind sharing what issues you've had with it? (Have you used it since November, when the 1.0 was released?)

Keen for your feedback, either here or email: [e-mail]

[minimaxir]

There's nothing wrong per se, it works as advertised. But as a result it's a somewhat redundant dependency.

[rattray]

Ah, gotcha. Thanks, that makes sense. FWIW, here are some things it provides which might be worth having:

1. typesafety (for those using pyright/mypy) and autocomplete/intellisense

2. auto-retry (w/ backoff, intelligently so w/ rate limits) and error handling

3. auto-pagination (can save a lot of code if you make list calls)

4. SSE parsing for streaming

5. (coming soon) richer streaming & function-calling helpers (can save / clean up a lot of code)

Not all of these matter to everybody (e.g., I imagine you're not moved by such benefits as "dot notation over dictionary access", which some devs might really like).

I would argue that auto-retry would benefit a pretty large percentage of users, though, especially since the 429 handling can paper over a lot of rate limits to the point that you never actually "feel" them. And spurious/temporary network connections or 500s also ~disappear.

For some simple use-cases, none of these would really matter, and I agree with you - especially if it's not production code and you don't use a type-aware editor.