A hedge fund beat every frontier model it tested

In June 2026, Bridgewater’s AIA Labs published results with Thinking Machines Lab on six information-triage tasks drawn from their investors’ daily work, including whether a news article is relevant to a macro investor, whether a central bank document signals a rate move, and where boilerplate begins in a research document.

Told only what the task was, frontier models scored under 50% accuracy. Bridgewater’s experts then wrote careful task instructions and reframed some of the questions, which lifted the best frontier model to 78.2%. Automated prompt optimization produced no further gains. That left them short of the 80% they considered the minimum for a system that investors would trust.

So they fine-tuned an open-weight model instead. Qwen3-235B scored 44.8% out of the box, below the frontier models. After training on Bridgewater’s own expert-labeled data, it reached 84.7% and made about 30% fewer mistakes than the best frontier model they tested, at roughly one fourteenth the inference cost per task.

Qwen3-235B is public; anyone can download it. Bridgewater chose it precisely because its fine-tuning behavior is well documented in the literature. What Bridgewater had that nobody else had was their labeled data, and a process for making that data trustworthy.

The loop, concretely

Bridgewater’s first attempt used a vendor for non-expert labeling. Models trained on that data performed badly. Reading the model’s reasoning traces, the team realized the labels themselves were frequently wrong. Expert investors could produce correct labels, but expert time is the most expensive input in the system, so labeling everything by hand was not viable.

The fix was a routing scheme for human attention. They trained a model on the cheap labels, then evaluated it against the same data it had just trained on. Every example where the model disagreed with its own training label went to an expert for review. The logic: if a model cannot reproduce a label from its own training set, either the example is genuinely hard or the label is wrong. Both cases should be checked by an expert.

The loop looks like this:

  • Capture judgment: experts define what a good answer looks like, on tasks drawn from real work.
  • Build the eval first: six tasks, each with a defined metric and a held-out test dataset that training never touches.
  • Find the disagreements: use the model’s own errors to locate the examples where the data is untrustworthy.
  • Spend expert time on disagreements: route contested examples to people, leave the rest alone.
  • Test the recipe, not just the model: Bridgewater removed each piece of their training setup one at a time and re-measured, so they knew what every piece was contributing.
  • Feed the result back: the cleaned dataset and the improved model both become inputs to the next iteration.

 

None of those six steps depend on which base model sits in the middle. Swap Qwen3-235B for something released next quarter and the loop still runs.

Two weeks after the Bridgewater post, Thinking Machines released Inkling, a 975B-parameter Mixture-of-Experts model (41B active) with full weights on Hugging Face, available for fine-tuning on Tinker, their managed post-training platform. Thinking Machines said plainly that Inkling is not the strongest model available, open or closed. They positioned it as a broad, adaptable base, and built the business around customization, inference, and deployment. The company shipping the open model is betting on the loop too.

Three ways the model stops being enough

Taking a bird’s-eye view of the AI space, the same conclusion appears from three different directions.

1. You cannot reliably serve it

A model that looks excellent on a public benchmark, but cannot meet your latency, capacity and availability requirements is a substantial risk.

That risk is coming from several events hitting all at once. Pricing keeps changing to keep up with compute demand. Providers can’t always serve the demand either: when Moonshot released Kimi K3, throughput dropped from 30 tokens per second to 13, and they had to pause new subscriptions just to protect existing users. On top of that, governments are stepping in too, with frontier models getting pulled because of security and geopolitical risk. It’s an all-around crunch on model and provider availability.

And when you think that routing solves all your problems, think again. A router owned by a model vendor has an incentive to prefer its own inventory. A gateway can become a toll booth of its own. The enterprise value comes from preserving the right to change routes while keeping policy and the developer workflow intact.

2. Owning the weights does not create differentiation

Bringing open weights into your stack can create real strategic value. They enable private deployment, offline use, regional control, customization, and greater independence from hosted APIs.

Local coding models are also becoming genuinely useful. Teams can now run capable coding models on workstation-class hardware for workflows that would have required hosted inference not long ago.

But two companies running the same model do not gain the same result if one has better context, labels, evaluations, engineering standards, and feedback loops.

3. Renting intelligence can externalize the learning

Alex Karp from Palantir made this case in a CNBC interview. He asked: “Who controls the models, who controls the weights? Who controls the value of your business?”

Karp argued that enterprises should retain control over their compute, models, data stack, and their “alpha,” the unique insight that separates their returns from the market’s. He described what enterprise leaders told him as paying for “tokens that create no value,” and said customers want to know they “own the means of production.”

External models clearly create value, or enterprises would not be buying them, but organizations should not rent intelligence without retaining the learning.

If every prompt, workflow, and eval stays trapped in a vendor-specific product, the organization is building a dependency rather than an asset.

The moat is the governed loop

Databricks CEO Ali Ghodsi makes a similar point from another angle. In a May 2026 CNBC interview, he said: “AI doesn’t have an intelligence problem. AI has a context problem. How do we feed it that context? And that context is in the data.”

Put all of these arguments together, and they all point at the same thing: general intelligence becomes enterprise value only once it’s connected to organizational knowledge and an operating system to use it. That system is a loop, not a single product: route work to the right model, feed it organizational context, capture expert judgment, evaluate outcomes, govern the path to production, and feed learnings back. The system improves because the organization learns and evolves.

This layer only becomes a moat under two conditions: it has to stay neutral enough that the organization can change models, providers, and infrastructure without replacing the workflow around them, and it has to be the organization’s own: context, evaluations, policies, judgment, and operating history that stay portable.

If you can’t leave a vendor, everything you built inside their tool belongs to them too. If you can leave any vendor but nothing accumulates while you’re there, you have flexibility and no advantage, because your competitor can buy the same flexibility tomorrow.

Bridgewater’s labeled dataset is the thing worth having. It’s theirs, and it works on whatever model they point it at next.

“AI doesn’t have an intelligence problem. AI has a context problem. How do we feed it that context? And that context is in the data.”

—Ali Ghodsi, CEO, Databricks

Why Kilo and Anaconda fit this shift

Stay neutral, stay yours. Those two conditions are what Kilo and Anaconda, together under one roof are built around.

Kilo enables developers to work across frontier, open-weight, and local models, with their own keys and providers, in the tools they already use, and organizations decide which routes are approved. Anaconda offers trusted packages, reproducible environments, and model governance, so what you build stays auditable and portable when the model underneath changes.

The value of the combination is that Kilo and Anaconda are aligned around an architecture in which the model can change while the organization’s standards, context, evaluations, and production learnings compound.

Freedom to choose

We have already argued that the future of AI is open and closed models working together, and that routing and model freedom are becoming core infrastructure.

The winners will own their intelligence, and the compounding factor will be the organizations’ ability to build a strong feedback loop.

Learn more about how Kilo and Anaconda work together to build that loop.