Copy the homework. Legally.
That’s the short version of what Y Combinator’s Garry Tan is arguing. He wants smaller American open-weight AI labs to use distillation on American frontier models, the same kind of training approach that has helped Chinese labs put out capable open models. His reasoning is that this gives the U.S. a stronger set of domestic open alternatives, and a better balance between the frontier tier and the open-weight tier.
As someone who builds bots for a living, this argument lands differently than most AI policy takes. Because distillation isn’t an abstraction to me. It’s a line item in my deployment budget.
What distillation actually means when you’re shipping
If you’ve never trained a model, distillation is easier to grasp than the name suggests. You take a large, capable model (the teacher) and use its outputs to train a smaller model (the student). The student doesn’t learn from raw internet text alone. It learns from a model that already figured out how to answer well. You end up with something much smaller that behaves closer to the big model than its size would suggest.
For bot builders, that gap between “size” and “behavior” is the whole ballgame. Every decision I make about a bot comes back to it:
- Can this run on my own hardware, or am I paying per token forever?
- Can I fine-tune it on my domain data without a contract negotiation?
- What happens to my bot when the provider deprecates the endpoint?
- Can I run it in an environment where data can’t leave the building?
Every one of those questions gets an easier answer when good open-weight models exist. And distillation is one of the most direct paths to good small open-weight models.
Why the “which country” part matters to a builder
I’ll be honest, my first instinct on Tan’s framing was skeptical. Open weights are open weights. When a strong open model ships, I download it and test it, and the flag on the release page isn’t in my evaluation use.
But sit with the argument a bit longer and there’s a practical edge to it. A lot of the bots I help people build run inside organizations with rules. Compliance rules, procurement rules, government contract rules, internal security review rules. In those environments, provenance is not a philosophical question. It’s the thing that determines whether the project gets approved at all. I’ve watched perfectly good architectures die in review because the model’s origin raised a question nobody wanted to answer.
So having more strong open-weight options with U.S. provenance isn’t about rooting for a team. It’s about a wider menu of models that can actually clear review. That’s a real constraint on real projects, and more choices means fewer builders getting forced into a single expensive API because it was the only thing legal would sign off on.
The balance question is the interesting one
Tan’s framing includes something more subtle than “make more open models.” He’s talking about balance between open-weight and frontier work.
That tension is familiar to anyone who ships. Frontier models are where the new capabilities show up first. Open models are where cost, control, and customization live. Most production bots I’ve built end up using both, with a large model handling the hard reasoning and a small model handling the high-volume, well-defined work. Classification. Extraction. Routing. Summarizing. The unglamorous 90 percent.
Distillation is what makes that architecture affordable, because it’s how the small model gets good enough to trust with the unglamorous 90 percent. Without decent students, you either overpay by sending everything to the teacher, or you accept worse output on the routine path. Neither is a great place to be.
What I’d actually do with this
If more distilled open-weight models start landing from U.S. labs, my playbook doesn’t change much, but it gets easier to execute:
- Build the bot against a frontier model first, to establish the quality ceiling you’re aiming for.
- Log real traffic and identify which request types are repetitive and narrow.
- Test open-weight candidates on exactly those request types, not on generic benchmarks.
- Route by task, not by vibes. Small model handles what it handles, escalate the rest.
- Keep the abstraction layer thin enough that swapping models is a config change, not a rewrite.
That last one is the advice I’d give regardless of how the policy conversation goes. The specific model you pick today will not be the model you run next year. Build like that’s true.
The part I’m watching
Tan is making a strategic argument, and strategic arguments about AI usually stay strategic. What would make this concrete is boring stuff: clear terms about training on model outputs, and small labs actually shipping students worth downloading.
Until then, I’ll do what I always do. Download the thing, run it against my own evals, and see if it earns a spot in the routing table. That’s the only benchmark that has ever mattered to me.
đź•’ Published: