We were building on these models too. We kept running into the same problems.

What we ran into

Small models lose accuracy

Decision models are cheap to clone, and the small ones are tempting because they run on a laptop. But accuracy falls off quickly below a few billion parameters. The kev family published the clearest curve so far, on its own test suite.

The smallest model is wrong almost one time in three, and its probabilities are much less reliable, with a Brier score of 0.416 against 0.156 at 27B (lower is better). Both matter when you want to automate a decision. A wrong answer with a confident probability is worse than no answer.

The bigger models keep paying off where it counts for automation. From 4B to 27B, the error rate drops from 16% to 11%, the Brier score from 0.242 to 0.156, and only the 27B model holds its accuracy on inputs up to 64K tokens, against 8K for the smaller ones. Part of that gap is the method, since the 27B model was fully fine-tuned and the smaller ones with LoRA adapters.

Large models need datacenter GPUs and heavy post-training

The 27B class and bigger is accurate, but it runs on datacenter GPUs. The base weights alone don't get you there. One small model, Laya, scores 36% on a decision benchmark before fine-tuning and 77% after. In decision models, the fine-tune is the model. Every team that wants the accuracy has to pay for the training, and then for the GPUs.

Size also sets how far post-training can take a model. In a 2026 study of supervised fine-tuning on models up to 235B parameters, bigger models ended up clearly better after the same training, with diminishing returns, and more so with full fine-tuning than with LoRA adapters. More training examples helped every size by about the same fraction (O'Neill et al., 2026; see also Zhang et al., 2024). Larger models also need less data to reach their best. On synthetic training data, an 8B model peaked at 1 trillion tokens, a 3B model only at 4 trillion (Qin et al., 2025). For a decision model whose training set keeps growing, that's the point because a bigger base keeps its lead with every round of new data.

Most open-source projects don't use extensive training data, usually don't clean it enough, and don't enrich it with synthetic data. To be fair, for open source this is too expensive. To get a model that performs well, the whole data pipeline has to be an investment, with continuous training. For us, that means we serve one model while training several others, and we're already preparing the data for the second generation.

Jev can't see images

First of all, a big shout-out to TypeSafe AI, the creators of Jev. They opened up a completely new class of models, and excitement for new use cases. They truly deserve respect for the idea and for the many new approaches that will come with it.

One big missing piece, and a crucial one for us, is that Jev doesn't take images. For many of our cases that's a must. Sometimes an image is the fallback when the text isn't enough, like the photo attached to an insurance damage report or the screenshot in a support ticket. Sometimes there's no text at all, as with a product photo that has to meet listing rules or a design question. You get the point.

Images are just as important for our upcoming extension, a browser-use agent. A web agent also decides based on what it sees, like which button to click, whether a form was filled in correctly, whether a page shows an error and needs a visual fallback, and what to do when there's no DOM at all, as on a canvas. Sometimes it simply looks to double-check. The page's text often leaves out what matters, so the screenshot is part of the state. A decision model that can't read an image can't drive the agent reliably.

In upcoming posts, we'll take these image use cases one by one, from damage photos in insurance claims and screenshots in support tickets to product photos against listing rules and the browser agent.

And our data had to stay in the EU

Many of the decisions we automate run on personal data, like customer emails, invoices and photos. Under the GDPR, every provider that processes that data for you needs a data processing agreement, and every transfer outside the EU needs its own safeguards. So the shortest path to compliance was our own model on GPUs in Paris, run for us by Scaleway, a French cloud provider, with no third-party AI provider in between. When a customer's data protection officer asks where their data goes, we wanted the answer to be simple. It's processed in France.

So we trained our own

Strom is a large vision-language model, fine-tuned on business decisions in currently 14 domains, from insurance and finance to mechanical engineering and office work, with tasks from invoices and contracts to machine logs and web agents. It takes free-form text, JSON or images, and answers named questions with one of the options you define, plus a probability for each option. It speaks the same request format as Jev, with choice, score and noul questions. For its size and precision it needs datacenter-class GPUs.

Why it's an API now

We mostly built Strom for ourselves, for uprelic.com, our main service, which is a co-work chat. In upcoming posts we'll share how this model class can improve chat applications too, because some approaches, like model routing, sound nice in theory but aren't feasible yet. At the same time, it was a no-brainer that other teams have the same needs, like decisions they want to automate, data that should stay in the EU, inputs that are often images and a dirt-cheap workflow pipeline, but no capacity to build and continuously improve a model themselves.

So we're opening it up. Strom costs $0.042 per million input tokens, and output is free, the same per token as Jev.

How Strom performs

One caution before the numbers. A model's own test suite says little about how it compares with others. kev-27B scores 88.9% on kev's own suite, ahead of Jev's 85.7% there, yet no open model has matched Jev overall. Teams build their tests around what their model was trained on, often without meaning to. That applies to us too. So we stick to public benchmarks, point out where our runs aren't fully clean, and keep improving how we measure, with more held-out and independent benchmarks over time.

We measured Strom 1.0.7 in production on October 1, 2026, on public benchmarks whose results for other models are published. Here is what we found, including where Strom is behind.

On par with Jev on JevBench

On the 231 public JevBench tasks, Strom gets 201 right. Jev 1.13 gets 200, according to the published results.

The reasoning model gets everything right, at a median of 2.2 seconds per answer. Strom answered in a median of 136 ms, measured from a client in Germany, network included. Latencies in the published results come from other clients, so only the accuracy and calibration columns compare directly.

Strom's probabilities are well calibrated. An expected calibration error (ECE) of 0.033 means its stated confidence is, on average, about three points away from how often it's actually right. That's what makes thresholds work. If 0.9 means right nine times in ten, your code can act on it.

Strom gets every task right in extraction, intent, routing, policy, tool selection and ordinal scoring. It's weakest on dates and numbers (5 of 15). It also struggles with long policies (12 of 19) and questions that chain several facts (13 of 18). We're addressing these in our next training cycle.

Where Jev is ahead

On the control suites Open-Jev published, Jev is ahead.

The errors have a pattern. In FizzBuzz, Strom never misses "divisible by 5", but says yes to "divisible by 3" for numbers like 13 and 29. Every Mailroom error is a false yes. In JF100, relations, dates and arithmetic account for most misses, while policy rules and discourse are perfect. Here too, we're fixing these in the training data, one family at a time.

An early signal on images

Image JevBench publishes questions and answers, not images, so we rebuilt part of the image set ourselves. On its 128 public preview items, Strom gets 94 right (73.4%). The best system in the benchmark's own preview round got 59.4%. Treat that as a sanity check, not a score, because 68 of the images are ours, and some of our versions are probably easier than the originals. A real comparison needs a run on the benchmark's sealed images.

Speed

Time in the model depends mostly on how much you send. The chart shows medians of 10 requests per point, with fresh content each time, measured in production.

Add your network round trip, which is about 100 ms from Germany. The latency guide has the full measurements, including how more questions and options add up. We plan to run in more locations to bring latency down.

What we're betting on

Eighteen days in, decision models are a category. The format has been rebuilt by an open lab, a runtime, a CDN and hundreds of independent authors. Weights alone won't be the moat for anyone. What's left is what you can't get from a weekend fine-tune, namely calibrated probabilities you can set thresholds on and a continuous data pipeline on infrastructure that processes your data in the EU.

That's what Strom is for. The docs show how to send your first request.

Data and method

We measured Strom 1.0.7 in production on October 1, 2026. For JevBench we used the 231 public tasks with the Open-Jev harness's request format and scoring, and took the results of other systems from the Open-Jev benchmarks page. We rebuilt the control suites (FizzBuzz, Mailroom, JF100) the way Open-Jev built them and checked all 1,521 gold labels against Open-Jev's published rows. Two items in our training data turned out to resemble JevBench tasks, one long policy and one date question, so those two slices aren't fully clean for Strom. The kev numbers come from the kev family's published evaluation (new-source test split), the Laya numbers from Convai Innovations' published model card, and the ecosystem count from Hugging Face repositories with decision-model tags created after September 15, 2026.