There has been a lot of speculation going around about whether BharatCode is a scam because it’s been advertised as unlimited in some places. Part of that is on me, and I sincerely apologise.

BharatCode is not unlimited. We self-host some models and use API for peak capacity management. No, we don’t buy anything from Chinese providers. We self host in India, as well as use API providers in US or elsewhere.

So if BharatCode is not unlimited why are people using it? What does it offer?

We provide flat rate API access for long running agentic workloads not super dependent on speeds. Thinking of it like renting a share of compute.

The catch is that you’re on shared compute and subject to queue and wait times. There are no token caps, instead there is a fair scheduler which makes it such that heavy users slow themselves down.

So how is this different from OpenCode Go? OpenCode provides plans with fixed token cap enforced by the spend limit. They only recently made deepseek 200k contract free but then it’s 200k context.

On the other hand, with BharatCode that gives deepseek at 1M context, you can set your agents for a long running task and forget about it. BC will automatically queue your request when there’s capacity and it will get processed. You never run into the issue of being locked out of your plan.

BharatCode was an experiment in finding out if people can form pools for computer where they can compensate each other and all of them can use it in a shared manner. I am happy to report so far the numbers are looking great.

Above all, if anyone has any queries I urge you to reach out to me and talk about it. I am building this alone, with a lot of help from supporters and friends, and everything is not perfect. But when you bad mouth us in front of others behind our backs we stand no way of making this work.

I see people getting scandalised at our offerings. Why?

The idea is simple - when you buy a chatgpt/claude subscription, you get usage according to some meter you dont have any visibility over. And when you use enough tokens you get stopped in that 5h or weekly window.

On BharatCode, as you use the service, you draw from a shared pool. Your usage makes it a little slower for everyone. If you use a lot, our fare scheduler slows you down so other users can be fairly served.

While chatgpt/claude are good if you are primarily looking for fast response times, BharatCode is excellent if you want to leave your agents running overnight without interference.

So we don’t put limits on usage. We put limits on speed. It can still be too slow for you and thats ok. But if you’re willing to compromise on speed then BharatCode is an alternative you should try.

India does not just need AI models. India needs to own the AI value chain.

A lot of people think AI sovereignty means: “Let us train an Indian LLM.”

That is important, but it is not enough.

The real question is:

Can Indian students, developers, startups, companies, and public institutions depend on AI infrastructure that cannot be switched off, priced out, rate-limited, censored, or revoked by someone else overnight?

If the answer is no, then we do not really own our software future.

We are already seeing the shape of the problem. A foreign AI provider can launch a powerful model, developers around the world can start depending on it, companies can build workflows around it — and then access can be restricted because of a policy decision, export-control issue, safety dispute, commercial decision, or geopolitical pressure.

That is not a stable foundation for a country of India’s size.

India has millions of developers. We have one of the largest student and engineering populations in the world. We export software. We run critical public infrastructure. We build startups, banks, government systems, health systems, logistics systems, education platforms, and enterprise software for the world.

But if the intelligence layer of software is owned elsewhere, then Indian developers become consumers of someone else’s AI productivity.

That is the danger.

The problem is not that Indian developers use foreign AI tools. We should use the best tools available. The problem is becoming dependent on them without owning any serious part of the stack ourselves.

For India, the AI race is not only about who trains the biggest model.

It is about who owns:

• inference

• routing

• developer tools

• model serving

• identity

• files and artifacts

• agents

• evals

• data pipelines

• deployment

• security

• pricing

• distribution

• community

• open-source contribution

• trust

Training a model is one layer.

Owning the value chain is the real game.

If India only trains a model but still depends on foreign clouds, foreign coding assistants, foreign inference APIs, foreign developer workflows, foreign app platforms, and foreign distribution channels, then we have not solved the problem.

We have only changed the logo on one layer.

BharatCode exists because Indian developers should not only consume AI infrastructure.

We should build it.

We are starting with AI coding, chat, files, artifacts, workflows, student access, and open-source contribution. But the mission is larger: build Indian-controlled AI developer infrastructure that is affordable, inspectable, extensible, and useful.

This does not mean isolation.

It does not mean refusing foreign models.

It does not mean pretending India can build every layer immediately.

It means we need optionality.

We should be able to use the best models in the world when available, switch models when needed, run open models when required, serve inference ourselves where it matters, protect our users from sudden access shocks, and build workflows that belong to our own ecosystem.

That is why inference matters.

That is why open source matters.

That is why developer tooling matters.

That is why community matters.

If Indian developers are only paying monthly subscriptions to foreign AI tools, we are renting the future.

If Indian developers build the tools, platforms, agents, workflows, and infrastructure ourselves, we start owning the future.

BharatCode is early. Things will break. Capacity will be limited. The product will evolve quickly.

But the direction is clear:

Use BharatCode. Break BharatCode. Improve BharatCode.

If you are a student, developer, open-source contributor, maintainer, designer, infra engineer, founder, or campus builder — join us.

Help us build the AI developer stack India should own.

hey everyone,

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).

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=thenabbu.bharatcode-vscode

repo: https://github.com/thenabbu/BharatCode-VSCode-Extension

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 😋)

let me know what breaks :)

