Appearance
Billing
Forge Pool uses a usage-based billing model centered on Credits consumed by verified execution.
Customers are billed for computational work that is actually executed, attributed, verified, and finalized through the canonical execution accounting system.
Forge Pool does not treat billing as a detached financial layer.
Billing is structurally tied to:
- execution
- replay
- attribution
- settlement
- ledger-backed accounting
This ensures that economic activity remains connected to measurable computation across the runtime.
By default, Forge Pool does not require long-term commitments for standard usage.
For larger deployments, Forge may support:
- reserved execution capacity
- dedicated execution domains
- isolated infrastructure environments
- hybrid enterprise deployments
- custom commercial agreements
1. Billing Principle
Forge Pool billing is designed around one core principle:
Pay for verified execution, nothing else.
Customers are billed for attributable computational activity rather than:
- idle infrastructure
- nominal hardware ownership
- theoretical capacity
- opaque platform allocation models
This keeps pricing aligned with useful execution instead of infrastructure complexity.
2. Relationship to Execution Accounting
Billing is downstream of execution accounting.
Workloads pass through the canonical execution lifecycle:
text
request
→ planning
→ execution
→ verification
→ aggregation
→ settlement
→ finalized ledger recordOnly finalized execution records become eligible for canonical billing.
Billing therefore depends on:
- verified execution
- finalized settlement state
- replay-compatible attribution
- ledger-backed accounting records
See Execution Accounting.
3. What Customers Pay For
Customers typically pay for:
- Credits consumed by verified workloads
- finalized execution activity
- replay retention where applicable
- artifact-heavy execution classes
- reserved execution commitments
- dedicated or isolated execution domains
- custom adapter or integration work
- enterprise operational features where applicable
Exact billing behavior may vary by:
- workload type
- execution class
- deployment model
- enterprise agreement
- governance policy
4. What Customers Do Not Pay For
By default, customers do not pay for:
- idle nodes
- failed shard retries
- internal orchestration overhead
- discarded invalid execution
- platform maintenance operations
- unattributed runtime activity
- internal recovery operations
This preserves alignment between cost and attributable execution.
5. Credits and Billing
Credits are the normalized accounting unit across Forge workloads.
Billing uses Credits to express execution consumption independently from:
- hardware type
- infrastructure ownership
- provider topology
- machine class
Credits derive from finalized execution accounting records.
See Credits.
6. Billing States
Workloads may move through several accounting and billing states before final settlement.
Illustrative states may include:
| State | Meaning |
|---|---|
| Pending | Accepted but not finalized |
| Running | Active execution in progress |
| Verifying | Under execution validation |
| Aggregating | Final reduction and artifact assembly |
| Finalized | Eligible for canonical settlement |
| Failed | Invalid or incomplete execution |
| Disputed | Under operational or commercial review |
| Adjusted | Corrected after reconciliation where applicable |
Only finalized execution contributes to canonical billing.
7. Replay and Billing Integrity
Replayability is part of the billing trust model.
Replay support may allow organizations to:
- validate historical execution
- investigate anomalies
- reproduce settlement conditions
- audit workload attribution
- verify accounting correctness
Replay references may remain associated with:
- execution records
- workload identity
- settlement metadata
- provider attribution
- accounting traces
Replay does not necessarily imply free re-execution.
Commercial treatment of replay workloads may depend on execution policy and agreement.
8. Invoicing
Billing is typically invoiced:
- monthly
- post-paid
- in EUR or USD by default
Other arrangements may be supported by agreement.
Invoices may include:
- total Credits consumed
- workload-level usage summaries
- project or organizational breakdowns
- adapter-level attribution
- replay retention usage
- reserved execution commitments
- enterprise-specific contractual items
Invoices are derived from finalized accounting records.
9. Enterprise Controls
Forge Pool supports enterprise governance and budgeting controls.
Illustrative controls may include:
- soft usage limits
- hard execution caps
- organizational quotas
- per-project billing scopes
- finance notifications
- operational alerts
- exportable accounting records
- reconciliation workflows
These controls allow organizations to experiment safely while preserving operational discipline.
10. Usage Visibility
Forge Pool may expose billing and accounting visibility through dashboards and APIs.
Illustrative visibility may include:
- current billing cycle usage
- projected consumption
- top workloads by execution volume
- provider attribution summaries
- replay-linked accounting records
- anomalous usage detection
- historical consumption trends
This supports:
- forecasting
- procurement review
- internal reconciliation
- chargeback and showback workflows
- operational auditability
11. API and Programmatic Access
Where enabled, billing and usage data may be accessed programmatically for:
- internal dashboards
- accounting reconciliation
- finance automation
- governance workflows
- enterprise reporting
- operational analytics
Programmatic access may depend on deployment policy and permission scope.
12. Pricing Tiers
Forge Pool may support commercial tiers such as:
- Starter
- Growth
- Enterprise
These tiers are illustrative operational categories rather than a universal static price list.
Commercial behavior may vary depending on:
- workload class
- execution scale
- replay requirements
- governance expectations
- support scope
- deployment model
13. Relationship to Economic Integrity
Billing is one component of a broader execution-native economic system.
Billing trust depends on:
- deterministic attribution
- replayability
- provider integrity
- verification systems
- settlement correctness
- ledger-backed accounting
See Economic Integrity.
14. Future Evolution
The billing model may evolve to support:
- specialized execution classes
- marketplace-native settlement
- delegated enterprise accounting
- advanced replay accounting
- hybrid infrastructure billing
- execution-priority guarantees
Future expansion will preserve deterministic accounting principles.
15. Summary
Forge Pool billing is designed to be:
- execution-native
- usage-based
- replay-aware
- auditable
- enterprise-compatible
- provider-aware
It aligns economic activity with verified computation and avoids charging customers for idle infrastructure complexity.
Billing in Forge Pool is derived from finalized execution — not detached infrastructure estimation.