About Class1

About Class1 and its cost engineering method

Class1 moves AI cost estimation into code review so engineering and finance can evaluate recurring spend while the architecture can still change.

What Class1 is

Cost engineering for AI systems, applied before merge.

Class1 is a software project for estimating the recurring cost impact of AI code changes while those changes are still under review. It reads a pull request, identifies defensible cost signals, compares a baseline with the proposed architecture, and reports a monthly distribution rather than one falsely precise number.

The product is designed for the moment when engineering choices are still negotiable. Model selection, context size, output limits, retries, fallbacks, tool schemas, and call frequency can all change before merge. After deployment, those choices become production behaviour and eventually an invoice.

Why Pre-Merge Matters

Traditional cloud costs (like compute and storage) scale predictably with traffic. AI costs do not. A single poorly designed prompt, an inefficient retry loop, or a heavy fallback chain can cause costs to spiral exponentially. By integrating into the CI/CD pipeline, Class1 allows engineering teams to catch architectural mistakes before they merge to the main branch.

Our Engineering Philosophy

We believe that engineering and finance should speak the same language. Finance needs predictability; engineering needs velocity. Class1 bridges this gap by using established principles of cost engineering (such as AACE estimate classifications) to provide realistic budget forecasts that developers can trust.

Principles

What the project refuses to fake.

No invented demandCode can reveal cost levers, but it cannot prove future adoption. Unknown volume remains an explicit assumption until measured actuals exist.
No average-only approvalClass1 reports expected cost alongside P50, P90, and deeper tails so budget owners can see uncertainty.
No hidden basis driftModel prices, capabilities, and cost structures are frozen to effective-dated snapshots for reproducibility.
No maturity by assertionEstimate maturity improves through estimate-to-actual reconciliation, not through the volume of telemetry alone.
No blocking by defaultThe estimate starts as advice. A team introduces blocking policy only after it trusts the basis and owns the budget decision.

What exists today

A working engine, a browser estimator, and a pilot governance surface.

Cost engine: paired Monte Carlo analysis, percentiles, sensitivity, escalation, contingency, and estimate classification.

Takeoff: code-diff scanning for model calls, token limits, retries, fallbacks, tools, and related architecture signals.

Blue Book: frozen model pricing, structured rates, specifications, capability evidence, and historical cost bases.

Browser estimator: a local, no-upload demonstration that turns a pasted diff and workload assumptions into a risk-adjusted monthly delta.

Business Pilot: private-repository installation, policy gates, actuals integration, and variance reporting developed with an initial budget owner and repository.

Evaluate it

Start with evidence, not a sales claim.

Review the evidence and limitations, inspect the rate basis, and run the browser estimator. The pilot is intended for teams that want to test the method on one real workflow before expanding governance.

Founder

Leandro Alvarez

Leandro Alvarez is a civil engineer and project controls specialist based in Niagara Region, Ontario. Class1 applies the estimating discipline used on capital projects—quantity takeoff, a traceable private rate basis, uncertainty ranges, estimate classes and actuals calibration—to AI software changes.

The product is built around a practical governance question: before a pull request is merged, what recurring AI cost does it create, how uncertain is that estimate and which engineering control reduces the risk?

Contact Class1 about a pilot or review the methodology, evidence and limitations.