Laravel Ai Usage Laravel Package

Product Decisions This Supports

• AI cost attribution and chargeback: instrument per-user, per-tenant, and per-feature token consumption so finance and product can see which surfaces (chat, summarization, search) actually drive inference spend, rather than reading a single blended provider invoice.
• Pricing and packaging: usage data is the prerequisite for tiers, credits, seat-plus-usage hybrids, or overage billing. Without metering you cannot answer "what does a power user cost us?" — this package is the cheapest path to that answer inside an existing Laravel codebase.
• Quota and rate-limit enforcement: hard or soft caps per plan, per workspace, or per API key. Enables a defensible "fair use" policy and protects gross margin from a single runaway integration or prompt loop.
• Build-vs-buy for metering: the realistic alternative is a homegrown ai_usage table, middleware, and reporting job — roughly one to two engineering weeks plus permanent maintenance. This package is the buy/borrow option and should be evaluated against that estimate, not against a commercial LLM observability platform.
• Model routing and roadmap bets: once usage is recorded by model and feature, you can quantify the savings from downgrading a task from a frontier model to a smaller one, and make that a roadmap item with a number attached instead of an intuition.
• Roadmap sequencing: metering is a foundational dependency for billing, admin analytics, and customer-facing usage dashboards. Adopting it early unblocks those features; deferring it means retrofitting instrumentation into code paths that have already proliferated.
• Release signal: v1.0.7 is a patch-level release with no published API changes. Treat it as routine maintenance — it does not alter the adoption calculus, but it does confirm the maintainer is still shipping.

When to Consider This Package

Adopt when most of the following hold:

• You are on a maintained Laravel version and your AI calls already flow through a small number of service classes or a shared client — instrumentation cost is proportional to how centralized those call sites are.
• You need first-party, in-app usage data (per user, team, or feature) that you will join against your own users and teams tables. This is the package's core value and where a SaaS metering product would require exporting data back out.
• You have a near-term monetization or cost-control decision — usage-based pricing, enterprise invoicing, internal chargeback, or quota enforcement — with a date attached.
• Your volume and compliance posture let you store usage metadata in your own database. Token counts, model names, and timestamps are low-sensitivity; if that assumption breaks, reconsider.
• You want a small dependency surface. A niche package from a single-org maintainer is a reasonable bet for a thin instrumentation layer, but only if the fallback (vendor the code, or reimplement against your own schema) is cheap — which here it is.

Look elsewhere when:

• You need full observability: prompt/completion logging, trace-level debugging, latency and error analytics, evaluation and regression tracking. That is an LLM observability platform, not a metering package.
• You need a gateway or proxy with provider failover, caching, and centralized key management. Different layer of the stack.
• The release history is opaque. v1.0.7's changelog is a bare compare link with no described changes. Before adopting, read the actual diff and confirm the version-to-version behaviour, especially anything touching schema migrations or how usage rows are written.
• Your AI traffic is spread across many services or languages. A Laravel-only meter gives you a partial picture; you will end up reconciling against provider dashboards anyway.
• You require vendor SLAs, security review artifacts, or a support contract. This is community-maintained software.

How to Pitch It (Stakeholders)

To executives: We currently pay for AI inference without knowing which customers, features, or plans consume it. That blocks usage-based pricing and leaves us unable to defend our margins if a single account runs hot. This package adds metering inside our existing Laravel application in days rather than the one to two engineer-weeks a custom build would take, and it puts the data in our own database where finance and the admin dashboard can use it directly. It is a small, reversible dependency — if it disappoints, we replace it with our own table because the instrumentation points are the same. The current release (v1.0.7) is a patch with no API changes and no migration risk.

To engineering: This is a thin instrumentation layer, not a framework. It records usage against models, users, and features in our own schema, so there is no new external service, no data leaving our infrastructure, and no runtime dependency on a third party. The integration burden scales with how disciplined our AI call sites already are — if calls are centralized, this is a small PR; if they are scattered, this is a useful forcing function to consolidate them. Caveats to flag: the project is single-maintainer and pre-2.0, so pin the version and read the diff for each bump; v1.0.7 currently ships with an empty changelog, so review the commit range before merging. We should also confirm migration behaviour against our existing tables and decide early whether we own the reporting layer or rely on the package's.

Recommendation: Proceed to a time-boxed spike on one high-volume feature. Success criteria: usage rows land correctly for all model types we call, the data reconciles within a few percent of provider-reported token counts, and per-tenant cost can be queried in one join. Reassess for broader rollout once those hold.