SDK Size

Context

The jar dependency adds around 30MB to my final spring boot project, based on the main dependency and its child dependencies.
The decompressed openai-java-core takes about 76MB.
The ResponseStreamEvent.class is by itself 91KB. The contents of this file are more equivalent to a god function written in C than object oriented code written in Java. Maybe due to some sort of scripted code creation?

 62M	./com/openai/models
 10M	./com/openai/services

Concerns

The first concern is the added size in terms of MB to the project size.
The second concern is that when this code runs, it will instantiate larger than necessary objects that will consume more memory (compared to a better design).
- For instance ResponseStreamEvent, it has: 51 member variables, leading to very large functions such as equals, hashcode, toString, and most other methods; across 2400 lines of code
The third concern is about forcing integrators to have to pull in Kotlin into a server side project. Additionally, when there is no intention to run on Android.

Feature Request

Please consider to:

refactor and remove the kotlin dependency
refactor and reduce the overall SDK size.

Have you encountered performance issues from the size? If so, in what context? i.e. What prompted filing this issue?

It's hard to figure out how or whether to prioritize this issue without a motivating use-case.

Also, for what it's worth, Kotlin's purpose isn't just for Android. It's generally useful. And by the way, okhttp is written in Kotlin as well, so even if we rewrite the SDK in Java, that doesn't remove the Kotlin dependency.

Have you encountered performance issues from the size?

Have I spent time to do performance and load testing, and be able to provide you with raw data -> I have not.

The principle is about not being forced to use larger EC2 instances simply because this library takes more run time memory.

If so, in what context? i.e. What prompted filing this issue?

My background is that I've worked at payment companies and were responsible for implementing and adhering to PCI payment security standards, OWASP, etc.

Larger libraries increase the attack surface and cause a larger security and compliance burden.

Also, for what it's worth, Kotlin's purpose isn't just for Android. It's generally useful. And by the way, okhttp is written in Kotlin as well, so even if we rewrite the SDK in Java, that doesn't remove the Kotlin dependency.

That's fair. I'm using retrofit which brings in okhttp which then brings in only kotlin-stdlib.

The openai-java brings in kotlin-stdlib, kotlin-stdlib-jdk7, kotlin-stdlib-jdk8, kotlin-common, jackson-module-kotlin, and kotlin-reflect.

A new concern after seeing kotlin-reflect could be to verify if user inputs are safely sanitize; but I would assume you guys already thought of that.

This client is way too large. It is hard to debug due to kotlin and it does not expose server response errors. The typical exception just lists the status code no additional information. I usually need to resort to mitmproxy to figure out why client call failed. Please create a lightweight client which uses the java http client.

@TomerAberbach

Have you encountered performance issues from the size? If so, in what context? i.e. What prompted filing this issue?

It's hard to figure out how or whether to prioritize this issue without a motivating use-case.

Also, for what it's worth, Kotlin's purpose isn't just for Android. It's generally useful. And by the way, okhttp is written in Kotlin as well, so even if we rewrite the SDK in Java, that doesn't remove the Kotlin dependency.

@TomerAberbach One thing I do not understand is why the library packs two http clients (okhttp, httpclient5) for a regular java environment instead of using the default one. And I'm not a kotlin expert, but from my understanding in newer versions it should be possible to only include stdlib, not the -jdk8 and -jdk7 variants, isn't it?

I don't think decreasing library size would justify rewriting the whole library. But it would definitely make sense to have two artifacts, one targeting a modern java runtime and one targetting android with whatever polyfill it needs. Many other api libraries in java handle it this way.

@TomerAberbach One thing I do not understand is why the library packs two http clients (okhttp, httpclient5) for a regular java environment instead of using the default one.

The two http clients were definitely not ideal, but I actually just dropped the Apache one in v4.23.0 so that at least is resolved.

And I'm not a kotlin expert, but from my understanding in newer versions it should be possible to only include stdlib, not the -jdk8 and -jdk7 variants, isn't it?

I'm actually not sure. I'll have to look into that. It's possible we don't need all those variants.

