Alpaca Bot
Alpaca Bot is a chat screen inside WordPress admin, talking to a model you host. Conversations stay on your site, in your own database, and only their author can open them. It runs against Ollama out of the box, or any OpenAI-compatible endpoint. Features A chat screen in wp-admin: replies stream in as they are written, with a copy button on every message and code block, “Edit and resend” on your own, and an image attached from the media library for a model that can see. Your conversations, stored privately on your site (or not at all: the Privacy tab decides) and listed in the screen’s history. Switch models per conversation; where the site allows it, your pick is remembered as your default. A system prompt, per-model overrides (temperature, context window, keep-alive) and a receipt under every reply: model, tokens, time. Monthly usage caps, per site and per user, with the meter behind them. A REST API under alpaca-bot/v1 (docs/api.md) and a WP-CLI command. Requirements PHP 8.4+, WordPress 6.9+, an Ollama instance (or any provider php-agents supports) Setup Install Ollama on your localhost or server. In your WordPress admin, open Alpaca Bot > Settings and, on the Provider tab, enter the endpoint’s base URL. For Ollama it ends in /v1: http://localhost:11434/v1. Click Save Changes. The Models tab then lists what the provider serves; pick a default. ⭐️ Become a Patreon and support Alpaca Bot development. ⭐️ Usage The chat screen Click Alpaca Bot in the admin menu, below Dashboard and above Posts. The screen is open to every user who can edit posts (filter alpaca_bot/admin/menu_capability to change that). The model select in the header picks the model for this conversation; where the site allows it, your pick is saved as your default. The history select opens one of your earlier conversations, and New chat starts a fresh one. Type in the box at the foot of the screen. Enter sends, Shift+Enter adds a line, Escape clears the box. The image button attaches a picture from the media library to your next message, for a model that can see. The largest image the screen takes is set by the site’s PHP post_max_size, not its upload limit: the image travels inside the message, not as an upload. Replies stream in as they are written. Every message has a Copy button, your own have Edit and resend, and a code block has its own copy button. Under a reply is its receipt: the model, the tokens it used and how long it took. The Help tab at the top right of the screen repeats this, and documents the shortcodes. Settings Alpaca Bot > Settings (administrators) is one page in six tabs: **Provider** (the endpoint, its key, the timeout), **Models** (the default, temperature, context window, keep-alive, and per-model overrides), **Chat** (system prompt, welcome text, what users may change), **Privacy** (whether conversations and the usage log are stored, and for how long), **Limits** (monthly token caps for the site and per user) and **Tools** (what the model may do besides answer — read the next section before you leave those as they come). Every field is also readable and writable over the REST API (`GET`/`PUT /settings`). Tools, and what they let the model reach Settings > Tools switches the model's tools on and off. Three ship, **all three on by default**: `web_fetch` reads one public web page as text, `summarize` condenses text through the model, and `draft_post` writes a draft. Read this section before you leave `web_fetch` on, and before you open the chat to a role. web_fetch makes the web server send a request, and hands the reply back. Every URL is checked twice before the fetch — WordPress’s own wp_http_validate_url(), then the plugin’s own check over every address the name resolves to, on the first URL and on every redirect — and http(s) only, ports 80/443/8080 only, no private, loopback, link-local or other special-purpose address. What no check of that shape can cover is a name whose answer changes between the check and the connection: each is a separate DNS lookup, so a host under someone else’s control, with a short TTL, can answer the checks with a public address and the connection with 127.0.0.1 or a cloud metadata address. The response body then comes back as text. Closing that means pinning the resolved address into the transport, which is a compatibility project and is planned for a later 0.x release. Who can reach it, today, with no model involved: anyone who can edit posts — a Contributor included, since core grants Contributors edit_posts — can put [alpacabot_agent name="get" url="…"] in their own draft and preview it. So treat web_fetch as a capability you are granting your authors, not as something only the model uses. An egress policy is the supported mitigation, and it is the one that holds for every plugin on the site at once: stop the web server’s host from opening outbound connections to your private ranges and to 169.254.169.254, at the network or the host firewall. On a cloud instance, require IMDSv2. If you cannot do that and do not need the tool, leave web_fetch off — the chat, the drafts and the summaries all work without it. Opening a route to a role opens the tools to that role too. alpaca_bot/capability/chat (and chat/stream) can name any capability, read and exist included, and that is deliberate — it is how a site builds a subscriber-facing or public chat. But the toolkits a turn may call are chosen by the toolkits.enabled setting alone: there is no second capability check between a role that may chat and the tools that are switched on. So a role you admit only to converse gets web_fetch with it. Only draft_post checks a capability of its own (edit_posts/edit_pages) and refuses a role that lacks it. Until a later 0.x release adds a floor of its own, use the alpaca_bot/toolkits filter to take web_fetch away from the users you are opening the chat to: add_filter( 'alpaca_bot/toolkits', function ( array $toolkits, int $user_id ): array { if ( ! user_can( $user_id, 'edit_posts' ) ) { unset( $toolkits['web_fetch'] ); } return $toolkits; }, 10, 2 ); REST API and WP-CLI Everything the screen does is a route under alpaca-bot/v1: a turn (POST /chat, then its stream as server-sent events), conversations, models, settings and usage. docs/api.md is the reference, with authentication, streaming and error examples. From the command line, wp alpaca-bot chat|models|usage|settings does the same. Shortcodes Both 0.4 shortcodes are back on the new pipeline. Both are for logged-in users who can edit posts (edit_posts); anyone else sees a notice. [alpacabot prompt="…"] Puts the model’s answer to the prompt in a post or page. prompt — The message sent to the model. Without it, the shortcode is the chat screen (below). model — the viewing editor’s model — The model, where the site lets users change it (Settings › Chat); it must be one the provider lists. Without it, the answer runs on the model the editor who first views the page would chat on (their own preference where the site lets users change it, else the site’s default), and the cache does not record which. system — the site’s system prompt — The system prompt for this answer. temperature — the model’s setting — The temperature for this answer, 0 to 2. format — markdown — markdown renders the answer (raw HTML stripped, links kept); text shows it as plain, escaped text. cache — 1h — How long the answer is kept: a number with a unit (45s, 30m, 1h, 2d), a year at most. off generates on every view. Anything else keeps the default. Generating an answer costs provider tokens and counts against the monthly cap of the user viewing the page, so it is cached (a transient, per shortcode, per post and per cache duration) and served from the cache until it expires. Two identical shortcodes on two pages are two answers; changing the site’s system prompt starts a new answer, changing its default model does not (the model is part of the answer’s identity only when the shortcode names one). When a turn fails, the page shows why in the words the chat uses (the cap, a model the provider does not list, or a fixed “could not complete” message: the provider’s own error, which quotes its endpoint, goes to the debug log under WP_DEBUG), and nothing is cached. The block editor and the REST API never generate. content.rendered carries the cached answer, or a notice when there is none; an answer is generated only when the page is viewed on the site. So a client listing a hundred posts over the API spends nothing, and the editor’s preview shows what the cache holds. A generation counts against the same per-minute limit as the chat. Thirty a minute per user, shared with the chat screen, the REST routes and the abilities, and moved everywhere at once by the alpaca_bot/rate_limit filter (bucket chat). A cached answer costs nothing; a page carrying more shortcodes than the minute allows shows the rest as a “Too many requests” notice, caches nothing for them, and fills them in on a view after the minute turns over. Anyone who can write a post can write a prompt. A Contributor can put a prompt, and a system prompt, in a draft; once it is published, the first user with edit_posts to view the page generates the answer, the tokens count against that viewer’s cap, and the answer is on the page for everyone without anyone having read it first. The markdown is sanitised (no scripts, no raw HTML), but links and images the model writes reach the public page. Review a page after its answer appears. A per-site capability setting for this belongs to the admin-wide panel of a later 0.x release. A visitor never triggers a generation. A visitor, or a logged-in user who cannot edit posts, sees a notice in place of the answer. A site that wants visitors to see the answer returns true from the alpaca_bot/shortcode/allow_guests filter ((bool $allow, int $postId, string $tag)); they then see the cached answer and nothing else. When the cache has expired, visitors see the notice again until someone who can edit posts opens the page. That is the point: a page nobody with the capability opens spends nothing, whatever the model costs. add_filter('alpaca_bot/shortcode/allow_guests', '__return_true'); [alpacabot] With no prompt, the chat screen on a page, for logged-in users who can edit posts, with the same bundle and stylesheet as in wp-admin (a front-end design of its own is a later 0.x release). A visitor sees a login notice and loads nothing. The REST API and the block editor show a notice in its place, as for a prompt. The screen’s markup carries the viewing user’s REST nonce, as it does in wp-admin; it is useless without their cookies, but a full-page cache set to cache pages for logged-in users would store one editor’s page and serve it to another, so leave a page carrying the shell out of such a cache. [alpacabot_agent name="get|summarize" url="…" length="…"] (deprecated) The 0.4 form still works, under the same rules and cache: get shows the page’s readable text, summarize fetches it and asks the model for a summary (length is free text, “2 sentences”; model and cache as above). The fetch is the chat’s web_fetch tool itself, so it runs only while that tool is on under Settings › Tools, and through the same address guard: a private, local or non-http(s) address is refused. It logs a deprecation notice once per request under WP_DEBUG and goes away in a later 0.x release. Put the text to summarize in a prompt instead, or open the URL in the chat, where the fetch and summarize tools read it for you: [alpacabot prompt="Summarize https://…"] would not work, since a shortcode’s turn runs no tools and the model cannot open the URL. Support Questions and bug reports go to the WordPress.org support forum. Say which plugin, WordPress and PHP versions you run. For premium support, book a call: video calls, help setting up your Ollama instance or provider, troubleshooting, and onsite setup assistance. If the plugin has been useful, star Alpaca Bot on GitHub; a star helps other site owners find it. Made Possible By Emma Delaney’s How to Create Your Own ChatGPT in HTML CSS and JavaScript Lucide Beautiful & consistent icons – ISC license htmx High power tools for HTML – 0BSD license league/commonmark Markdown parser for PHP – BSD-3-Clause license php-agents Provider-agnostic AI agents for PHP – MIT license Ollama Get up and running with large language models locally – MIT license
