The two AI project types have fundamentally different cost structures. Here is how to build a credible estimate for each — from the work breakdown structure to the final budget submission.

Most AI project cost estimates treat two fundamentally different types of work as though they are the same problem. They are not. Model development and LLM integration have different effort drivers, different cost structures, and require different estimation approaches.

Ask an engineering team to estimate an AI project and one of two things typically happens. Either they apply a standard software WBS and discover mid-delivery that AI model development does not behave like software development. Or they produce a number — usually a gut-feel multiple of a previous project — that satisfies the approval process but provides no analytical basis for managing cost through delivery.

Neither approach is estimation. Both produce the same outcome: a figure that diverges from actuals at a rate that damages programme credibility and executive confidence.

This article provides a complete breakdown of how to estimate AI project costs accurately — covering the two project type distinction, the work breakdown structure, role-level labour costing, LLM token cost modelling, infrastructure budgeting, and the common gaps that turn credible estimates into embarrassing surprises. For the shorter, step-by-step version of the overall process — classify the project, build the work breakdown, range each estimate, then roll it up — see How to Estimate an AI Project.

Step One: Establish Which Type of AI Project You Are Estimating

Before any estimate is built, one decision determines the entire cost methodology: whether the project involves building and training a machine learning model, or whether it involves building application logic that consumes an existing model via API.

These are not the same problem. They have different primary effort drivers, different cost structures, and critically — different non-linearity profiles. Mixing up the approaches produces estimates that are wrong not just in magnitude but in structure.

Applying non-linearity multipliers to an LLM integration project overstates costs by 40–80%. Applying linear estimation to a model development project understates costs by the same margin. The type selector is the most important decision in the estimation process.

Step Two: Build the Labour Cost Plan

Labour is the dominant cost category in most AI projects — typically 55–70% of total project cost for model development, and 60–80% for LLM integration. Getting the labour estimate right is the foundation of the entire cost model.

The Work Breakdown Structure: 36 Activities Across 6 Phases

A credible AI project WBS covers six phases and pre-defines the activities within each. The default structure below reflects industry-standard AI delivery practice. Phase names can be customised — what matters is that all 36 activity types are accounted for, even if some have zero effort in a specific project context.

Effort Reference Ranges: Calibrating Your Estimates

The table below provides indicative effort ranges by project scale as a calibration reference. These are base figures before non-linearity adjustment for Model Development projects. Use them as a starting point and adjust based on team seniority, organisational context, and the non-linearity multiplier from your factor scoring.

These are base effort figures. For Model Development projects, the non-linearity multiplier is applied per phase on top of these numbers — Phase 3 at full multiplier weight, other phases at fractional weights. Never submit base figures to a budget committee without NL adjustment.

The Eight AI Delivery Roles and Their Rate Structures

Labour cost is calculated at role level — not as a blended headcount number. Blended rates obscure the cost structure of the project and make it impossible to identify which workstreams are over- or under-resourced. A proper AI cost model specifies effort and daily rate for each of the eight core delivery roles.

Daily rates should be all-inclusive: base salary, employer taxes, benefits, and direct on-costs. Rates will vary significantly by geography, seniority, and delivery model (staff augmentation, consultancy, or permanent hire). Always validate against your organisation's actual rate card or current market rates before submission.

Overhead and Contingency: Two Lines That Most Estimates Undercount

Two cost lines consistently appear in actuals but disappear from estimates: overhead burden and contingency reserve.

•       Overhead / burden rate: Indirect costs applied to labour — office facilities, HR support, benefits administration, and organisational overhead. Typical range for AI programmes: 15–35%. A Senior ML Engineer at $750/day with a 25% burden rate has a true all-in daily cost of $937.50. Multiply this across a six-month programme and the gap between burdened and unburdened costs is material.

•       Contingency reserve: A reserve percentage applied to the total base cost. Not a substitute for proper risk modelling — but a necessary buffer for the residual uncertainty that structured estimation cannot fully capture. Typical range for AI projects: 15–25%, skewed toward the upper end for novel domains or poor data readiness scores.

Step Three: Model LLM Token Costs (For Integration Projects)

For LLM integration projects, API token costs frequently become the largest single cost category at production scale — overtaking labour, infrastructure, and every other line item. This is also the cost category most commonly absent, underestimated, or treated as a rounding error in initial estimates. Once the system is in production, that per-call cost becomes a recurring annual budget line rather than a one-time estimate — covered in Budgeting AI Token Costs for 2027: Plan on Consumption, Not Licences.

