Ptero: A GPL v2 Multi-Model AI Chat Wrapper With a WordPress Shortcode
AI Chat with powerful models for free
At a glance
- What is it?
- Ptero is a PHP and JavaScript chat front end that puts several hosted language models behind one interface, stores conversations in the browser, and ships as a WordPress plugin. The repository metadata says Apache-2.0 while the README says GPL v2, and that conflict is the first thing to settle before you deploy it.
- Who is it for?
- Adopt Ptero if you want a ready-made chat interface you can drop into a WordPress page with the [mlp_ai_chat] shortcode, or a small PHP and JavaScript front end you can read end to end before trusting it with prompts. Do not adopt it if you need per-user history, server-side audit trails, or any control over which upstream model actually answers.
- Can I use it commercially?
- Yes. Apache-2.0 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 received new commits within the last day.
- 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Ptero Solves Is Interface Sprawl, Not Model Access
Anyone who compares hosted language models ends up juggling browser tabs. Each provider has its own login, its own quota display, and its own idea of what a conversation looks like. Ptero's answer is a single chat surface with a model dropdown, so switching from one model to another is one click rather than one new account. The README frames the audience explicitly: developers, students, and creators who value privacy and simplicity. The privacy claim is specific rather than decorative. Conversations are stored locally in the browser, and the README states that no chat history is saved on the project's servers. For a student pasting lecture notes or a developer pasting a stack trace, that distinction matters more than the model list. The project is also positioned as non-profit with no paid tier, which explains why the model roster is broad and the feature set is thin. There is no team workspace, no usage analytics, no billing. That is a deliberate shape, and it tells you what the project is optimizing for.
What the Architecture Actually Consists Of
Ptero is a thin client. The README lists the stack as JavaScript, HTML, and CSS on the front end, PHP on the back end for WordPress integration, and a REST API between them. The model providers (DeepSeek, Llama, Qwen, MiniMax, Mistral, and others) are upstream services, not weights shipped in this repository. So the data flow is: browser UI sends a prompt to the PHP REST layer, the REST layer forwards it to whichever provider the user selected, the response comes back, and the browser writes the conversation to local storage. Two consequences follow from that shape. First, the PHP layer is where provider credentials and routing logic must live, which means a self-hosted deployment carries the cost and the key management burden. Second, because history lives in the browser, clearing site data clears the conversations. There is no export path described in the README, and no server-side record to recover from. If you have ever lost a browser profile, you already know how that ends.
Installing It: Two Paths, One Shortcode
The README describes two installation routes. The end-user route requires no installation at all: visit the hosted instance, pick a display name, which is saved locally on the device, select a model from the dropdown, and start typing. No account and no payment are involved. The self-hosted route is WordPress-specific. You download the plugin from the GitHub repository, upload it to a WordPress site, activate it, and then place the shortcode [mlp_ai_chat] on any page or post to embed the full chat interface. That shortcode is the only concrete integration point the README names, and it is worth noting that it is the entire documented API surface. There is no described filter hook, no settings page reference, no REST route table. If you need to theme the chat, restrict it to logged-in users, or log prompts for compliance, the README does not tell you where to start. You would be reading the PHP source to find out, which is a reasonable thing to do before putting a chat interface on a public page.
The Licence Conflict Is the Loudest Thing in the Repository
The repository metadata supplied here lists Apache-2.0. The README carries a GPL v2 badge, states that Ptero is licensed under GPL v2 or later, and links to the GNU GPL v2 text. Those are not the same licence and they are not interchangeable. Apache-2.0 is permissive and includes an explicit patent grant; GPL v2 is copyleft and requires derivative works distributed to others to carry the same licence. For someone evaluating the project, the practical difference is large. If you fork the WordPress plugin, modify it, and distribute it, GPL v2 obligations attach. If the metadata is correct and the README is stale, they do not. This is not a subtle documentation nit. It is the single fact that determines what you may legally do with the code, and the repository contradicts itself on it. Treat the licence as unresolved until the maintainer states which one governs, and note that the README's own badge and the repository's metadata field cannot both be right.
Where Ptero Breaks Down
The no-server-history design is a privacy feature and an operational limitation at the same time. Teams that need a shared conversation log, a compliance record, or the ability to hand a thread to a colleague cannot get any of that from browser local storage. The moment two people need to see the same conversation, Ptero is the wrong tool. There is a second limitation in the model roster. The README names DeepSeek V4, Llama 3.3, Qwen, MiniMax, and Mistral, but it does not describe how the routing layer selects an upstream endpoint, what happens when a provider is rate limited or down, or whether there is any fallback. A multi-model chat wrapper is only as reliable as its least reliable upstream, and the README gives no failure behaviour. Third, the WordPress integration is the only documented deployment target. If your site runs Drupal, Rails, or a static generator, the README offers you nothing beyond the hosted instance. Fourth, the README asks readers to star the project and points to a Discord server, but it does not describe a release process or versioning scheme, and no releases were retrieved for this review. That makes upgrade planning guesswork.
Compared With a Self-Hosted Gateway Like LibreChat
The obvious alternative for this problem space is a self-hosted multi-model gateway such as LibreChat, which also puts several providers behind one interface. The difference is where state and control live. LibreChat is built around server-side conversation history and user accounts, with a database behind it, so teams get shared threads, per-user isolation, and an audit trail. Ptero inverts that: the server is a pass-through and the browser is the system of record. That inversion is the whole product. If your requirement is 'my prompts must not persist on someone else's disk,' Ptero's model is a better fit than a gateway that stores everything by default. If your requirement is 'I need to know what was asked last Tuesday,' Ptero cannot answer and LibreChat can. The second axis is deployment weight. Ptero's documented self-hosted path is a WordPress plugin and a shortcode, which is a lower barrier than standing up a Node application with a database. The trade is that you inherit WordPress's plugin model and its update cycle, and you get no control plane of your own.
Maintenance Cost and the Moving Parts You Do Not Control
The code in this repository is small: PHP glue, JavaScript UI, CSS. That part is cheap to maintain. The expensive part is everything it depends on. Model providers deprecate endpoints and rename model identifiers on their own schedules, and the README's model list (DeepSeek V4, Llama 3.3, and the rest) is a snapshot that will drift. Every upstream change is a potential break in the routing layer, and the README does not describe a configuration file, an environment variable, or a settings screen where model identifiers can be updated. If those are hardcoded in the PHP, each provider change becomes a code edit and a redeploy. That is the real ongoing cost of a wrapper project, and it is not visible from the feature list. On the funding side, the README thanks named sponsors and states there are no paid plans, which means the hosted instance at ptero.pro depends on sponsorship rather than revenue. Self-hosting insulates you from that particular risk, but only if you have resolved the licence question first.
Editorial conclusion
Adopt Ptero if you want a ready-made chat interface you can drop into a WordPress page with the [mlp_ai_chat] shortcode, or a small PHP and JavaScript front end you can read end to end before trusting it with prompts. Do not adopt it if you need per-user history, server-side audit trails, or any control over which upstream model actually answers. Verify three things first: the effective licence, since the repository says Apache-2.0 and the README says GPL v2 or later; where the upstream provider credentials live and who pays for the tokens; and whether the WordPress plugin bundle in the repository is the same code as the one on ptero.pro.
Community notes