Laravel Ai Pricing Laravel Package

Getting Started

Install the package and publish its config/catalog, then confirm which pricing snapshot is active. v0.4.2 ships snapshot v19 (retrieved 2026-10-19), so the first check after upgrading is that your application is resolving snapshot v19 and not a cached older catalog.

The first practical use case is quoting or metering DeepSeek V4.1 Flash 1017. Look first at two places:

1. The catalog/snapshot data and the identity resolver — the release is primarily a data refresh plus a fallback-policy change, not a new API surface.
2. The fallback configuration — the generic identity and the new qualified basis are both fallback-blocked, which changes runtime behavior for existing lookups.

For day-to-day use, request the explicit qualified basis:

openrouter:deepseek/deepseek-v4.1-flash-1017-standard-max

Do not start with the generic openrouter:deepseek/deepseek-v4.1-flash-1017 identity if you expect it to resolve through a live catalog or Portkey headline price. That path is now blocked by design. Configure the generic identity explicitly if your application needs it.

Validate the integration with a single cost calculation against the qualified basis and assert the snapshot version alongside the result. Once that works, wire the lookup into your existing usage/billing flow.

Implementation Patterns

Treat model identity and pricing basis as separate concepts. The model is deepseek/deepseek-v4.1-flash-20261017; the billable basis is openrouter:deepseek/deepseek-v4.1-flash-1017-standard-max. Keep the qualified basis in a constant, enum, or config mapping rather than scattering the raw string through jobs and controllers.

Centralize cost resolution behind one service. A small application-level service or action should accept a model key, token counts, and optional route/endpoint metadata, then resolve the basis, apply rates, and return a cost object. This is where you can handle fallback-blocked identities consistently instead of letting each call site deal with exceptions or nulls.

Use the -standard-max basis as a conservative pre-flight estimate. Because it is the maximum over the 13 default-routed endpoints, including quantization and time-of-day overrides, it is suitable for budgets, guardrails, and user-facing estimates that should not under-quote. For post-hoc reconciliation, pair it with actual provider invoices or recorded usage rather than presenting the estimate as exact.

Persist the snapshot version with cost records. Store snapshot=v19 (and the basis string) next to calculated costs. When rates change on endpoint churn, you can explain historical numbers without re-deriving them from a catalog that has moved.

Handle fallback-blocked identities explicitly. In your resolver, distingush between “unknown model” and “known but fallback-blocked identity.” The latter should fail fast with a clear application exception or be mapped through an explicit configured alias. Avoid silently returning zero cost, which is the most dangerous failure mode for billing and quota enforcement.

Use the qualified basis in tests and fixtures. Freeze the snapshot in test setup and assert that the generic identity is rejected while the qualified basis resolves. Add a regression test that the computed rates match the expected input, output, and cached-input values from snapshot v19.

Aggregate reporting by basis, not only by model. If you later add another basis for the same model, grouping solely by model will blend incompatible price points. Include the basis string in usage records and group by both.

Gotchas and Tips

• The generic identity is fallback-blocked. Code that previously relied on implicit fallback to a cheaper live catalog or Portkey headline price will no longer resolve that way. Either quote the qualified -standard-max basis when its conditions are met, or configure the generic identity explicitly.
• The qualified basis is not an alias. Do not treat openrouter:deepseek/deepseek-v4.1-flash-1017-standard-max as another name for the generic identity. It is a distinct, fallback-blocked basis with its own published rates.
• standard-max is a ceiling, not your expected bill. It is the maximum across all 13 default-routed endpoints, including every quantization and time-of-day override. Actual routed cost can be lower. Label estimates accordingly.
• Some costs are outside the snapshot. Batch requests, opt-in service tiers, cache writes, and server tools are not covered. The two opt-in DeepInfra flex/priority endpoints are also excluded. If your workload uses any of these, the snapshot will understate cost.
• Cached input at 0.008/M is endpoint-specific. That rate comes from relace and inference-net/fp8. If your traffic does not route through those endpoints, cached input will cost more than the headline maximum suggests. Do not apply the cached-input rate globally.
• Endpoint churn is the maintenance trigger. The release notes explicitly call for re-review on endpoint churn. Pin snapshot v19, but schedule a periodic check of the upstream endpoint catalog and upgrade the snapshot deliberately.
• Beware unit and rounding errors. Rates are USD per million tokens. Keep token counts as integers until the final calculation, and avoid rounding intermediate per-token rates to too few decimal places, especially for the 0.008/M cached-input figure.
• Do not depend on live catalog fallback in production paths. For deterministic billing and tests, resolve only against the pinned snapshot and explicit identity mappings. Live fallback behavior is exactly what this release restricts.
• Config quirk to check after upgrade: confirm whether your existing fallback settings now cause hard failures versus null returns. The release changes resolution policy; your error handling should be verified against the new behavior rather than assumed from previous versions.