Laravel Ai Usage Laravel Package

Product Decisions This Supports

• Build vs. buy for AI cost/usage telemetry. A drop-in Laravel package that ships ai_usage_records and ai_usage_budget_alerts tables supports the "buy/adopt" side of the decision: instead of building internal token-accounting, per-tenant quota tracking, and alert plumbing, the team adopts a package and spends the saved engineering time on the actual product surface (dashboards, customer-facing usage views, billing integration).
• Feature scoping for usage metering and spend controls. The presence of a dedicated budget-alerts table signals first-class support for thresholds and notifications — useful when deciding whether to ship "usage caps" or "budget alerts" as a v1 feature versus deferring them to a later roadmap slot.
• Monetization and packaging decisions. Usage records are the raw material for metered billing, per-seat/per-token plans, and fair-use policies. This package de-risks a usage-based pricing experiment by giving you the data layer before you commit to a pricing model.
• Roadmap sequencing for multi-tenant and per-customer quotas. If you serve multiple customers or workspaces from one app, the usage-records schema is a prerequisite for per-tenant spend reporting and chargeback — a plausible near-term roadmap item.
• Upgrade and operational hygiene decisions. v0.1.6 fixes a real footgun: re-publishing the ai-usage-migrations tag after an update previously copied every migration again under a new date, so migrate failed on pre-existing tables. The release now publishes only new migrations. This is a reminder to treat migration publishing as a controlled operational step, not an ad-hoc command.
• Vendor/version risk posture. At v0.1.x with a required manual cleanup note (delete duplicated create_ai_usage_records_table and create_ai_usage_budget_alerts_table migrations if you followed the v0.1.4 upgrade note), the package is early-stage. That informs whether to adopt now for internal tooling versus wait for a 1.0 before putting it on a revenue-critical path.

When to Consider This Package

Consider adoption when:

• You are on Laravel/PHP and already use one or more AI/LLM providers; the package's value is highest when you need to persist per-call or per-period usage and act on it.
• You need usage records and budget alerts as infrastructure, not as a bespoke product — i.e., you want the schema, migrations, and alert hooks without owning their maintenance.
• You are prototyping or shipping an internal cost-observability dashboard or an early customer-facing usage page, where a v0.x dependency is acceptable and a breaking change is a contained inconvenience.
• Your migration workflow can absorb manual upgrade steps. The v0.1.6 note requires operators to delete stale duplicate migration files; teams that cannot audit and prune published migrations before migrate runs should pause.

Look elsewhere — or build in-house — when:

• The package would sit on a revenue-critical billing path and you need stability guarantees that a v0.x release does not offer.
• You require provider-specific cost normalization (per-model pricing tables, cached-token rates, currency handling) that a lightweight usage-records schema may not encode; validate the column set against your actual billing needs before committing.
• You are not on Laravel, or your migration policy forbids packages that publish migrations into the host app.
• You need strong tenancy, retention, or PII controls on usage data — confirm the schema and any pruning/retention behavior before storing prompt-adjacent metadata.
• You already run observability tooling (APM, provider-side usage APIs, a warehouse) that can answer cost questions without an application-level table.

Practical adoption gate: pin the version, run the publish-and-migrate step on a disposable branch first, review the generated migration files, and document the upgrade procedure in your runbook so the v0.1.6 class of duplication issue does not reach staging.

How to Pitch It (Stakeholders)

For executives: This is a small, focused Laravel package that gives us the database foundation for tracking AI usage and enforcing budget alerts. It converts a would-be internal build — schema design, migrations, alert plumbing — into an adoption decision, so we can stand up cost visibility and spend controls in days rather than a sprint. The trade-off is maturity: it is pre-1.0, and the latest patch fixes a migration re-publishing bug that could otherwise cause failed deploys. Recommended posture is to pilot it on internal cost dashboards now, keep it off the billing critical path, and revisit a 1.0 commitment once the API stabilizes.

For engineering: v0.1.6 makes vendor:publish --tag=ai-usage-migrations incremental — it now copies only new migrations instead of re-copying every file under a fresh timestamp, which previously broke migrate with "table already exists." If you upgraded through v0.1.4, manually delete the duplicated create_ai_usage_records_table and create_ai_usage_budget_alerts_table migrations that have not yet run. Pin the version, publish and migrate on a throwaway branch first, and add the publish step to the upgrade runbook. Expect further churn at 0.1.x; keep an abstraction boundary around usage writes so a swap stays cheap.

What we are asking for: approval to pilot the package for internal AI usage and budget reporting, with the explicit understanding that it is a v0.x dependency, that migration publishing is a reviewed operational step, and that billing integration remains out of scope until the package reaches a stable release.