Should you post-train your own model?

General frontier models, both open and closed, are improving quickly. In many cases, they are the right starting point. If you are building a 0-to-1 prototype, trying to understand a workflow, or getting water running through the pipes, you should use the strongest general model available and move fast.

But for the handful of power-law use cases that are critical to your company’s mission, product, and margin, the answer is increasingly yes: you should post-train your own model.

Your most important use cases are usually where your differentiated data lives. They are where your users create traces, your experts make judgments, your systems record outcomes, and your business has a specific definition of “good” that a general model does not share. A frontier model can get you started, but it will not automatically learn the private operating knowledge that makes your company different.

This is especially true when the use case has hard constraints around cost, latency, reliability, or product experience. A general model locks you into one tradeoff between these characteristics. Post-training gives you agency: you can push the model toward stronger performance on your specific tasks while also improving cost and latency.

Custom models can mean frontier-level quality at a fraction of the cost. It can mean latency low enough to put intelligence directly in the flow of real-time user actions. It can also mean a model that runs continuously because the economics finally work. For instance, a custom model that is 10x cheaper on vulnerability detection is not only cheaper, it also enables a new product that scans constantly instead of occasionally.

This is why the leading AI-native companies – many of whom we work with – are moving first. As the largest token consumers today, they understand the financial and strategic pressure to go custom. The broader enterprise market will eventually arrive at the same conclusion.

Companies will not post-train everything, nor should they. Most use cases will continue to use general models, retrieval, tools, and orchestration. But the “bread and butter” workflows that define a company’s differentiation should not be permanently outsourced to a rented generalist. Companies that do that will effectively commoditize their differentiation since every other competitor has access to the same generalist models.

If you are spending $100M a year on frontier inference for a critical function, moving that workload to a custom model you own is one of the highest-leverage projects your company can undertake.

But it is also a serious technical endeavor. Dozens of companies have shipped self-serve training endpoints, and the reason they rarely become the default path is that the training stack is only one part of the problem. The work is not just calling a training API.

Your product, engineering, and research teams need to work together to identify what to train on, how to build the right environments, how to define success, how to translate that definition into robust reward signals, what a representative eval looks like, which post-training techniques to apply, and how to keep improving the model once it is in production. That is why our work with customers is forward deployed, and it all sits on top of our platform which supports the end-to-end process from task creation to applying frontier post-training techniques.

Hundreds of billions of dollars will be spent by enterprises over the next few years as they deploy AI systems and serve models inside their products and operations. A small number of power-law use cases will make up a disproportionate share of that spend, and custom models optimized for those use cases will drive ROI and differentiation.

TL;DR – you should post-train your own private model for a use case if:

• You own proprietary data specific to the use case.

• The use case has high inference volume.

• The use case is mission-critical and worth differentiating on.

In the process, make sure you:

• Build evals and reward signals that reflect your actual definition of good.

• Choose the post-training approach that matches the problem.

• Instrument your production deployment so the model improves as it is used.