The AI Engineering Cost Model
AI engineering spend breaks into three buckets: fixed seats, semi-fixed seat allowances, and variable API usage. Most organizations budget for the first and get surprised by the other two. The industry moved from per-seat to usage-based pricing in 2026, and the same shift is reshaping build-vs-buy decisions for the tooling wrapped around every agent.
Last reviewed: September 2026
Why the API Bucket Surprises Everyone
Seats are committed in advance and easy to forecast. Seat allowances are a known pool that resets every month. The third bucket - anything in CI, any unattended agent, any custom tooling - has no natural ceiling. Cost scales directly with usage, and usage scales with how many workflows quietly call a model in the background, on every commit, every pull request, every scheduled run.
This is also the bucket finance teams do not see coming, because it does not show up as a line item until the invoice does. A per-workflow habit that seemed free in testing can multiply across every repository once it ships, and overage on a shared credit pool at published model rates is variable cost wearing a seat's clothing. Treat the API bucket as its own budget line with its own controls, not as an extension of the seat contract.
Three Cost Buckets, One Budget Line
Seats, Fixed
Committed in advance. The lever is the mix: premium seats for engineers living in an agentic tool all day, standard seats for everyone else. A developer hitting overage on a standard seat every month is a mispriced seat, not a budget problem.
Seat Allowances, Semi-Fixed
Seat products now bundle a monthly credit pool: GitHub AI Credits since 06-2026, following GitHub's April 2026 move to usage-based billing, plus GitLab Credits since 01-2026, Anthropic's premium-seat usage tier, and Cursor's per-run Bugbot. Coding agents, AI review, and cloud agent sessions all draw from the same pool, often alongside CI minutes. Model the burn before enabling unattended agents - the pool empties faster than anyone expects.
API, Variable
Anything in CI, any unattended agent, any custom tooling. This is the bucket that surprises you: no seat cap, no bundled pool, just usage times rate. It needs its own controls, covered next.
Controls for the Variable Bucket
-
Per-workflow token budget. Cap what a single workflow can spend before it runs, not after.
-
Spend tagged by repo, workflow, and ticket. Without tags, a spike is a mystery instead of a lead.
-
Hard monthly cap, alert at 70 percent. A hard stop plus an early warning, not just one or the other.
-
Per-user spend caps on seat plans. So overage on a single account cannot run away unnoticed.
-
Unattended work budgeted per PR. An agent working without a human in the loop gets a spend ceiling for that unit of work, same as a human's time would be estimated.
-
Prompt caching and batch APIs. Use them wherever the vendor offers them - the same review workflow can cost 2 to 10x more without them.
-
Model routing. Send each task to the cheapest model that passes the eval for that task class, not the best model available for everything.
Unit Economics to Report
-
Agent spend per merged PR, broken out by workflow.
-
Review agent cost per PR.
-
Cost per escaped defect prevented - an estimate, but track it anyway.
The rule that matters: if the fully unattended lane's cost per merged PR exceeds the loaded cost of a human doing the same class of work, the work class is wrong, not the idea. That comparison is what turns unattended agent lanes from a bet into a measured decision.
Build vs Buy: Four Positions
| Approach | Internal Control | Description |
|---|---|---|
| Vendor first | 10% | Commercial products as the primary AI layer, minimal internal tooling, ride the vendor roadmap. |
| Guardrail layer | 50% | Vendor provides the model and the tools, the organization builds the governance wrapper: instruction files, review rules, logging, data classification, policy compliance, evals. |
| Hybrid Recommended | 60% | Vendor tools for general-purpose work, internal tooling for sensitive or domain-specific workflows. Route by data sensitivity and task type with explicit routing rules. |
| Internal tooling | 90% | Open or fine-tuned models in house. Maximum control over data, behavior, and proprietary integration. A significant engineering investment that few organizations recoup. |
McKinsey's August 2026 edition of "The state of AI" found that 32% of organizations decided against buying at least one software product because they built it in-house with agentic coding tools. Build-vs-buy now applies to the tools around the model, not only the model itself.
The pattern holds across the four positions: the guardrail layer - instruction files, review rules, skills, evals, evidence generation - is almost always built, because it encodes what is specific to the organization. The model and the harness underneath it are almost always bought, because a vendor amortizes that engineering investment across far more customers than any single team can.
Where It Fits in AIDLC
Cost decisions land in every phase. Analyze is where build-vs-buy gets decided - which workflows route to vendor tools and which get internal guardrails. Ideate scopes work against the unit economics, so a proposal that cannot clear the cost-per-merged-PR bar gets reshaped before it starts. Develop is where the API bucket actually burns - CI runs, unattended agents, custom tooling - and where the seven controls apply directly. Launch draws down seat allowances through cloud agent sessions and AI review at merge time. Curate is where the unit economics get reported and fed back into next quarter's seat mix and build-vs-buy calls.
Frequently Asked Questions
Most budgets account for seats, a fixed and predictable cost. They miss the other two buckets: seat allowances that bundle a shared credit pool for coding agents and AI review, and API usage from CI runs, unattended agents, and custom tooling. The API bucket has no natural ceiling, so spend can climb quickly once a workflow starts calling a model on every commit.
Set a hard monthly cap with an alert at 70 percent, tag spend by repo, workflow, and ticket, and give every unattended workflow a per-run token budget. Route each task to the cheapest model that still passes its evaluation rather than the most capable model available, and enable prompt caching or batch APIs wherever the vendor offers them, since the same workflow can otherwise cost several times more.
Rarely, for the model and the harness - those are almost always bought, because a vendor amortizes the engineering investment across far more customers than a single team can. The guardrail layer around them - instruction files, review rules, evals, logging, policy compliance - is almost always worth building, because it encodes what is specific to the organization and few generic products cover it well.
Put a Number on What Agents Cost
Report unit economics alongside the rest of the metrics that prove agentic work is paying off.