ollama pull llama3.2That command downloads a small model your laptop can serve, and it is the most useful line you can run before the Core AI Contributor Day in Kraków. The AI features that shipped in WordPress 7.0 stay switched off until a provider is connected, and venue wifi is not something I would bet a working day on. Pull the model at home and you always have something to point WordPress at.
The Core AI Team published its prep notes for the table it runs at WordCamp Europe’s Contributor Day on June 4, 2026, at ICE Kraków. David Levine and Greg Ziółkowski lead in person, Gajendra Singh handles remote support, and anyone not in Poland can join through #contributor-day or #core-ai on the WordPress Slack. What I keep coming back to is how much of the day gets decided before you arrive. Two choices matter most: which environment you bring, and where your model lives.
Playground or a real environment
For testing the AI plugin, the MCP Adapter, or the AI Client that landed in 7.0, WordPress Playground is enough. It runs in the browser with no dependencies, which is why the team lists it first. The documentation lives on developer.wordpress.org. You get a fresh install, add the AI plugin from the directory, connect a provider, and start testing. If your contribution for the day is bug reports or documentation, stop there.
It helps to know what’s in play. The AI Client and v1.0 of the canonical AI plugin arrived with 7.0, the Abilities API has been in core since 6.9, and the MCP Adapter that lets assistants like Claude and ChatGPT drive a site is still distributed as a Composer library while it waits for a directory listing. Every one of those is testable from Playground.
Playground has limits. It is a browser sandbox, so state can disappear between sessions and API keys need re-entering. There is no Composer or Python inside it. Anyone planning to apply patches, test pull requests, or run WP Bench (the team’s benchmarking framework) needs the full setup: Docker or a local install, Node and npm, Composer, and Python 3.10 with pip. That toolchain takes an evening to get right, and it is the part people try to improvise on conference wifi.
One clarification from the repos saved me some confusion. The AI Client in core wraps the wordpress/php-ai-client Composer library, but core ships the library, so you only need the package when you are building outside WordPress or hacking on the library itself. The GitHub README is explicit that it is an SDK you install with Composer rather than a plugin.
composer require wordpress/php-ai-clientCloud key or local model
The features need a provider, and you connect one through a connector plugin. The team points to Mistral’s free API key with the ai-provider-for-mistral connector, and to Ollama or llama.cpp for serving a model from your own machine. The two options cover different halves of the day.
A cloud key gives you the behavior users see, with quicker responses, stronger output, and the provider capabilities some features depend on. A local model gives you independence. When the venue network falls over, and at some point it will, the person with Ollama already running keeps working. The download alone is a reason to do this at home rather than on the network in Kraków.
Between the two local options I would take Ollama, because it installs like a normal app and exposes a local endpoint a connector can target. llama.cpp through llama.app is the lighter route if you already live in a terminal. Neither needs an account, which matters when you don’t want another vendor relationship just to test a plugin.
I would set up both, cloud as primary and local as fallback, which is also what the team recommends. If you maintain client sites there is a second question to settle first: who owns the provider key and where it is stored. The key encryption that arrived with the AI plugin changed the answer, and I wrote about what to check there before you paste credentials into a fresh install.
Who the Core AI Contributor Day is for
The table lists three tracks: testing, QA and feedback on WordPress 7.0 and AI plugin v1.0, documentation for the handbook and developer docs, and good first issues across the team’s repositories and core. That covers most skill levels. A bug report with clean reproduction steps counts, and so does a handbook page that no longer matches the current screens, which happens fast while these APIs keep moving.
it’s “Contributor Day”, not “Contribution Day”, and our focus for the day revolves around finding meaningful ways to contribute, and not necessarily landing a specific patch.
The team also warns that work started on the day may land in 7.1 or later, and suggests picking tickets that can move in a few focused hours. That matches how core releases run, and it takes the pressure off shipping something before the 16.30 wrap-up. Remote contributors get the same table through Slack, with Singh running the digital side. I wrote a longer playbook for the Core AI table at WordCamp US, and almost all of it still applies here.
What I’d do the night before
The order matters less than doing it at home, but this is roughly mine, with the downloads first because they are the slow part.
- Pull a model with Ollama and send it one test prompt, so you know it answers before you need it.
- Create the Mistral key, install the connector plugin, and run one generation in a fresh Playground.
- Walk through the AI plugin’s screens once, so you spend the day testing features rather than hunting for them.
- Set up Docker, Node, Composer and Python 3.10 only if you expect to touch code or benchmarks.
I’m still left with one question. How much of the feedback that day will arrive through small local models because the wifi forced it? If half the room falls back to a laptop model, the team has to tell rough features apart from rough models when triaging, and I’m not sure that distinction survives a busy issue queue. Ask the table leads directly. And if you’re flying out with a client site that still needs a provider connected or the AI plugin reviewed, that’s work I do, so get in touch before you pack.
