GaaS Pricing Models: How Agentic Services Are Priced
Agentic as a Service can be priced in several ways because the provider is not charging for one simple software feature.
A GaaS task may use:
- one or more AI models;
- hosted compute;
- memory or task state;
- retrieval;
- external tools;
- APIs;
- storage;
- orchestration;
- monitoring;
- human review;
- support; and
- managed workflow operations.
Providers may package these costs into a subscription, charge for individual usage components, price completed tasks, or combine several models.
Buyers should therefore compare the cost of an accepted outcome, not only the advertised price of one request, message, or agent run.
Why GaaS pricing is more complex than software pricing
Traditional software pricing often focuses on access.
A customer may pay:
- per user;
- per month;
- per workspace;
- per feature tier; or
- per storage level.
GaaS pricing must also account for execution.
Two users may have access to the same agent, but one may run a simple classification task while another launches a long workflow involving several models, searches, documents, tools, and approvals.
The provider's cost can vary based on:
- task complexity;
- input size;
- output size;
- model choice;
- number of steps;
- number of tool calls;
- execution time;
- memory use;
- external service charges;
- retries;
- concurrency; and
- support requirements.
This makes hybrid pricing common.
The main GaaS pricing models
Most offers fit into one or more of these categories:
| Pricing model | Customer pays for |
|---|---|
| Subscription | Access to a service tier |
| Per user or seat | Each authorised operator or reviewer |
| Usage-based | Consumed technical resources |
| Per task or run | Each agentic execution |
| Capacity-based | Reserved execution volume or infrastructure |
| Per managed agent | Each deployed or maintained agent |
| Per workflow | Each production process |
| Outcome-based | Accepted completed business results |
| Professional services | Design, integration, testing, and support |
| Hybrid | A combination of fixed and variable charges |
No model is automatically best.
The right structure depends on workload predictability, task quality, risk, and the responsibilities included in the service.
Subscription pricing
Subscription pricing charges a fixed amount for access during a defined period.
A subscription may include:
- a limited number of agents;
- selected models;
- a defined task allowance;
- standard integrations;
- monitoring;
- storage;
- support; and
- administrative features.
Subscription pricing is attractive because it is predictable.
It works well when usage is stable and the included limits match the organisation's needs.
Questions to ask include:
- What usage is included?
- What happens when the allowance is exceeded?
- Are premium models included?
- Are tool charges included?
- Is support included?
- Does unused allowance expire?
- Are test runs billed?
- Are separate environments included?
Per-user or per-seat pricing
Seat-based pricing charges for each person who can use or manage the service.
Seats may be assigned to:
- end users;
- administrators;
- workflow builders;
- reviewers;
- operators; or
- support teams.
This model is easy to understand, but it may not match the actual cost of agent execution.
A reviewer who approves five tasks per month may cost the same as an operator who runs hundreds of complex workflows.
Seat pricing is most useful when access and collaboration are major parts of the value.
It is often combined with usage limits.
Usage-based pricing
Usage-based pricing charges for the technical resources consumed by the service.
Billable units may include:
- input tokens;
- output tokens;
- model requests;
- messages;
- tool calls;
- searches;
- code-execution sessions;
- compute time;
- memory items;
- memory retrieval;
- vector storage;
- file storage;
- network activity; or
- API transactions.
This model can be economical for low or irregular volume.
It can also make monthly cost difficult to predict.
Token-based charges
Language models commonly charge based on input and output tokens.
Agentic workflows can use more tokens than a single chat response because they may include:
- long instructions;
- conversation history;
- retrieved documents;
- tool descriptions;
- intermediate results;
- repeated planning;
- verification; and
- final output.
A task may call the model several times.
Buyers should ask for the average and high-percentile token use per accepted outcome, not only the token price.
Tool-based charges
Tools may have separate charges.
Common examples include:
- web search;
- file search;
- code execution;
- database queries;
- document conversion;
- speech processing;
- image analysis;
- external APIs; and
- paid data sources.
A provider may pass these charges through, add a margin, or include them in a service allowance.
Ask whether one agent step can trigger several billable tool calls.
Compute-based pricing
Hosted agents may consume compute while they run.
Providers may charge for:
- virtual CPU time;
- memory;
- containers;
- runtime minutes;
- reserved instances;
- accelerator use; or
- concurrent execution.
Compute pricing matters for:
- long-running tasks;
- code execution;
- local model hosting;
- large document processing;
- high concurrency; and
- always-available agents.
Idle infrastructure may also create cost.
Memory and storage pricing
Agentic services may store:
- short-term task state;
- long-term memory;
- uploaded files;
- vector indexes;
- logs;
- activity records;
- generated documents; and
- evaluation data.
Pricing may depend on:
- storage volume;
- retention period;
- number of memory items;
- retrieval frequency;
- backup requirements; and
- regional storage.
Memory costs can grow quietly over time.
Buyers should define retention and deletion rules before scaling.
Per-task or per-run pricing
Per-task pricing charges each time the agentic service attempts a defined workflow.
Examples include:
- one research brief;
- one document review;
- one support triage;
- one supplier check;
- one project report; or
- one scheduled monitoring run.
This model is easier to connect to business volume than raw token pricing.
However, the contract must define what counts as one task.
Ask:
- Does a retry count as another task?
- Does a failed run count?
- Does a partial result count?
- Does human review count separately?
- Can one request create several billed subtasks?
- Is a scheduled no-change result billed?
Complexity-tier pricing
Some providers may group tasks into complexity levels.
For example:
- simple;
- standard;
- advanced; and
- custom.
Complexity may depend on:
- number of sources;
- number of tools;
- model type;
- context size;
- expected runtime;
- number of agents;
- approval stages; and
- external actions.
Complexity tiers can improve predictability.
They can also be difficult to audit when the provider controls the classification.
The criteria should be documented.
Capacity-based pricing
Capacity pricing reserves a defined amount of service capability.
Capacity may be measured as:
- monthly tasks;
- concurrent agents;
- processing hours;
- message units;
- workflow executions;
- compute capacity; or
- pooled usage.
Capacity is useful for predictable, high-volume workloads.
It can support budget planning and service guarantees.
The risk is paying for unused capacity.
Ask whether capacity can be shared across teams, agents, or workflows.
Per-managed-agent pricing
A provider may charge for each deployed or maintained agent.
The price may include:
- agent configuration;
- hosting;
- monitoring;
- routine evaluation;
- updates;
- support;
- tool maintenance; and
- reporting.
This model can suit specialist agents with clear ownership.
It becomes less clear when one agent supports many workflows or one workflow uses several agents.
Ask what makes two configurations separate billable agents.
Per-workflow pricing
Workflow pricing charges for each production process.
A workflow may include:
- triggers;
- models;
- tools;
- branches;
- validation;
- approvals;
- destinations; and
- monitoring.
This model can align well with business ownership.
A department can understand the cost of a specific process.
Ask how versions, test copies, and regional deployments are treated.
Outcome-based pricing
Outcome-based pricing charges for a defined accepted result.
Examples may include:
- accepted research report;
- correctly processed document package;
- resolved support request;
- approved account update;
- completed supplier review; or
- verified risk alert.
This model can align provider revenue with customer value.
It is also the hardest model to define fairly.
The agreement must specify:
- what counts as completion;
- required quality;
- required evidence;
- who accepts the result;
- how corrections are treated;
- how exceptions are treated;
- how partial work is treated;
- how human contribution is treated;
- what happens after reversal; and
- how disputes are resolved.
Outcome pricing is not the same as performance marketing
Outcome pricing does not mean the provider should be paid for every broad business result.
A GaaS service may contribute to revenue, retention, risk reduction, or productivity without controlling every factor.
Pricing should attach to an outcome the service can reasonably influence and verify.
For example, “accepted qualified account brief” is easier to define than “sales growth.”
Savings-share pricing
Some providers may charge a percentage of measured savings.
Potential savings may come from:
- reduced labour;
- avoided outsourcing;
- fewer errors;
- reduced rework;
- faster processing;
- lower backlog; or
- reduced operational loss.
Savings-share models require a trusted baseline.
They can create disputes when process volume, staffing, or business conditions change.
Use independently reviewable assumptions.
Revenue-share pricing
Revenue-share pricing connects provider payment to incremental revenue.
It may be proposed for:
- lead qualification;
- sales support;
- conversion optimisation;
- retention workflows; or
- marketplace services.
Attribution is difficult.
Revenue may depend on pricing, brand, sales staff, product quality, market conditions, and other systems.
Revenue-share agreements should define the attribution method and avoid assigning full value to the agentic service.
Professional-services pricing
GaaS implementation may require additional services.
These may include:
- process discovery;
- workflow design;
- integration;
- data preparation;
- security review;
- evaluation;
- migration;
- training;
- custom tool development;
- support; and
- change management.
Professional services may be priced:
- hourly;
- daily;
- by project;
- by milestone;
- by workflow; or
- through a retainer.
These costs belong in the total business case.
Support-tier pricing
Providers may offer different support levels.
Higher tiers may include:
- longer support hours;
- faster response targets;
- named contacts;
- onboarding;
- workflow assistance;
- incident support;
- dedicated environments;
- reporting;
- evaluation help; and
- change-management support.
The right support tier depends on the importance of the workflow.
A business-critical write process may need stronger support than an internal research assistant.
Hybrid pricing
Hybrid pricing combines fixed and variable charges.
A common structure might include:
- monthly platform subscription;
- included user seats;
- included task capacity;
- variable model and tool usage;
- per-agent management fee;
- professional services; and
- premium support.
Hybrid models can balance predictability with fair usage allocation.
They are also harder to compare.
Buyers should create one complete monthly cost scenario for their expected workload.
Hidden GaaS cost drivers
The invoice may not show every cost created by the service.
Internal cost drivers include:
- reviewer time;
- correction;
- exception handling;
- access management;
- monitoring;
- incident response;
- security review;
- provider management;
- employee training;
- workflow maintenance;
- data cleaning; and
- migration.
Technical cost drivers include:
- repeated planning;
- long prompts;
- unnecessary history;
- broad retrieval;
- failed tool calls;
- agent loops;
- duplicate runs;
- premium models;
- long retention;
- high concurrency; and
- unused reserved capacity.
Why failed tasks matter to pricing
A provider may incur costs even when a task fails.
The customer may be charged for:
- model calls;
- tool use;
- compute;
- storage;
- retries; and
- partial execution.
Ask how the provider treats:
- provider-caused failure;
- customer-data failure;
- source outage;
- tool outage;
- validation failure;
- rejected approval;
- cancellation;
- timeout; and
- duplicate prevention.
The pricing policy should not reward endless retries.
Why scheduled tasks can create surprise costs
Scheduled agents can run without a user actively starting each task.
Cost can grow when:
- the schedule is too frequent;
- the source rarely changes;
- several schedules overlap;
- failed tasks retry;
- unused reports continue;
- a workflow remains active after ownership changes; or
- a tool call becomes more expensive.
Review scheduled cost by workflow.
Pause recurring tasks that no longer create value.
Compare cost per accepted outcome
The most useful comparison is often:
Total [GaaS operating cost
÷
Accepted](/gaas/gaas-security-and-privacy) outcomes
Total operating cost should include:
- provider charges;
- models;
- tools;
- storage;
- compute;
- support;
- human review;
- correction;
- exception handling;
- monitoring; and
- allocated maintenance.
Accepted outcomes should meet predefined quality requirements.
This prevents a low-cost but low-quality service from appearing efficient.
Build low, expected, and high-cost scenarios
Estimate at least three scenarios.
Vary:
- task volume;
- average steps;
- model use;
- tool calls;
- context size;
- acceptance rate;
- correction rate;
- exception rate;
- storage;
- support;
- concurrency; and
- growth.
A high-cost case should include abnormal retries and increased review.
This shows how sensitive the offer is to real operating behaviour.
Questions to ask about a pricing proposal
Ask:
- What is the primary billing unit?
- What is included in the base price?
- Which models are included?
- Which tools are billed separately?
- Are failed tasks billed?
- Are retries billed?
- Are test runs billed?
- Is storage included?
- Is memory included?
- Is monitoring included?
- Is human review included?
- Are integrations included?
- Is support included?
- Are there minimum commitments?
- Can unused capacity roll over?
- Are prices different by region?
- How are price changes communicated?
- What does offboarding cost?
Contract protections for variable pricing
Buyers may seek:
- spending limits;
- usage alerts;
- approval before overage;
- task budgets;
- monthly caps;
- retry limits;
- model restrictions;
- tool restrictions;
- transparent metering;
- downloadable usage records;
- notice before price changes; and
- the right to pause execution.
Cost controls should exist at both account and workflow level.
Pricing for local and hybrid GaaS
Local execution changes the cost structure.
Costs may include:
- hardware;
- local model storage;
- electricity;
- device maintenance;
- local MCP services;
- backups;
- administration;
- monitoring; and
- provider management fees.
Local models may reduce some cloud-model charges.
They may increase device and support cost.
Hybrid pricing may combine a managed-service fee with customer-owned infrastructure.
How Feluda relates to GaaS pricing
Feluda can help users understand the components that create agentic service cost.
Workflows may combine:
- local or cloud AI providers;
- MCP tools;
- multiple processing steps;
- RunFlows execution;
- file and data operations;
- scheduling; and
- human review.
A service operator can compare local and remote models, simplify workflows, limit enabled tools, inspect repeated calls, and review scheduled execution.
These controls can help reduce unnecessary model, tool, and operating cost.
Feluda's own product plans are separate from the broader GaaS pricing models described in this article.
Choosing the right pricing model as a buyer
Subscription pricing may fit when:
- usage is stable;
- access is the main value;
- the included allowance is sufficient; and
- budget predictability matters.
Usage pricing may fit when:
- volume is low or irregular;
- the customer wants to pay for actual consumption;
- technical usage is transparent; and
- spending controls are available.
Per-task pricing may fit when:
- task boundaries are clear;
- volume can be forecast;
- failures and retries are defined; and
- tasks have similar complexity.
Capacity pricing may fit when:
- volume is high;
- concurrency matters;
- demand is predictable; and
- reserved service levels have value.
Outcome pricing may fit when:
- acceptance can be defined objectively;
- quality can be verified;
- provider influence is clear; and
- both sides trust the measurement.
Choosing a pricing model as a provider
A provider should choose a billing unit that customers can understand and that reflects service cost.
Good pricing should:
- reward useful outcomes;
- avoid encouraging unnecessary calls;
- remain predictable enough for buyers;
- cover variable model and tool costs;
- support continuous improvement;
- make failures visible;
- avoid hidden overages; and
- scale with delivered value.
A technically convenient billing unit is not always commercially useful.
Customers may understand “approved document review” more easily than “seventy-three orchestration messages.”
Final pricing checklist
Before accepting a GaaS price, confirm that:
- the billing unit is clear;
- included usage is clear;
- overage is clear;
- model charges are clear;
- tool charges are clear;
- compute charges are clear;
- memory and storage charges are clear;
- failed runs are defined;
- retries are defined;
- partial outcomes are defined;
- human review cost is included;
- support cost is included;
- implementation cost is included;
- usage records are exportable;
- spending limits are available;
- price-change terms are clear;
- exit costs are clear; and
- cost per accepted outcome is competitive.
The practical conclusion
GaaS pricing is likely to remain hybrid because agentic services combine software access, AI consumption, tool execution, infrastructure, and managed operations.
Buyers should avoid comparing offers through one headline number.
They should model the complete workload.
Count failed and corrected tasks.
Include internal review and support.
Test high-usage scenarios.
Measure the final cost per accepted outcome.
The best pricing model is not necessarily the cheapest per call.
It is the model that makes cost predictable, aligns payment with useful work, and gives both provider and customer an incentive to improve quality.