This is Part 3 of AI Grew Up on Git, a series on the Git infrastructure that raised AI and what AI is now doing to it.
The company that now holds most of the world’s open AI models began life as an app for lonely teenagers.
In 2016, three French founders started a company in New York around a chatbot. The chatbot was meant to be a kind of digital best friend, an AI you could text when you were bored or sad, aimed squarely at teenagers, and they named the whole thing after the emoji with the smiling face and the two open hands, the one people use to mean a hug. It was earnest and a little strange, and for a while it worked. At its peak the app had something like a hundred thousand people opening it every day, and over its life its users exchanged more than a billion messages with it.
And it went nowhere. The founders kept improving the natural-language technology underneath, making the bot better at understanding and answering, and the improvements did not move the numbers that mattered. Better answers did not make teenagers stay. The app was moderately loved and structurally stuck, the way a lot of consumer apps are, and by the standard story of startups it should have quietly died.
What happened instead is one of the more consequential accidents in the recent history of AI, and to see why it matters you have to know who these three people were.
A chatbot for bored teenagers
Clément Delangue, the CEO, had been an entrepreneur since before he could legally sign a contract. As a teenager in a small town in northern France, he and his older brother imported all-terrain vehicles and dirt bikes from China, stockpiled them in their father’s garden-equipment shop, and sold them on eBay, where Delangue became one of the top sellers in the country. He carried that instinct forward, through a computer-vision startup that Google later bought and a job offer from Google that he turned down, into a settled conviction that the interesting action was in small, open, fast-moving things rather than large closed ones.
Julien Chaumond, the CTO, came from inside the French state, an engineer who had worked at the country’s economy ministry. Thomas Wolf, the third founder and chief science officer, was a physicist by training who had moved into machine-learning research. The three of them had converged, more or less, around a study group for an online Stanford course, and they shared one conviction above the others: that the technology of language understanding was about to matter enormously, and that it should be open.
That last conviction is the thing to hold onto, because it is what turned a failing chatbot into infrastructure. When you believe technology should be open, you do a particular thing almost by reflex when you build something useful internally. You publish it. And the tools Hugging Face was building to make its own chatbot understand language were, it would turn out, far more valuable than the chatbot had ever been.
The pivot hidden inside the failure
The turn came from outside, in late 2018, when Google Research released a model called BERT.
BERT was a genuine break in natural-language processing, a model that understood language well enough to reset what people expected from the field, and it landed on a research community that immediately wanted to use it. There was a gap, though. BERT arrived in a form that was not trivial to pick up and run. Thomas Wolf and the Hugging Face team saw the gap and closed it fast: they built a clean implementation of BERT in PyTorch, the framework researchers used, and they released it as open source on GitHub within roughly a week.
It went off like a signal flare. The researchers who had been unable to easily use BERT could now use it in one line, and they descended on the release. The little library did, in a few weeks, what the chatbot had failed to do in two years: it found a real and growing audience of people who needed it and came back. The founders had built a tool to support their own product and discovered that the tool was the product. Within months the chatbot was a memory, and the library, which grew into what they called Transformers, was the company.
By 2019 the pivot was formal. Hugging Face stopped being a consumer app and became infrastructure for open machine learning, and the thing people came to it for was no longer conversation but code, the libraries and, increasingly, the models themselves.
The shape of this repeats what the last two parts described. Hugging Face found its real business the way GitHub found its real asset: sideways, as a byproduct of doing something else. GitHub set out to make collaboration pleasant and accidentally accumulated the largest corpus of code on earth. Hugging Face set out to comfort teenagers and accidentally built the tools the entire open-model world would run on. The teenagers were the accident. The researchers were the company.
The file Git could not hold
To understand what Hugging Face built next, and why it was hard, you have to return to what Git is, because the two are on a collision course.
Recall the design from Part 1. Git thinks in snapshots of text. It expects files that are small, that are made of lines, and that change a little at a time, and its whole machinery is tuned for exactly that. When you change three lines in a source file, Git can represent that change compactly, show you a readable comparison of before and after, and store the difference efficiently. This is the thing Git is superb at, and it is superb at it because it assumes the files are code.
A model is not code. A trained model is a file full of weights, which are just numbers, millions or billions of them, packed together into a single binary blob. “Binary” here means the file is not human-readable text but raw data, and “blob” is the honest word for it: an undifferentiated mass. Such a file is routinely hundreds of megabytes, often many gigabytes. And it has a property that is poison to Git’s entire way of working: when you retrain or fine-tune the model, essentially every number inside it can change at once. There are no three lines that changed. There is no readable before-and-after. The old blob and the new blob are simply two different gigabyte-sized clouds of numbers, related in a way no line-by-line comparison can express.
Hand a file like that to Git and Git does what it always does, which is exactly the wrong thing. It faithfully stores the entire new blob, and it keeps the entire old blob too, because Git never throws history away, that being the whole tamper-evident point from Part 1. Do this a few times across a few model versions and the repository swells to tens of gigabytes of near-duplicate binary mass, slow to clone, slow to move, a millstone. Git has not malfunctioned. Git is working perfectly, applying a discipline built for source code to an object that is nothing like source code. The tool that secured the world’s software is structurally, unfixably wrong for the world’s models.
This is the problem Hugging Face had to solve to become a home for models. And the solution it reached for is a small, honest piece of deception.
The pointer trick, and the playbook
The workaround is a tool called Git LFS, for Large File Storage, and the idea at its heart is a sleight of hand.
When you put a model into a repository using Git LFS, the giant weight file does not actually go into Git. In its place, LFS drops a tiny text file, a stub, a few lines long, that names the real file’s cryptographic hash and its size and nothing else. That little pointer is what Git sees and stores. The real gigabytes of weights are shipped off to a separate storage server and kept there, addressed by the hash written in the stub. Git, looking at its repository, sees a small text file that changes a little when the model changes, which is precisely the kind of thing it was built to version. It does its job happily, never knowing that the small text file is a decoy standing in front of a mountain of numbers parked somewhere else.
That is the trick that makes the impossible look routine. Git gets to keep believing it is versioning text. The weights get versioned by proxy, through their pointers. Everyone is satisfied, including Git, which has been politely fooled.
Hugging Face built its entire Hub on this foundation. On the Hub, one model is one repository, versioned by commit exactly as Part 1 described, so you can pin a model to an exact commit, tag a release, or branch it, while LFS quietly handles the heavy files underneath. The seam between the pretense and the reality is usually invisible, but it shows itself in a telling detail: the Hub’s servers run a check on every push that rejects any file over ten mebibytes trying to enter Git the ordinary way. Ten megabytes and up, and the door is closed unless the file goes through the pointer system. The rule exists to enforce the deception, to make sure no one accidentally hands Git the real blob it cannot handle.
Then Hugging Face made the move that this series has been building toward. Having gotten Git to hold models, it wrapped the whole thing in the exact social playbook GitHub had invented, the one from Part 2. A model on the Hub got a public page. You could fork someone else’s model, the way you fork a repository, to make your own variant. You could open a pull request against a model, discuss it, propose changes. You got a profile that displayed your work to the world. Sharing a model was engineered to feel, gesture for gesture, like sharing code on GitHub. The weights had been given a GitHub of their own, and it was not GitHub.
The place the weights live
Once sharing a model felt like GitHub, the same gravity that concentrated code onto GitHub concentrated models onto the Hub, and for the same reason.
It was never mainly a technical reason. It was social, exactly as in Part 2. The builders were on the Hub, so the interesting models were on the Hub, so any model published anywhere else was cut off from the community that would download it, fine-tune it, build on it, and improve it. A model alone on a private server was a tree falling in an empty forest. Hugging Face became the default home of open model weights the way GitHub became the default home of open source code, not because its version control was best but because its people were there. Today it hosts well over a million model repositories, and “put it on Hugging Face” has become as automatic for a model as “put it on GitHub” is for code.
But the deception at the base of all this never fully resolved, and the industry keeps stubbing its toe on the place where Git’s pretense wears thin. Git LFS deduplicates whole files, which means it has no idea that two checkpoints from the same training run, saved a few thousand steps apart and sharing ninety-five percent of their numbers, are almost the same file. To LFS they are two separate blobs, stored in full, transferred in full, ninety-five percent of it redundant both times. For an industry that produces these near-identical checkpoints by the thousand, that waste is not a rounding error.
So the edges have started to give. In March 2026, Hugging Face introduced a new kind of storage on the Hub, called Storage Buckets, for exactly the flood of files that Git was never meant to hold: training checkpoints, optimizer states, logs, the constant high-throughput exhaust of training models at scale. Buckets are deliberately not repositories. They are mutable and non-versioned, plain fast object storage, the thing Git is not, and Hugging Face said as much in announcing them, describing Git as the wrong abstraction for this kind of work. It was the first new repository type on the Hub in four years, and one of the people who put their name on it was Julien Chaumond, the same co-founder who had helped start the company around a teenage chatbot a decade earlier. The pretense that Git can version everything about a model is, quietly and at the edges, being set down.
Step back and the series’ shape is visible in three moves. Part 1 built a version-control system on distrust, for text. Part 2 built a social layer on top that concentrated the world’s code onto one platform and, without anyone intending it, assembled a corpus. Part 3 shows both of those foundations stretched to hold the actual artifacts of modern AI, the models themselves, which they were never designed for, held in place by a pointer trick and beginning, at the seams, to strain. The infrastructure that raised artificial intelligence is now visibly bending under the weight of what it raised. What it means to version a file that has no lines, and refuses to diff, is where a later part goes next.
The Working Tree
This part’s commands are about teaching Git to carry what it cannot hold, and about branching a model the way you branch code. Everything here assumes Part 1’s local habits and Part 2’s remotes.
First, turn on Large File Storage. You do this once per machine.
git lfs install
Then tell Git which files should become pointers instead of going in directly. This writes a rule into a file called .gitattributes, which travels with the repository so everyone who clones it inherits the same rule.
git lfs track "*.safetensors"
Now a large model file added and committed the normal way is silently replaced by a pointer, while the real bytes go to LFS storage.
git add model.safetensors
git commit -m "Add model weights"
When you clone a model repository, Git first pulls the small pointers, then LFS fetches the real files they point to. From your side it looks like an ordinary clone, only heavier.
git clone https://huggingface.co/some-org/some-model
And branching, deferred from Part 2, is how one model becomes many. A branch is a cheap, local pointer to a line of development. You make one to build a variant without disturbing the original, work on it, and later merge it back if it earns its place.
git switch -c my-finetune
git merge my-finetune
That is the whole shape of it: mark the heavy files, let Git version their shadows, and branch the model as freely as you would branch code.
commit 3/8
What changed: The weights of the AI era got a home that looked like GitHub, by tricking Git into versioning files it was built to reject.
Why: A model is one giant blob where every byte changes at once, and Git only knows how to version text that changes a line at a time.
This is Part 3 of AI Grew Up on Git, a series on the infrastructure that raised artificial intelligence and what AI is now doing to it. Part 4 turns to what open code did to research itself, when a published paper became something you could clone, run, and check.