Router Laravel Package

Product Decisions This Supports

• Multi-provider inference strategy (build vs. buy vs. abstract). The core decision this package informs is whether to own a routing layer between your product and LLM providers. It lets you centralize "which provider/model handles this request" as a policy you define, rather than hard-coding a vendor into feature code — so the decision is really "do we want provider selection to be a first-class product capability?"
• Cost and latency optimization as a product lever. A routing strategy can send expensive/complex calls to a premium model and high-volume or latency-sensitive calls to a cheaper/faster one. This directly supports roadmap items like usage-based pricing, free-tier sustainability, and margin protection without re-architecting features.
• Resilience and failover. Supports product commitments like uptime SLAs and graceful degradation when a provider has an outage or rate-limits you — a user-facing reliability decision, not just an infra one.
• Vendor optionality / lock-in reduction. Makes "swap providers" a config/strategy change instead of a multi-sprint migration. Supports procurement decisions and renegotiation leverage.
• Experimentation and model upgrading. Enables A/B tests, canary rollouts, and gradual model migrations (e.g., cheap model for 5% of traffic, evaluate, ramp). Supports quality-vs-cost trade-off decisions with evidence.
• Compliance and data-residency routing. If you have region- or tenant-specific constraints, provider selection can become part of your compliance story.
• Feature scoping. If your product exposes "model choice" or "bring your own key" to customers, this is a candidate substrate — but only after the maturity risks below are resolved.

When to Consider This Package

Consider it when all of the following hold:

• You already have, or are committing to, more than one inference provider (or multiple models/tiers within a provider) and are feeling the pain of ad-hoc branching in feature code.
• Your stack is PHP/Laravel and you want routing to live in-process rather than as a separate service.
• The routing logic you need is policy-shaped and modest: cost tiering, failover, percentage rollout, tenant/region rules. You are not looking for a full AI gateway.
• You can absorb vendor risk: 12 stars, 0 dependents, and a single-maintainer footprint mean you must plan to read the code, pin versions, and possibly fork.
• You have engineering appetite for a time-boxed spike and ADR rather than a rubber-stamped adoption. Treat the "opportunity" score as a prompt to evaluate, not evidence of fitness.

Look elsewhere (or build the thin layer yourself) when:

• You use a single provider. The abstraction buys you nothing today and costs you direct access to provider-native features (tool calling, caching, streaming nuances). Revisit only when a second provider is genuinely on the roadmap.
• You need production-grade observability, retries, quota management, semantic caching, and evals. That is gateway territory; buy or build a dedicated service rather than stretch a 12-star library.
• You require commercial support, SLAs, or a security review with vendor accountability. There is no ecosystem to lean on here.
• Your inference path is latency-critical and cross-language. A PHP in-process router may not be the right home; a sidecar/service may be.
• The team isn't PHP-native or would have to maintain it without understanding it. Maintenance burden with no dependents means you are the ecosystem.

Decision guidance: the correct PM output here is usually "spike, don't adopt." Fund 3–5 days to build one failover path and one cost-tier path behind your own internal interface, then decide whether to keep the dependency, fork it, or write ~200 lines yourself.

How to Pitch It (Stakeholders)

To executives (30 seconds): We currently couple our product to one AI vendor, which means every price change, outage, or model upgrade is a fire drill. This package is a small, MIT-licensed routing layer that lets us choose providers by policy — cheapest for routine work, best for premium work, automatic failover — so we can cut inference cost, protect uptime, and keep negotiating leverage. It is early-stage with no adoption yet, so the recommendation is a short, low-cost evaluation, not a commitment.

To engineering leads: Thin PHP/Laravel abstraction that centralizes provider selection behind a strategy you define. Aligns with your strict-types/PSR-12/PHP 8.1+ standards. The upside is removing provider branching from feature code. The risk is maturity: near-zero adoption, single maintainer, limited docs, no dependents to learn from. Proposed path: pin it, wrap it behind our own routing interface so it's replaceable, and prove two scenarios (failover + cost tiering) before any broader rollout.

To finance/procurement: Primary value is cost control and vendor leverage, not new revenue. Quantify by modeling current spend against a tiered policy (share of traffic eligible for a cheaper model) and the expected cost of a provider outage. Set the evaluation budget small enough that the answer is cheap either way.

Bottom line for stakeholders: Strategic fit is real if we are — or will soon be — multi-provider. Readiness is not. Approve a bounded evaluation with a clear keep/fork/build exit criterion; do not standardize on it yet.