Users Don and Jagster reported a sudden, costly spike in OpenAI token usage—jumping from ~200k to ~24M tokens/day—after November 30, linked to the text-embedding-3-large model and semantic related topics. Falco investigated settings and usage, noting the spike likely indicated a bug, as 24M tokens/day suggests full-forum reprocessing. Roman identified and fixed a regression in backfill code that ignored digest checks, causing redundant embedding generation. A follow-up bug was found in batch processing logic, which Roman also patched. Don encountered a NULL vector error post-update, but it resolved after confirming OpenAI connectivity and applying a second fix Falco shared. Both users confirmed usage normalized after updates. Jagster confirmed API requests dropped back to normal. The root cause was inefficient backfill logic triggering unnecessary embeddings, now resolved.
I use text-embedding-3-large for ai embeddings model and something wrong with it. I mean, I have to top-up my OpenAI account now twice, since (30 Nov) which is crazy because it should be enough for months… Is that anything changed with related topics? It maybe backfills topics always which already done or I don’t know.
I checked mine. It exploded 27.11. and before that it was under 100k tokens a day, but then it increased to 7 million and is increasing everyday and yesterday it was close to 20 million.
Edit: October, embeddings cost was 46 cents. Now, December close to four days: almost 6 dollars.
One thing that may be related is that we used to skip calling embeddings API when the topic digest didn’t change, but we regressed this on gen_bulk_reprensentations@Roman.
@Don do you know how many embeddings requests are you making per day?
Given the 250 per hour, we have a hard limit of 6k per day. This numbers are still inside the limit.
However, if they are only getting triggered by our “update a random sample” of topics, it should be limited to 10% of that, which would, at worse, be 600 requests.
@Roman is this limit here not getting applied somehow? Or is the problem elsewhere?
Yeah, I think the bug I fixed revealed another one that the digest check was hiding.
I think the bug is here:
I changed it from find_each to find_in_batches last week (the former uses batches internally), and since both rely on limit to specify batch size, the original limit of limit - rebaked is ignored. We should use pluck + each_slice instead.
At first glance, it doesn’t look related. Looks like it failed to generate the embedding and it’s trying to insert NULL. Could it be OpenAI is returning an error? Maybe something quota related?
Can you please run this from a console?
DiscourseAi::Embeddings::VectorRepresentations::Base
.find_representation(SiteSetting.ai_embeddings_model)
.new(DiscourseAi::Embeddings::Strategies::Truncation.new)
.vector_from("this is a test")
.present?
It should log the error in your logs if it raises a Net::HTTPBadResponse.