I don't think decreasing library size would justify rewriting the whole library. But it would definitely make sense to have two artifacts, one targeting a modern java runtime and one targetting android with whatever polyfill it needs. Many other api libraries in java handle it this way.

Yeah, that's a good callout. There might be opportunities to produce a multi-release JAR.

Truthfully I don't have a ton of time to look into these other things. If you happen to have time and feel like researching whether all these Kotlin dependency variants are needed, then that'd be helpful with getting things moving here

Adding another concrete data point from a Spring Boot / Spring AI integration.

Context:

Application: Spring Boot 4 + Spring AI 2.0.0-RC2
Dependency path: spring-ai-starter-model-openai -> spring-ai-openai -> openai-java -> openai-java-core
Use case: OpenAI-compatible Chat Completions only, via Spring AI OpenAiChatModel
Packaged as a normal Spring Boot executable/fat jar

Observed size impact with openai-java-core-4.38.0.jar:

openai-java-core-4.38.0.jar in the final Boot jar: ~39.7 MB compressed
Uncompressed contents: ~104 MB
Entries: ~20,683
com/openai/models: ~16,447 classes, ~83.7 MB uncompressed

Rough breakdown by API area inside com/openai/models:

admin          ~6.02 MB compressed / 3092 entries
beta           ~5.25 MB / 3102 entries
responses      ~4.48 MB / 2637 entries
realtime       ~3.10 MB / 1882 entries
evals          ~2.87 MB / 1660 entries
chat           ~1.18 MB / 720 entries

For projects that only need Chat Completions, most of the SDK surface is pulled in even though it is unused at runtime. This makes the final artifact noticeably larger and also increases cold deployment/upload time for self-contained Java services.

Feature request / suggestion:

Would you consider publishing modular artifacts in addition to the current full SDK? For example:

openai-java-chat or openai-java-core-chat: Chat Completions + shared core only
openai-java-responses
openai-java-realtime
openai-java-admin
openai-java-full: current all-in-one artifact for convenience/backward compatibility

The current all-in-one SDK is convenient, so keeping it makes sense. But a smaller chat-only artifact would help frameworks like Spring AI, and downstream applications that only use OpenAI-compatible chat endpoints, avoid pulling in Admin, Realtime, Evals, Beta Assistants, Vector Stores, Images, Videos, etc.

This is not just about disk size. In enterprise/server deployments, smaller dependency surfaces also help with faster artifact distribution, vulnerability scanning, SBOM review, and compliance review.

I was looking into why my application deps are so big. I have a Spring Boot 4 + Spring AI 2.0 app that only uses Chat Completions through OpenAiChatModel.

What I noticed is that openai-java-core grew from 39.7 MB (4.38.0, mentioned above) to 71.0 MB in 4.90.0 (~35k classes, 184 MB unpacked), a third of our boot jar. Spring AI 2.0.2's spring-ai-openai only references com.openai.{core,client,credential,azure,errors} and models.{chat,completions,audio,images,embeddings,moderations}.

As a workaround I strip at build time (unpack the jar into target/classes without models and services for beta, admin, responses, realtime, evals, live, webhooks, finetuning, vectorstores, conversations and containers, and the original jar is excluded from repackaging. The result is 71.0 MB → 10.6 MB, with no NoClassDefFoundError or VerifyError, because OpenAIClientImpl creates its sub-services lazily.

This works, but it is opviously fragile and every consumer would have to reinvent it. A chat-only artifact (or openai-java-core split per API area, with the current jar as an aggregate) would make it unnecessary, and frameworks like Spring AI could depend on just what they use.

I really don’t get it—this SDK keeps getting bigger and bigger, and every time I upgrade it, it adds a lot to my bundle size.

Navigation Menu

Repository navigation

SDK Size #602

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

SDK Size #602

Description

Activity

TomerAberbach commented on Sep 2, 2025

nkavian commented on Sep 22, 2025

Jotschi commented on Oct 9, 2025

gpsfl commented on Feb 24, 2026

TomerAberbach commented on Feb 24, 2026

TomerAberbach commented on Feb 24, 2026

liushenling2001 commented on Jun 10, 2026

soudmaijer commented on Oct 22, 2026

zhujianxintian commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions