Class1 pilot pricing and deployment options

A free advisory comment is useful because it spreads the mental model: reviewers learn to ask about P90, model fit, retries, context, fallback, and escalation. That education creates trust and gives teams a low-friction way to evaluate Class1 on public or local code. It shifts the culture of engineering teams without requiring immediate financial commitment.

The paid value starts when the report changes the merge outcome. Private repositories, blocking policy gates, estimate persistence, actuals ingestion, private rate basis, and monthly variance reporting are organisational controls. Those are the parts a team pays for because they change behaviour. A CFO doesn't buy a dashboard; they buy the ability to enforce a budget.

The pilot should be sold around one budget owner and one repository first. The first week proves installation and PR comment value. The first month proves whether actuals can be paired. The second month is where the flywheel starts: repeated workflows move from rough class estimates toward locally calibrated control. This staged rollout prevents pilot fatigue and delivers demonstrable ROI at each checkpoint.

At the heart of our platform lies a strict adherence to the principles of cost engineering, adapted for the unpredictable nature of Large Language Models. Unlike traditional software where compute costs are deterministic and tied directly to traffic, AI feature costs are highly variable. They depend on model selection, input token length, output token variability, the frequency of retries due to hallucinations or malformed JSON, and dynamic fallback chains.

To capture this complexity, Class1 employs Monte Carlo simulations using Common Random Numbers (CRN). By modeling the system before and after a pull request across thousands of synthetic scenarios, we isolate the true cost delta of your architectural change from background noise. This approach allows us to assign an AACE (Association for the Advancement of Cost Engineering) estimate class to the forecast, communicating both the expected cost and the confidence interval.

Furthermore, this estimation does not happen in a vacuum. The Blue Book ledger records historical execution data, creating a closed-loop calibration system. As your team merges changes and actuals are observed in production, the engine updates its actuarial tables. This continuous feedback loop ensures that our pre-merge budget gates remain accurate and actionable, preventing catastrophic cost overruns before they reach production while maintaining developer velocity.