The case for specialized intelligence.

Over the past few years, frontier LLMs have kept pushing the boundary of what a model can do. From conversation to coding agents, general-purpose models have shown enormous value.

We believe there is another opportunity of equal importance: embedding intelligence directly into applications, data pipelines and workflows, so that a large number of tasks that used to depend on people, rules or traditional machine learning can be automated.

These tasks come in three kinds: decisions, which cover classification, routing and matching; extraction of fields and records from text and documents; and judging, which scores and verifies an output against a rubric. They do not necessarily need complex multi-step reasoning. They do need intelligence that is reliable, repeatable and callable by programs at large scale.

Why specialized language models

Traditional machine learning can be very efficient on a fixed task. But for tasks that need deep semantic understanding, labels that change and business rules that keep moving, it usually means collecting training data, building features, retraining and maintaining a model for each one.

Frontier LLMs offer another option. With the language understanding and generalization they gain in pretraining, they can handle many tasks they were never specifically trained for, given a natural-language instruction. But for large, high-frequency workloads, the compute a general-purpose model spends can be far more than the task actually needs.

We believe specialized language models are filling the gap between the two.

They inherit the semantic representations of a pretrained language model, and are then optimized for one class of task through task-specific post-training and purpose-built architectures.

For example, some of these models let you define new classification labels in natural language, or specify the fields to extract with a dynamic schema, without training a new classifier from scratch for every task.

They can generalize existing knowledge to new inputs, labels and tasks to a meaningful degree, while using dedicated prediction heads, parallel scoring or other non-autoregressive mechanisms to avoid the computation a general generative model would spend for nothing.

Specialization doesn't have to come at the expense of generalization.

When these capabilities are reliable enough and economical enough, developers can apply intelligence to huge volumes of data and tasks, instead of only the few scenarios that justify the cost of AI.

We believe this will create a large number of automated applications that were not economically viable before.

Understanding the boundaries of models

More and more specialized models are being developed today.

But we think the next important thing is not just releasing new models. It is understanding their limits.

A model that handles new labels zero-shot does not necessarily handle every unseen domain correctly. The generalization that comes from pretraining does not mean the model naturally copes with distribution shift or concept drift.

A model that scores well on a benchmark is not necessarily ready for production.

We need to understand how a model behaves under different tasks, data distributions and business constraints: accuracy, calibration (a 0.9 should be right about nine times in ten), robustness, latency and failure modes.

We also need to know when traditional ML is still the better choice, when a frontier LLM is needed, and when a specialized model offers a real advantage.

Understanding what models cannot do is just as important as understanding what they can do.

This is why we take model evaluation seriously.

By evaluating existing models systematically, we hope to find out which capabilities are mature enough, where the clear technical gaps are, and which new models are actually worth building.

Our first benchmark is for judge models, the ones that score an answer or an agent's trace against a rubric. It is the use where calibration matters most.

The teams adopting these models already work this way: a specialized model is evaluated on each task, against the model in production, and swapped in only where it wins. We hold ourselves to the same rule. A new kind of model earns a place in our catalog only when it beats the existing ones on accuracy per dollar for the same task; otherwise it is a new name for an old model.

We do not want to release models for the sake of releasing models. We want to push the boundary of what specialized intelligence can do.

The right compute for the right model

Models are only part of the story. For intelligence to reach machine scale, the compute underneath has to be rethought too.

Different models have different computational characteristics.

Decoding in an autoregressive LLM is usually bound by memory bandwidth and the KV cache, which is why the capacity and bandwidth of HBM matter so much.

But many specialized models do not need to generate many tokens, and some do not depend on autoregressive decoding at all.

For these models, at a suitable batch size and model size, compute throughput can matter more than HBM bandwidth. They may well run with better inference economics on GPUs with GDDR memory.

This is not to say specialized models never need HBM. It is to say the choice of GPU should follow from the model architecture, memory footprint, batch size, latency target and the actual workload.

The right GPU isn't necessarily the most powerful one. It's the one that best matches the model and workload.

We also believe that as GPU supply keeps growing, compute will be spread across more hardware architectures, cloud providers and capacity markets.

What will be needed is a layer that brings these GPUs together and provides unified inference infrastructure on top of them. Think of it as a fungible pool of GPU capacity: any job can land on any card that fits its model, and a job with a completion window can also move in time.

Capacity enters the pool on one condition: the provider has passed our security review, and zero data retention is part of it.

Different workloads should get different execution and resource strategies.

Real-time inference needs stable, continuous capacity and predictable latency. For tasks that can accept a flexible completion window, we can use batch scheduling, together with the right mix of spot, on-demand and reserved capacity, to raise GPU utilization and execution efficiency.

What really matters is not optimizing the model, the GPU or the token price in isolation. It is considering the model, the workload and the compute together.

The right model, on the right compute, at the right time.

Why we're building Recurrence

This is why we started Recurrence.

We build, evaluate and serve specialized language models, and develop and optimize them further where it is worth doing.

Alongside the models, we build the inference infrastructure around them: real-time and flexible batch, on GPUs matched to each model's compute profile, across hardware architectures and capacity markets.

We care not only about what a model can do, but about whether it can go into production reliably and keep running at sound economics.

We believe the future of AI belongs not only to ever more powerful general-purpose models, but also to specialized intelligence that can be embedded widely in real applications and automated systems.

Intelligence at machine scale.