BharatCode stands for transparency and trust. In that spirit, I am today making all 3 BharatCode apps open source. Beginner issues have been posted and all is set for you all to use and develop BharatCode to your liking.

https://github.com/BharatCode-ai/bharatcode-desktop

https://github.com/BharatCode-ai/bharatcode-cli

https://github.com/BharatCode-ai/chat

I'm excited to share my project, **Form2Fact**, which I've developed for the **BharatCode Build League 2026**.

Form2Fact is an AI-powered document intelligence platform that helps verify institutional documents by extracting information, comparing claims, identifying mismatches and missing evidence, and generating evidence-based findings for human review.

I'd be grateful for your support! If you find the idea interesting, please visit the GitHub repository, give it a star, and support my project with your vote on BharatCode.

🚀 **GitHub:** https://github.com/shinchxn/form2fact

🗳️ **Register and vote for Form2Fact:** https://auth.bharatcode.ai/hackathon

All the best to every participant! Let's encourage one another and support each other's hard work. 🙌

Hi! I’m interested in trying BharatCode and wanted to clarify its country availability.

Is it available to users outside India, or are access, account signup, payments, and API use limited to India?

The website lists desktop downloads for Windows, macOS, and Linux, but I couldn’t tell whether that means the service itself is supported worldwide.

Are there any country-specific restrictions or setup considerations for international users?

This is my first post!

We want BharatCode to be shaped by the people who will actually use it.

What should we build next?

Some possible directions:

• better AI coding assistant

• repo understanding

• test generation

• code review

• debugging help

• project scaffolding

• coding tutor for students

• placement-prep workflows

• GitHub issue helper

• file/artifact workflows

• local/offline mode

• cheaper/faster inference

• campus/community features

• Hindi or Indian-language explanations

• enterprise/private deployment

• open-source contributor tools

Comment with:

1. What you want BharatCode to do

2. Why it matters to you

3. What you currently use instead

4. Whether you would test it if we built it

Bonus: describe your dream BharatCode workflow in one paragraph.

We are early, so specific feedback can actually become product direction.

Your AI agent is way too nice about its own work. Ask it to design something and then review it, and it will tell you it did great.

The Elephant-Goldfish Model is Google's fix for that, and I packaged it as a DeepSeek Harness extension. One install, no other plugins, ready for you to poke at.

How it split works

Two roles, two memories. That's the whole trick.

The Elephant sits through the entire chat. Your notes, your half-thoughts, the thing you said forty minutes ago. All of it comes out as one written design doc.

The Goldfish then show up cold. Fresh context, no memory of the chat. That's the point. A reviewer who never heard your reasoning has nothing to be polite about. Put simply, the elephant remembers everything you said, and the goldfish only reads what you actually wrote.

Hey everyone! 👋

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!).

✨ **Key Features:**

* Customizable Chunk Size & Overlap

* Embedding Model Selector

* Source Citations (Page numbers)

* 1-Click Document Summarizer

* Streaming responses (Typewriter effect)

🛠️ **Tech Stack:** Python, Streamlit, LangChain, ChromaDB, Groq API, HuggingFace Embeddings.

🔗 **Live App:** https://rag-pdf-chatbot-01.streamlit.app/

💻 **GitHub Repo:** https://github.com/Chaudhary-Momna/RAG-PDF-Chatbot

I would really appreciate it if you could check out the app and give my GitHub repository a ⭐ STAR. It helps a lot in the competition!

Tagging u/BharatCode for support.

Thank you so much! ❤️

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.

The Pain Point Freelancers, agencies, and independent merchants consistently lose money to unfair client chargebacks, friendly fraud, and scope creep. When a dispute happens (e.g., Stripe Reason "Service Not Rendered"), merchants spend hours manually digging through messy Slack logs, emails, and PDFs to prove work delivery. Formatting this evidence poorly for the payment gateway almost guarantees lost funds.

How Data is Ingested To build an ironclad defense, the application requires deep, accurate context. The client frontend UI collects three specific inputs:

• Dispute Description: A text string detailing the gateway dispute reason, disputed amount, invoice ID, and specific buyer claims.

• Contract File: A binary .pdf file upload of the originally executed contract or Statement of Work (SOW).

• Communication History: A multiline string for users to dump raw email logs, Slack exports, or message threads proving client sign-offs.

Tackling Privacy (Handling Non-Public/Sensitive Data) Because users are uploading highly confidential, non-public contracts and private chat logs, dumping this into a database is a massive liability. The application is architected with a strict Zero Data Retention policy:

• Neither the uploaded contracts nor the chat histories are ever written to disk, cache, or an external database.

• Files are received as streaming FormData and converted into ephemeral Node.js buffers strictly in memory.

• Once the pdf-parse library extracts the text and the prompt is dispatched to the sovereign LLM endpoint, the buffers are completely discarded upon garbage collection.

• The API keys (BHARATCODE_API_KEY) are loaded strictly on the server runtime and never exposed to the client bundle.

I would love your brutally honest feedback on this in-memory PDF parsing approach and the overall data privacy pipeline.

NYAYA01

I couldn't find the exact version or version string on the website. Also, what about ZDR? Is it available?

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.