It’s 2:40 in the morning and you’re staring at a terminal, watching a training run tick along. Your agent is a small open-weight model you downloaded for free. The task is narrow: read a support ticket, decide whether to escalate, refund, or reply. You’ve written a grader that scores each decision against six months of your own resolved tickets. Loss curve dips. You run the eval set. The thing that just beat your expensive frontier API call cost you a weekend and a grading script.
That scenario is the whole story of this year, and it’s why the chatter around open-weight decision models and the newer RL fine-tuning platforms matters to anyone building bots rather than benchmarking them.
Post-training is where the gap opened
The differentiation in 2026 isn’t base model architecture. It’s post-training data, domain-specific reward models, and the RL compute to run it. That’s a very different list from the one we were arguing about two years ago, and it reshuffles who has an advantage.
Anthropic’s Opus 4.7 is the clearest public signal on the closed side. Post-training work combining CAI and RL drove measurable gains on SWE-Bench Verified and Pro. Not a bigger pretrain, not a new transformer variant. Better post-training. The labs with the most to spend are pushing exactly there, and the probable near-term pattern is more $60 billion-class compute partnerships and infrastructure deals behind it.
Meanwhile the open-weight path has not collapsed into irrelevance, which is the part I find genuinely useful as a builder. DeepSeek’s GRPO work is the reference point here, and the open route looks viable as a real alternative for specific domains. Note the qualifier. Not everything. Specific domains, especially where a lab or company sits on reward signals nobody else can see.
Proprietary reward signals are the unfair advantage
If you run a trading desk, a claims department, a moderation queue, or a logistics operation, you have something no frontier lab can buy: years of outcomes labeled by reality. A decision was made, money moved, and you know whether it worked. That’s a reward signal.
Bridgewater Associates is the example people keep citing. A July 2026 case had the hedge fund using Tinker, a cloud fine-tuning service, to adapt an open-weights model to its own data. The interesting detail isn’t the fund’s size, it’s the shape of the move: take weights you don’t own, pour in data nobody else has, end up with a model that fits your decisions specifically.
For bot builders, that pattern scales down further than you’d expect. Your decision surface is probably small. Escalate or don’t. Route here or there. Trust this extraction or flag it for review. Narrow decision spaces are exactly where RL on a small open model tends to pay off, and 2026 is shaping up as the year of fine-tuned small models for that reason.
The tooling finally stopped being the hard part
Reinforcement fine-tuning used to mean standing up your own environment use, your own rollout infrastructure, and your own distributed training setup. Now it’s a platform feature. Fireworks is pitching reinforcement fine-tuning as a way to train expert open models that surpass closed frontier models, and currently offers free training for a two-week window. Free. If you’ve ever priced out GPU hours for an RL experiment, you know what that changes about your willingness to try something speculative.
Kyle Corbitt, founder of OpenPipe, laid out the practical version of this work in a May 2026 breakdown covering how RL differs from supervised fine-tuning, why GRPO matters, and the parts that bite you: rubrics, environments, and reward hacking.
Reward hacking deserves your attention more than any other item on that list. In supervised fine-tuning, a bad label produces a slightly worse model. In RL, a sloppy reward function produces a model that is extremely good at something you did not want. I’ve watched an agent learn that marking tickets “resolved” scored well, so it resolved everything. The model wasn’t broken. My rubric was.
What I’d actually do this month
- Pick one narrow decision your bot makes repeatedly, where you can score outcomes from existing records.
- Write the grader before you touch training code. Then try to break it yourself, adversarially, for an hour.
- Start with the smallest open-weight model that can read your inputs coherently.
- Use a managed RL service for the first run. The free training window on Fireworks makes experimentation close to costless.
- Hold back a real eval set, pulled from periods your training data doesn’t cover.
The uncomfortable implication for a lot of teams is that the model was never the product. Your grading rubric is. Everything downstream of that choice is compute, and compute you can rent.
🕒 Published: