Free big model, who told you how much was left, who made you hit the wall?

Sooner or later, people who use free large models will encounter the same question: How many times can I adjust it?

It's not "Can it be adjusted", I've been testing it in the past few articles. It is after the transfer, when will the quota for free prostitutes reach its bottom, how many requests can be sent in a minute, and whether running will be suddenly stopped?

I asked this again today. There are two methods: first, see whether each family gives the amount information in the response header, and then send 8 requests in a row to see who stops me first.

The conclusion is this: Only 2 out of 10 will tell you how much you have left. But the one with the deadliest card didn't say a word.

!

Let's talk about what happened yesterday first

Before testing, I first explored as usual, and then saw NVIDIA's Nemotron-49B return 410:

The model 'nvidia/llama-3.3-nemotron-super-49b-v1' has reached its end of life on 2026-08-26T09:00:00Z and is no longer available.

The expiration time is 09:00 on August 26, 2026, accurate to seconds.

It was still alive when I retested it two days ago, although it was as slow as 15 seconds. The advice I gave in that article was "Move it to offline tasks." It went offline the next day.

I have to admit, the suggested shelf life is shorter than I thought. But NVIDIA did it decently among these vendors: it gave a clear EOL timestamp, rather than one day when you called it and suddenly found that the model name didn't exist. In the first few articles, Groq's Llama-3.3, ModelScope's DeepSeek are the latter death method, and the report is "the model does not exist", you simply do not know whether you wrote it wrong or it is gone.

Who will tell you how much is left?

A normal call can actually carry a lot of information in the response header. Whether to give or not is the choice of each family.

Groq gave the most rules:

x-ratelimit-limit-requests: 1000
x-ratelimit-limit-tokens: 8000
x-ratelimit-remaining-requests: 999
x-ratelimit-remaining-tokens: 7912
x-ratelimit-reset-requests: 1m26.4s
x-ratelimit-reset-tokens: 659ms

The number of requests and the number of tokens are measured separately, each with a residual amount and a reset countdown. Note that these two reset rhythms are not the same. The number of requests takes 1 minute and 26 seconds, and the number of tokens will be full in 659 milliseconds. That means you may have enough tokens but run out of requests, and vice versa.

Mistral gave it in more detail:

x-ratelimit-limit-tokens-minute: 250000
x-ratelimit-remaining-tokens-minute: 249980
x-ratelimit-tokens-query-cost: 20
x-ratelimit-limit-req-minute: 4
x-ratelimit-remaining-req-minute: 3

It even tells you separately "How many tokens did you spend on this query"(query-cost: 20).

But look at that limit-req-minute:4 . Four requests per minute. The token was given 250,000 yuan, and the request number was stuck in single digits.

There were eight remaining companies, but there was not a word in the response. NVIDIA, OpenRouter, Smart Spectrum, Cloudflare, Kimi, Cerebras, Gemini, all refused.

If you want to know how much you have left, there is only one way: hit it.

, then hit it once

I sent 8 quick requests in a row to several entrances that were still alive without waiting to see who would stop me first.

!

Groq, OpenRouter, Intelligent Spectrum, Cloudflare: all 8 passes. These four batch tasks can be queued with confidence.

NVIDIA Ultra-550B: The seventh one starts reporting 503.

But it needs to be clear here. What it returns is:

Service temporarily overloaded

This is overload, not current limiting. The two are completely different in nature: current restriction means "you exceed the quota", and overload means "I can't handle it at the moment." When writing retry logic, these two types need to be handled separately. 503 can be retried immediately, and 429 retried immediately will only continue to hit the wall.

Kimi: The fourth one died.

The return is 429, which reads:

request reached organization max RPM: 3

Three requests per minute. From the fourth to the eighth, all five consecutive ones were rejected.

In its response, it said nothing about this 3.

The one ## said was loose

The most interesting comparison is between Mistral and Kimi.

Mistral clearly wrote 4 requests per minute, and I sent 8 requests in succession, but it didn't stop me.

Kimi didn't write anything. I sent eight shots in succession, but it stopped me on the fourth shot.

Those who are nominally strict in practice are most stuck when they say nothing.

I have to add a strict sentence here: Among Mistral's eight requests, curl reported a timeout on the fifth. But I went to see the response body of the drop, and it contained a complete normal return with id, model, and usage. This means that the server processed this request. It was a timeout judgment problem on my side, and it cannot be regarded as blocking me. What really explains the problem is that the other seven passed normally.

So the accurate statement is: Mistral marked 4 RPM, but this time it did not strictly enforce it. Conversely, this also means that it may start to be executed at any time, and you cannot regard "the actual measurement is not blocked" as a prerequisite that you can rely on.

!

QKPFX4 How to use these numbers

To run concurrent or batch tasks, go through Groq, OpenRouter, Smart Spectrum, and Cloudflare. There is no pressure in 8 consecutive rounds, and there is no problem in queuing.

Kimi can only serial, and more than 20 seconds are left between requests. This is the rhythm when converted at 3 RPM. It can be used as a cover, and it must be hung in batches when used.

NVIDIA wants to write 503 separately and try again. It is not current-limiting or overloaded, and can be retried immediately without waiting.

The retry logic must distinguish between 429 and 503. This is the one that can be put into the code most directly in this actual test: 429 needs to retreat, and 503 can be retried immediately. Mix them together and use one set of logic, either wait in vain or keep bumping.

Don't treat nominal value as a promise. Mistral Standard 4 actually doesn't stop it, but you're taking advantage this time; the day it starts to be implemented, your service will collapse. If you really want to rely on a certain amount, pressing it yourself is the only reliable way.

few sentences boundary

This is a snapshot of an account and a point in time, August 27, 2026. The amount of free tier is the easiest thing for each family to adjust, and these numbers can change at any time.

Eight consecutive calls are a very light pressure. We can only measure the limit of the order of "several requests per minute". We cannot measure the daily quota and monthly quota, nor can we measure whether long-term high-frequency calls will trigger other risk control. I didn't really use the quota of any company. It would be unkind to others and would not be cost-effective to my account.

Kimi's current-restricted return with the account number and key, but I deleted it, leaving only the sentence "limit."

Finally, the NVIDIA Nemotron-49B EOL reminded me of one thing: the shelf life of such lists is measured in days. I was recommending it two days ago. If you followed my previous chapters, you should remove that one now.