- What is symfony/ai-albert-platform used for?
- It is a Symfony AI platform bridge that connects applications to Albert, the French government's OpenAI-compatible LLM API built on OpenGateLLM. It maps Albert's chat and completion endpoints onto Symfony AI's unified provider interface so Albert models can be used alongside other Symfony AI platforms. It is an adapter, not a full SDK or a Laravel-specific package.
- How do I install symfony/ai-albert-platform in a Laravel application?
- Install it with Composer using composer require symfony/ai-albert-platform. The package is PSR-4 autoloadable and does not conflict with Laravel's framework code. You will need to bind and configure it yourself because the package does not ship Laravel integration code.
- Does this package include a Laravel service provider, facade, or config publishing?
- No. It does not ship a Laravel service provider, facade, configuration publishing, queue integration, or Eloquent/vector-store glue. All Laravel ergonomics, such as container bindings and config files, are work you own. The package is a Composer-level Symfony AI bridge rather than a Laravel package.
- Which Laravel and PHP versions are supported by symfony/ai-albert-platform?
- The package does not declare Laravel framework support because it is not a Laravel package; it is a Symfony AI bridge. Its PHP and dependency constraints come from its composer.json and symfony/ai, so check those before installing. It can be used in a Laravel application wherever Symfony AI itself is supported.
- How do I configure the Albert API key and base URL?
- Configure Albert like other Symfony AI platforms by supplying your Albert API key and pointing the base URL at https://albert.api.etalab.gouv.fr. You obtain the key from Albert and should keep it in environment or config storage rather than hard-coding it. Because there is no Laravel config publishing, you own the configuration wrapper and validation.
- Can I reuse existing OpenAI-compatible code with Albert?
- Albert is OpenAI-compatible, so the conceptual migration from openai-php-style code is small. The practical migration stays small if you keep an internal interface boundary and avoid letting vendor-specific calls leak into domain code. Prefer the Symfony AI abstraction so Albert remains one interchangeable adapter.
- Does it support embeddings, streaming, and tool calling?
- Embeddings have been explicitly supported since v0.4.0, and chat/completion endpoints are the core use case. Streaming and tool/function calling are less certain because OpenAI-compatible does not mean feature-complete; verify them against the current package version and Albert API reference before depending on them. Keep capability checks inside your own gateway.
- What is the carbon footprint metadata added in symfony/ai-albert-platform v0.14.0?
- Version 0.14.0 exposes Albert's carbon footprint as result metadata on the existing response path. It is an additive, nullable field rather than a new abstraction or feature layer. The package surfaces a value but does not document a methodology, so decide internally whether and how you are allowed to report on it.
- How should I test an Albert integration without hitting the live API?
- The package does not ship test doubles, so you should mock the Symfony AI platform interface or the underlying HTTP client in your test suite. Use recorded fixtures and contract tests against Albert response shapes, and alert on response-shape changes. This also helps catch API drift across 0.x releases.
- Is symfony/ai-albert-platform production-ready and actively maintained?
- Treat it as an upstream-tracked, de facto single-vendor adapter: it has a small maintenance signal, low dependent count, and prior releases with no significant changes. Version 0.14.0 adds a genuine user-facing capability and credits an upstream Symfony AI maintainer, which is encouraging but not a guarantee. Pin versions, wrap the package in your own gateway, and budget for production hardening such as timeouts, retries, quota handling, logging, and redaction.