Prism: one PHP interface for OpenAI, Anthropic and Ollama calls in Laravel
A unified interface for working with LLMs in Laravel
At a glance
- What is it?
- Prism is an MIT-licensed Laravel package that puts text generation, multi-step conversations and tool use behind a single fluent API across several model providers. The value is provider portability inside a Laravel app; the cost is a pre-1.0 dependency that moves fast and hides provider-specific behaviour behind its own abstraction.
- Who is it for?
- Adopt Prism if you are building inside Laravel and need to switch or mix providers without rewriting call sites; the fluent chain and the config/prism.php provider list are the whole integration surface.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 179 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The provider lock-in problem Prism is aimed at
Calling an LLM from PHP without a wrapper means writing against one vendor's HTTP shape. The request body, the streaming format, the way a tool call comes back and the way a system prompt is expressed differ between OpenAI, Anthropic and a local runtime such as Ollama. If you write that code directly and later want to try a cheaper model or a local one for development, you rewrite the call sites, not the configuration. Prism exists to move that difference behind a PHP interface so the application code stays put. The README frames the goal as letting you focus on the application rather than the technical details of each provider, and the repository topics list openai, anthropic, claude and ollama as the targets. The audience is Laravel developers: the package is a Laravel package, it is installed through Composer, and its configuration lives in the Laravel config directory. If you are not on Laravel, the fluent API and the service provider wiring are the parts you would be porting by hand, which is most of the package.
What the fluent interface actually covers
The README names three capabilities: generating text, handling multi-step conversations, and using tools with various AI providers. Those map to three different shapes of work. Text generation is a single request and a single response. A multi-step conversation means the package keeps message history so a follow-up call includes prior turns, which is the part that normally forces you to design your own message array and decide where it is stored. Tool use means the model can ask for a function to be executed and the result fed back, which is a loop rather than a single round trip. The README does not describe the internal architecture, so the data flow below the interface is not something this article can confirm. What is documented is the surface: a fluent chain for building a request, and provider selection as a configuration concern rather than a code concern. That is the design bet. Provider differences that can be expressed as configuration are absorbed; differences that cannot are either normalised or unavailable.
Installing Prism and where the provider settings live
The package is published on Packagist as prism-php/prism, so installation is a Composer require inside a Laravel project. The README points to the Prism website for official documentation, and that site is where the full command set and the fluent method names are documented; the README itself does not reproduce them. The pattern for a Laravel package of this kind is a service provider registered through package discovery, plus a publishable config file. The config file is config/prism.php, and it is where provider credentials and the provider list are declared. That file is the first thing to read after install, because it tells you which providers this version actually ships support for, which is not necessarily the same set as the repository topics. API keys for OpenAI, Anthropic and any local Ollama endpoint are environment values referenced from that config, which keeps secrets out of the repository in the usual Laravel way. Because the README does not print the install command or the config keys verbatim, treat the website as the authoritative source for the exact syntax at the version you install.
The version number is the risk, not the feature list
The most concrete fact in the release history is that the project is still on 0.x. The latest release at the time of writing is v0.100.1, preceded by v0.100.0 and v0.99.22. Reaching a hundred minor versions without a 1.0 is a signal about API stability: under semantic versioning conventions, anything before 1.0 can break in a minor release, and a project that ships three releases in eight days is moving quickly. For a Laravel app that is fine if you pin the version and read the changelog before upgrading. It is not fine if you treat the fluent chain as a frozen contract and run composer update on a schedule. The second limitation is scope: a unified interface can only expose what it has modelled. Provider-specific parameters, new response fields and preview features tend to appear in the vendor SDK first and in a wrapper later. If your application depends on a capability that is not in the Prism documentation, the wrapper is the wrong layer and you should call the provider directly for that one path rather than wait.
Prism against calling the vendor SDKs directly
The alternative is not another PHP LLM wrapper; it is the official SDKs and raw HTTP clients. OpenAI and Anthropic both publish first-party client libraries, and Ollama is reachable over plain HTTP. Calling those directly gives you the full parameter set on day one, error payloads exactly as the vendor defines them, and no intermediate release cycle between a new model feature and your code. The difference in approach is where the abstraction sits. Direct SDK calls put the provider in your application code, so switching providers means touching every call site. Prism puts the provider in config/prism.php, so switching is a configuration change and the call sites stay. You are trading access to provider-specific detail for the ability to change your mind cheaply. For a single-provider application that will never switch, that trade is mostly cost. For an application that wants a local Ollama model in development and a hosted model in production, it is the entire point.
Maintenance, upgrades and the MIT licence
Prism is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are retained. That is a permissive licence and it does not impose copyleft obligations on your application. It also means there is no warranty, so support comes from the project and the community rather than from a contract. The repository is not archived and receives commits, with the most recent push matching the v0.100.1 release date, so the project is active. The upgrade cost is the practical concern: with minor releases arriving at this cadence, budget for reading release notes and running your own test suite after each bump. Pinning to an exact version in composer.json and upgrading deliberately, rather than on a floating constraint, is the difference between a routine change and a surprise. This is a description of the licence terms, not legal advice; if licence compatibility matters for your distribution, have someone qualified review it.
Who should take Prism and what to check first
Prism fits a Laravel application that needs to talk to more than one model provider, or expects to, and wants that decision expressed in configuration. It fits less well in a codebase that is not Laravel, where the framework integration is most of what you would be adopting, and in an application that leans on provider-specific parameters the package has not exposed. The thing to verify before writing application code is the provider list in config/prism.php at the version you install, cross-checked against the documentation pages for the operations you need. Confirm that text generation, conversation state and tool use are all covered for your chosen provider, because the README describes them as package-level capabilities without claiming every provider implements all three identically. Then pin the version. A wrapper that unifies four providers is worth having only if the unified surface covers the calls you actually make.
Editorial conclusion
Adopt Prism if you are building inside Laravel and need to switch or mix providers without rewriting call sites; the fluent chain and the config/prism.php provider list are the whole integration surface. Do not adopt it if you depend on provider features that the package has not modelled yet, or if you need a stable API contract today: the version numbers are still 0.x. Before committing, read the provider list in config/prism.php, check which providers the documentation actually covers, and pin prism-php/prism to an exact version in composer.json so a minor release cannot change your call sites underneath you.
Community notes