Ai Platform Laravel Package

Product Decisions This Supports

• Build vs. buy on an internal AI abstraction layer. This package is essentially the "buy" answer to "should we write our own provider wrapper?" It ships 37+ provider bridges (OpenAI, Anthropic, Gemini, Bedrock, Mistral, Ollama, Vertex, Azure, OpenRouter, etc.) behind one Platform contract, so the abstraction cost is already paid by the Symfony AI team rather than by your roadmap.
• Multi-provider strategy and vendor de-risking. If roadmap includes "don't get locked into one model vendor," this is the cheapest path to a swappable provider in a PHP codebase. Relevant when procurement wants pricing leverage, when you need regional/EU providers (Mistral, OVH, Scaleway, Albert), or when legal wants a self-hosted fallback (Ollama, LM Studio, Docker Model Runner, TransformersPHP).
• Reliability and cost governance features as product requirements. The Cache and Failover bridges turn "AI calls are slow/expensive/flaky" from an accepted cost into an engineerable concern — prompt caching for unit economics, failover for uptime SLAs. These map directly to SLO and margin conversations.
• Feature-level scoping. Capability surface (chat, streaming, tool calling, structured output with schema validation, embeddings, reranking, speech-to-text/TTS, OCR, image) tells you what you can commit to without custom glue. Structured-output validation in particular decides whether "AI returns reliable JSON" is a v1 feature or a v2 risk item.
• Test strategy and CI spend. The Mock provider and routing-aware test doubles let you keep AI paths in CI without live API keys or per-build token cost — a real line item in the engineering budget.
• Timing gates on the AI roadmap. Release cadence (0.6 → 0.12 in a short window) plus "experimental, outside the BC promise" means any commitment here is a bet on when to adopt, not just whether.

When to Consider This Package

Consider it when:

• You are a Symfony/PHP shop (or a PHP shop comfortable with Symfony components standalone) and want the abstraction to fit your existing DI, config, and HTTP client stack rather than fighting a framework.
• You expect two or more providers within 12 months — for cost, latency, capability, or residency reasons — and would otherwise hand-roll a wrapper.
• Uptime or cost targets require failover and caching behavior that would take a sprint to build.
• You want self-hosted / on-prem inference as a credible option without a second integration effort.
• You can absorb churn: pin versions, isolate behind an internal interface, and staff a small upgrade budget per quarter.

Look elsewhere when:

• You are Laravel-first and want first-class framework ergonomics — the Laravel AI SDK or Prism give you native service providers and conventions; this package's Laravel story is "it's Composer-installable," not "it's integrated."
• You need BC guarantees and vendor support now for a revenue-critical path. Experimental + 0.x means breaking changes ship in minor versions.
• You depend on provider-specific depth the abstraction may not surface — fine-tuning jobs, batch APIs, vector store/assistant lifecycle management, advanced guardrails. Abstractions leak precisely where differentiation lives.
• You have a single, stable provider. A direct SDK is fewer moving parts than an abstraction over one thing.
• Your team's AI investment is in Python/Node service boundaries; adding a PHP-side abstraction duplicates ownership.

Signals to weigh honestly: 55 stars and 0 dependents means near-zero ecosystem validation — you are an early adopter, not a follower. Mitigating factor: it's a read-only subtree of the main symfony/ai repo with an active changelog and Symfony-core contributors, so abandonment risk is lower than the star count implies. Treat it as "young but backed," not "unproven hobby project."

Recommended gate: a 1–2 week spike with two providers plus the failover bridge, wrapped in your own AiClient interface, then a go/no-go against upgrade cost and abstraction leakage observed.

How to Pitch It (Stakeholders)

For executives: Symfony is standardizing how PHP applications talk to AI models. Adopting symfony/ai-platform means one integration that works with OpenAI, Anthropic, Gemini, Bedrock, Mistral, and self-hosted models — we can switch vendors on pricing or policy changes without a rewrite, and we get caching and automatic failover essentially free. That converts vendor lock-in and AI downtime from strategic risks into configuration. The trade-off: it is officially experimental, so we pin versions and keep it behind our own thin interface, capping our exposure to a few days of work if we ever need to move.

For engineering: provider-agnostic Platform contract, one bridge package per vendor, pluggable contracts for anything custom. Covers chat, streaming, tool calls, validated structured output, embeddings, reranking, speech, and OCR — plus a mock provider so AI paths stay in CI without live keys. It's a Symfony component, so it slots into DI and the HTTP client naturally, but there's no Laravel integration layer, and 0.x releases have shipped breaking changes. Plan to wrap it, pin it, and budget a quarterly upgrade pass.

Risk framing to state up front: young package, low public adoption, fast-moving API. That's acceptable for an abstraction boundary — it is not acceptable for a dependency sprinkled directly across feature code. Approve the spike, not the sprawl.