Symfony Laravel Package

Product Decisions This Supports

• Build vs. buy for LLM plumbing. This bundle is thin: it registers the google-gemini-php/client SDK as a Symfony service, exposes config for API key/model defaults/base_url, and gets out of the way. The build-vs-buy question is really "spend half a day writing DI glue, or composer require it." For a spike or MVP, buying wins on time-to-first-call. The 2.1.0 release reinforces the buy case: the base_url config gap that previously forced a hand-rolled service definition is now fixed upstream.
• Whether to add Gemini as a second provider. Teams already on OpenAI/Anthropic can use this to A/B a second vendor on cost, latency, or capability (long context, multimodal input) without committing to an abstraction layer. It supports a cost-per-1k-calls comparison rather than an architecture rewrite.
• Feature roadmap bets. Concrete near-term candidates: summarization and tagging of user content, classification/routing of inbound tickets, semantic search over existing Doctrine data, and in-app assistants. All are reachable with a client-level integration plus a prompt, no new platform.
• Standardizing AI client wiring. If the org already configures services via Symfony YAML/PHP config and env vars, adopting this pushes AI credentials and model selection into the same config surface as the rest of the app — a governance and secrets-management decision, not just a code one. The newly configurable base_url extends that governance surface to routing: pointing traffic at a corporate AI gateway, a regional endpoint for data residency, or a recording proxy is now a YAML change rather than a code change.
• Stack-level routing decision: this is Symfony, not Laravel. The brief frames this as a Laravel/PHP package; it isn't, and 2.1.0 does not change that — it adds Symfony 8 support, deepening the Symfony-only positioning. For Laravel work the right artifacts are the core google-gemini-php/client or the Laravel integration. Treat this bundle as the Symfony-only branch of that family and make the stack call explicitly before anyone adds it to a Laravel backlog.
• Platform lifecycle / upgrade posture. Symfony 8 support is a meaningful signal for planning: a service built on this today has a supported path through the current major, rather than being pinned to a maintenance-mode framework version. That converts "spike-grade convenience" into a defensible choice for services with a 12–24 month horizon.
• Testability as a delivery-cost input. The 2.1.0 README documents ClientFake, which means the eval set and regression tests in the proposed spike don't require live API calls or recorded fixtures. That lowers the cost of the "measure quality/latency/cost against incumbent" step and makes the kill criteria cheap to actually run.
• Vendor-dependency posture. MIT, no per-seat cost, still a small footprint (~15 stars, 0 dependents) — no social proof, no downstream canary. 2.1.0 shows active maintenance (Symfony 8 support within the release window), which softens but does not remove the risk. The mitigation has improved materially: the client is now autowirable by Gemini\Contracts\ClientContract, an SDK-level interface, so application code can depend on a contract rather than the bundle's concrete service.

When to Consider This Package

Adopt it when:

• The application is Symfony 6/7/8 on PHP 8.2+ (Symfony 8 itself requires a newer runtime), and the team already wants Gemini specifically — not "an LLM, undecided."
• You want the DI/config ergonomics (env-based API key, autowired client, per-environment model defaults, base_url override for gateway/proxy/regional routing) instead of hand-rolling a service definition around the SDK.
• You need a non-default endpoint — enterprise AI gateway, data-residency region, or a logging/mocking proxy. As of 2.1.0 this is config-only; before, it required escaping the bundle.
• You want direct access to the Gemini SDK's types and methods. This bundle intentionally does not abstract the provider away, which is fine if you're not hedging — but type-hint ClientContract, not the bundle's service, so the seam exists.
• You're time-boxing an exploration and writing the wiring yourself is not a good use of the sprint.

Look elsewhere when:

• Laravel. Use the core client or the Laravel-specific integration. This bundle solves a problem Laravel doesn't have (Symfony's container and bundle config), and 2.1.0's Symfony 8 work is irrelevant to a Laravel codebase.
• You need provider-agnosticism. Unified tool-calling, fallback routing across OpenAI/Anthropic/Gemini, or swapping models by config belongs in an abstraction layer (Prism, LLPhant, the Symfony AI work), not a per-provider bundle.
• You need RAG, vector stores, agents, or evaluation harnesses. The bundle is a wiring layer, not a framework. ClientFake helps with unit tests, not with embeddings storage and retrieval — budget separately.
• Procurement or security review requires a maintained dependency with downstream users. Active maintenance is now evidenced, but zero dependents and a small maintainer surface remains a real risk for anything customer-facing or long-lived. Fine for internal tooling; escalate for production-critical paths.
• You're pinning PHP below 8.2. The bundle still installs, but you lose the 2.8.0 client features the refreshed README advertises. Check this before committing the runtime upgrade to the same sprint as the integration.
• You're not on Symfony. Slim, plain PHP, WordPress, Drupal — go to the underlying client.

How to Pitch It (Stakeholders)

One-liner for executives: A small, MIT-licensed Symfony integration for Google's Gemini API that lets us put an LLM behind an existing service in days, not a quarter — with no license cost, token-based pricing we can meter, and an endpoint we can point at our own gateway.

The case: We have concrete, near-term features (summarization, classification, in-app assistant) that need a model call and nothing more. This package removes the boilerplate and keeps API keys, model settings, and now endpoint routing in the config system we already operate. Release 2.1.0 closes the two gaps that made it feel improvised: proxy/regional endpoints are config rather than custom code, and the client is injectable via a published interface, so our domain code isn't welded to a third-party package's internals. It's a spike-grade investment: hours of integration, low exit cost, and now a supported framework path through Symfony 8.

The honest risk, stated up front: It is still a young package — a thin wrapper over someone else's SDK, with no downstream dependents to act as a canary. 2.1.0 shows the maintainer is responsive, which reduces the abandonment risk but doesn't establish a track record. Mitigation is cheap and unchanged in shape, now easier in practice: define one internal interface for "generate/classify" in our own code, inject the Gemini client behind it via ClientContract, and a future swap to Vertex AI or another provider becomes a config change rather than a refactor. We should not let this package's types — or the SDK's request/response objects — leak into domain code.

What we're asking for: A two-week time-boxed spike — integrate behind the interface, use ClientFake for the fast test loop, run an eval set of ~200 real examples, and report quality, p95 latency, and cost per 1,000 calls against the incumbent. Kill criteria: if quality or cost doesn't beat current handling, we keep the interface and drop the provider without sunk cost. Prerequisite to confirm in week one: the PHP 8.2+ runtime requirement for the current client feature set, since that upgrade may be on a different team's schedule.

For engineering: composer require, one config file (gemini.yaml — API key, model defaults, optional base_url), autow ire against Gemini\Contracts\ClientContract. No new infrastructure, no vendor lock at the code level if the interface boundary holds, and ClientFake for tests.