Laravel Mutable Content Ai Laravel Package

Product Decisions This Supports

• Monetization & packaging: Services\Spending (runs(), total(), daily()) plus Run::cost() turn raw AI usage into per-user, per-model, per-currency cost data — the input needed to decide seat-based vs. usage-based vs. credit-based pricing.
• Prepaid credits / quota enforcement: Models\BalanceEntry and Services\Balances (topUp(), setActual(), remaining()) enable a prepaid wallet model (buy credits, draw down by usage) without building a ledger from scratch. remaining() is explicitly an estimate (latest actual + top-ups − subsequent costs), which is fine for gating and UX but not for invoicing.
• Unit economics / margin tracking: the new prices config key with separate cache read/write prices means you can model gross margin per customer, per feature, and per model — and quantify whether prompt caching is actually paying for itself.
• Model routing & cost/quality trade-offs: with cache read/write tokens recorded in the run journal (Run::FIELD_CACHE_READ_TOKENS / FIELD_CACHE_WRITE_TOKENS), you can A/B cheaper models or aggressive caching and measure the cost delta instead of guessing.
• Roadmap sequencing: this release shifts the package from "LLM call wrapper" to "LLM usage accounting layer." If AI cost controls are on your roadmap, this collapses several candidate tickets (metering, wallet, reporting) into configuration + a migration.
• Build vs. buy: for a Laravel app with modest billing needs, adopting this is materially cheaper than wiring a bespoke usage pipeline into your database and billing provider. It does not replace an invoicing engine — budget that separately.

When to Consider This Package

Adopt when:

• You're on Laravel/PHP and already (or about to be) making multi-provider LLM calls in-app.
• You need per-user cost attribution, spend dashboards, or a prepaid credit/wallet UX.
• Your billing tolerance for "estimated balance" is high — i.e., gating and display, not statutory invoicing.
• You can absorb a pre-1.0 dependency: 0.x minor releases may change APIs, and 0.5.0 requires running LovsSeeder and FieldsSeeder after the extend_ai_tables_with_balance migration. Pin versions and read changelogs on every bump.
• You're comfortable owning the prices config: published model prices are your responsibility to keep current, and stale prices silently produce wrong margins.

Look elsewhere when:

• You need an authoritative, auditable money ledger — use a billing platform (Stripe metered billing, Lago, Metronome) and treat this as a feed, not the system of record.
• You require multi-currency FX normalization, tax handling, proration, or invoice generation.
• You need sub-account/team-level hierarchies of spend beyond per-user.
• You're not on Laravel, or you need a stable 1.0+ API contract with deprecation guarantees.
• You need provider-side reconciliation against actual invoices per billing period (balances here are self-computed, not synced from provider billing APIs).

How to Pitch It (Stakeholders)

To executives: v0.5.0 adds the financial plumbing for AI features — per-user cost tracking, spend reporting by day/model/currency, and a prepaid credit balance. That means we can launch usage-based or credit-based pricing without a custom metering build, see gross margin per customer from day one, and cap credit exposure. Treat it as an 80% solution for cost visibility, not a replacement for our billing system.

To engineering: the release is additive — no breaking changes listed. It introduces a prices config (with distinct cache prices), two run-journal fields for cache tokens, Services\Costs / Services\Spending / Services\Balances, and a new ai.balance_entries table via the extend_ai_tables_with_balance migration. Required ops step: run the migration, then LovsSeeder and FieldsSeeder. Because we're on 0.x, pin the version and review each minor bump. remaining() is a computed estimate, so don't let it back authoritative billing logic.

Recommended next steps: spike the migration + seeders in staging, validate Spending::daily() against a week of real traffic, and confirm the prices key is populated for every model we actually call before shipping any customer-facing spend UI.