I was wondering whether this was any good for programming, but it is too fast for its own good. There is a limit of 450,000 tokens per minute. I hit this limit in about 90 seconds and burned through $1.10 while doing so. This is because cached tokens count towards the token limit.
For comparison, I ran the same task with DeepSeek-V4-Flash, which finished in 172 seconds and cost $0.024 with a final context window size of 55217 tokens, while Qwen3.8-27B was not even close to being done with a 64178 context window.
This is a very efficient way to burn your money, but I would not recommend it for programming.
On the positive side, I got a $5 signup bonus, so it wasn't my own money.
The point of speed is to increase throughput. What the point of all this speed, if overall throughput is still so low?
This doesn't work for my use case at all (code generation).
These bursts of speed might work well for workflows that need bursts of quick decisions, followed by silence. But these workflows have needed provable determinism to som extent, so I haven't been using llms for those use cases. And I don't see myself using llms for them in the future too.
Without prompt caching this becomes more expensive than fable 5.1 after turn 50, assuming you start with 40k tokens and add 2k per turn.
> There is a limit of 450,000 tokens per minute. I hit this limit in about 90 seconds
I'm confused. If it's 1500t/s, isn't that only 90k per minute? How do you hit a 450k/minute limit?
Cached tokens count towards the limit as well. For example, if your context window is 50,000 tokens, it takes 9 requests to reach that limit without generating a single token.
Cached tokens counting toward the limit is ridiculous.
then it's basically useless lol, wtf, this has to be a defect
It's PR:
https://news.ycombinator.com/item?id=49556302
Could this also be coming from the problem that Qwen3.8-27B's default mode being "extra-high reasoning level"?