How Token-Based Pricing Works

LLM providers charge per token — a sub-word unit of text, where approximately 750 words equal 1,000 tokens in English. Pricing has two components: input tokens (the prompt, context, history, and any retrieved content sent to the model) and output tokens (the model's generated response). Output tokens are consistently priced higher than input tokens because generation is computationally more expensive than reading.

The Five Variables That Determine Your Monthly API Bill

LLM Pricing Tier Reference

The table below provides indicative pricing tiers covering the full spectrum from frontier to open-source models. Always validate against your provider's current published or negotiated rates — LLM pricing has been declining rapidly and point-in-time figures become outdated quickly.

A Worked Example: The Chatbot Nobody Budgeted For

Step Four: Build the Infrastructure and Licensing Budget

Infrastructure and licensing costs are the third major cost category — after labour and API costs — and the one most likely to contain unpleasant surprises. The table below covers the four sub-categories that a complete AI infrastructure budget must address.

A single A100 GPU running continuously for one month costs approximately $2,300. A large-scale model training programme requiring 200 GPU-hours per training run across 15 iterations generates $69,000 in compute costs before any other line item is counted. Validate compute estimates directly with your ML engineers — do not carry them as a percentage of labour.

Step Five: Assemble the Complete Cost Model

A complete AI project cost model is not a spreadsheet with one total. It is a structured document with five explicit layers, each independently defensible and traceable to evidence.

Once all five layers are assembled, the cost model feeds into three outputs: the P50 base case (the expected cost under most-likely assumptions), the P80 business case figure (the number submitted to the budget committee), and the executive dashboard summary for steering committee presentation.

How to calculate P50, P80, and P90 confidence ranges using PERT three-point estimation, how to build the risk register that informs them, and how to present the full picture to a steering committee is covered in Blog 3 of this series: P50, P80, P90 — How to Present AI Project Estimates That Get Approved.

The Four Cost Lines That Consistently Disappear From AI Estimates

After reviewing dozens of enterprise AI project cost models, four gaps appear with enough regularity to warrant explicit attention.

1. Change Management and Adoption Costs

The investment required to prepare the organisation to use AI outputs effectively is rarely captured in a project estimate. Training programmes, communications campaigns, process redesign, and the productivity dip during transition all have real costs. For programmes where AI is changing how frontline staff work — rather than back-office processing — change management can represent 10–15% of total programme cost.

2. Ongoing Model Maintenance and Monitoring

A deployed AI model is not the end state. It is the beginning of an ongoing cost curve. Data distributions shift. Business rules change. Model performance degrades. The cost of monitoring infrastructure, retraining cadence, and MLOps operations in production is an operational cost — but it must be disclosed in the capital business case, separately from the project investment, so that finance understands the total economic commitment.

3. Data Labelling and Annotation

Supervised learning models require labelled training data. If that labelled data does not exist at the required quality, it must be created — either by internal subject matter experts or via a managed labelling service. A labelling programme for a moderately complex classification task can cost $20,000–$80,000 and take eight to twelve weeks. It is almost always absent from the initial estimate because it only becomes visible when data assessment is completed in Phase 1.

4. Internal Resource Opportunity Cost

The internal engineering time, data team capacity, and business unit involvement diverted from BAU to support the AI programme has a real cost. It does not appear as an invoice. It is not captured in any project management tool. But it represents genuine organisational spend that belongs in the total investment figure — particularly for programmes requiring sustained business unit engagement for requirements validation, UAT, and change management.

AI Project Estimation Model — Viksya

The AI Project Estimation Model from Viksya is an Excel-based framework covering both project types — Model Development and LLM Integration — with a project type selector that activates the appropriate cost methodology. It includes a full 36-activity WBS across 8 roles and 6 phases, a configurable rate card, a token-based LLM cost model with sensitivity analysis from 0.5× to 5× scale, infrastructure and licence cost tracking, and a consolidated cost roll-up feeding the executive dashboard. The non-linearity engine (covered in Blog 1 of this series) applies automatically for Model Development projects.

→ Download the AI Project Estimation Model

Frequently Asked Questions

How do I estimate an AI project cost from scratch?

Start by identifying the project type: Model Development or LLM Integration. For Model Development, build a role-level effort estimate across a 6-phase WBS (36 activities), apply non-linearity multipliers to adjust for data readiness, architecture complexity, training iterations, domain novelty, and infrastructure complexity, then add burdened labour costs, compute infrastructure, MLOps tooling, software licences, and a contingency reserve. For LLM Integration, build the labour estimate separately and add a token-cost model based on daily call volume, average input/output tokens per call, and the selected model pricing tier.

What percentage of an AI project budget should be labour?

Labour typically represents 55–70% of total project cost for model development programmes and 60–80% for LLM integration projects. The remaining cost is split across compute infrastructure (15–25% for model development), API token costs (10–30% for LLM integration at scale), software licences (3–8%), and contingency reserve (15–25%). These proportions shift significantly based on project scale, data maturity, and model tier selection. Zoom out from any one line item and the same project-type, scale, and readiness factors that shift this split are what explain the wide band enterprises see when they ask how much an AI project costs overall — see How Much Does an Enterprise AI Project Cost, and What Drives the Range for how those drivers compound.

How do I estimate LLM API token costs for a production system?

Build a per-call cost model: multiply daily call volume by the per-call cost, where per-call cost equals (average input tokens / 1,000,000 × input price) + (average output tokens / 1,000,000 × output price). Then apply a sensitivity analysis at 0.5×, 1×, 2×, and 5× of baseline call volume to model adoption growth. Key variables to scrutinise: whether the system uses RAG (which can 3–6× input tokens per call), whether conversation history accumulates across turns, and which pricing tier the model falls into. A full step-by-step walkthrough of sizing each of those inputs — model tier, prompt and context tokens, output length, call volume, and retry overhead — for a single enterprise application is covered in How to Estimate LLM Token Costs for an Enterprise Application.

What daily rate should I use for AI/ML engineers?

Daily rates vary significantly by geography, seniority, and delivery model. As a broad reference: AI/ML Leads typically range $850–$1,100/day, Senior ML Engineers $650–$850/day, Data Scientists $550–$700/day, Data Engineers $500–$650/day, and MLOps Engineers $600–$750/day in major Western markets. Always validate against your organisation's actual rate card or current market benchmarks. Rates in India, Eastern Europe, and Southeast Asia are typically 40–60% lower. All rates should be all-inclusive (base + employer taxes + benefits + on-costs) before applying the overhead burden rate.

Should infrastructure costs be included in the project budget or operational budget?

Development and training compute costs are capital project costs — they are incurred during the programme and end at go-live. Production inference and hosting costs, ongoing MLOps operations, and model retraining cycles are operational costs that continue post-deployment. A complete AI business case must distinguish these two categories clearly. The capital cost belongs in the project investment figure. The operational cost belongs in the total cost of ownership model that informs the NPV and ROI calculation.

How does the AI project cost estimation connect to the AI ROI business case?

The cost model from your project estimate feeds directly into the ROI calculation: total investment (capital cost) is the denominator of your ROI%, the input to your NPV calculation, and the baseline against which your payback period is measured. A project estimate that understates costs will produce an ROI that looks credible in the business case and fails in the post-implementation review. The mechanics of building the complete AI business case — including NPV, IRR, payback period, and scenario modelling — are covered in Viksya's AI ROI Calculator guide: AI Business Case Financial Metrics.

Can this estimation approach be used for Agentic AI projects?

Agentic AI systems — where models take autonomous actions through tool calls, API chains, or workflow orchestration — are architecturally closer to LLM integration than model development, but carry additional cost considerations. Token consumption in agentic systems is often unpredictable because the number of reasoning steps, tool calls, and context accumulation varies per task. Build your token cost model on a worst-case task complexity scenario and apply a wider sensitivity range (0.5× to 10×) than you would for a bounded chatbot use case. Risk-adjusted cost modelling for autonomous agent error scenarios also belongs in the estimate.

Related Reading from Viksya

→ What Is AI Project Non-Linearity — And Why It Breaks Every Estimate (Blog 1 of this series)

→ P50, P80, P90: How to Present AI Project Estimates That Get Approved (Blog 3 of this series)

→ AI Business Case Cost Modelling: The CFO-Ready Framework (AI ROI Calculator series)

→ The Six Dimensions of AI Transformation Readiness (AI Readiness Scoring Model series)