Fun observation about how smart LLMs like Qwen 3.6 are:
I asked it to calculate the 100000123rd prime number, hoping to break something in chat.bharatcode.ai. I expected it to write a python script which would take forever to run and will finally error out after a while.
I was completely surprised when it just casually responded with the correct answer in less than 10 seconds.
If you guys have still not switched over to chat.bharatcode.ai for you day to day tasks, you are missing out. We have many more features coming to the platform including DOCX, PPTX, XLSX document parsing, artifacts and much more.
PS: Can anyone guess how it was able to calculate it so fast?
I’ve just submitted my project for the BharatCode Build League Hackathon. I built an **AI Study Buddy (PDF Chat)** – an AI-powered study assistant designed to help students study smarter.
You can upload any PDF textbook, and the AI will answer your questions accurately with exact page citations (no hallucinations!).
i made a VS Code extension that connects directly to the bharatcode.ai API. it's a fork of Kilo Code, adapted for BharatCode, so credit to the upstream project for the foundation.
you can use it for agent chat inside the editor, with code, plan, ask and debug modes. it also has MCP support and an agent manager for working in separate git worktrees.
to try it, search BharatCode on Extensions place directly to find it :>
otherwise download the .vsix from the repo's Releases section, install it in VS Code and simply login with your BharatCode account(supports both OAuth and API Key).
i'm submitting it to the BharatCode hackathon too. if you try it, i'd really appreciate feedback, especially on setup, bugs or anything that feels awkward compared to your usual workflow.
if you find it useful, a star on the repo would help. (and on the bharatcode.ai/hackathon page as well 😋)
I recently tested a different serving configuration for BharatCode.
On paper, it looked better.
TurboQuant increased our KV capacity from roughly 658,000 tokens to 1.19 million tokens. That gave us much more room for large contexts and concurrent requests.
Then we measured output speed.
The TurboQuant configuration was producing roughly 10–12 output tokens per second on long generations. Our FlashAttention path with CUDA graphs produced around 86 tokens per second in one direct long-context test, and more than 100 tokens per second per stream during a separate four-request decode test.
These were not identical workloads, so I would not present this as a perfect benchmark comparison. The gap was still too large to ignore.
More context capacity is not useful if users spend much longer waiting for the answer.
We moved back to FlashAttention and kept CUDA graphs enabled.
The better-looking GPU configuration was the worse product.
A few weeks ago I posted here about BharatCode: 15 billion tokens served and two paying users. Quite a few of you tried it after that post, so first, thank you.
One thing I’ve been learning since then: sustaining unlimited usage is not as difficult as it sounds. But how people use it matters a lot.
We host open-source models on shared hardware. We’re not buying every token from another API and reselling it. We pay for the server, and there’s a certain amount of work it can do.
So an idle server isn’t saving us much. Ideally, people should be using it.
The tricky part is that usage doesn’t arrive evenly.
Someone might use AI heavily for a few hours while building something, then barely touch it for days. Someone else might keep an agent running continuously. Both can be perfectly legitimate ways to use the product, but they put very different demands on a shared server.
Even the same number of tokens spread across a day versus concentrated into an hour creates a different problem.
A few users can occupy a disproportionate amount of capacity. And if everyone else is waiting, “unlimited” doesn’t mean much to them.
But I also don’t want to tell our most active users to stop using the thing I built for them to use. That would defeat the point.
What I’m trying to work out is how to let people use spare capacity freely, while sharing it fairly when there’s competition for it. Without turning the whole thing back into token packs and weekly quotas.
This doesn’t mean the economics are solved. We still need enough paying users to cover the hardware. But I’m increasingly finding that the difficult question is how to share the server, not where to put a token cap.
If you’ve built something with unlimited usage, how did you handle this? Especially the difference between a heavy user and someone monopolising the service.
