In about 15 minutes, Claude Code turned my two-month-old study of AI plugins on WordPress.org into a live tracker with its own database, a scheduled job and a public URL. I didn’t write a line of the code, and I didn’t set up a server.
It did that on Spacefast, Automattic’s new publishing platform for AI agents. Spacefast soft-launched on September 22, and the next day Matt Mullenweg posted on X that the team behind it has been “cooking what I think is the future of @WordPress and AI.”
I wanted to see what that means in practice, so I spent some time letting Claude Code do the work while I watched. These are my first impressions.
Matt Mullenweg's launch post, Sep 23 (on X)
What Spacefast is
Spacefast is a place to put whatever your agent makes. You (or more likely your agent) hand it a folder, a framework project or a small app, and it hands back a live URL. It runs on wp.cloud, Automattic’s WordPress hosting platform, and the welcome page still calls it a “research preview.”
The parts that stood out to me:
- Every Space is private by default. You open it up to your team, a share link, a password or the public when you’re ready.
- Every publish creates a version you can roll back to in one click.
- Beyond static sites, it runs apps. Its Zero runtime gives each app a MySQL database, logins, file storage, email and scheduled jobs, configured from one file.
- It’s built for agents first. There’s a CLI, a REST API, a hosted MCP server and ready-made plugins for Claude Code, Codex and Cursor.
The detail I didn’t expect: every Space has a full WordPress install running behind it. Your published files sit in front, so a static site never touches it, but the database, the media storage and the app runtime are all WordPress underneath. You can even run WP-CLI against it. Batuhan İçöz, who created Spacefast and leads it at Automattic, showed off a Space rendered with PHP and Gutenberg blocks with the caption “this is WordPress. not headless WordPress.”
Batuhan İçöz, Sep 6 (on X)
WordPress sites can publish to Spacefast too. There’s a Spacefast plugin for WordPress, currently in private beta, that turns an existing site into a static copy with Simply Static and publishes it to a Space. It can also use WordPress as the content source for a separately built site, rebuilding it whenever you publish or update a post.
Getting Claude connected
Spacefast’s main onboarding path is a prompt you paste into your agent: “Fetch [this link] and follow the task inside.” The link returns a long set of instructions written for the agent, covering how to sign in, publish, check the result and report errors.
That link is a credential. Redeeming it gives the agent admin rights over your whole Spacefast team, including publishing, settings, domains and deleting Spaces, through an API key that lasts up to 30 days. The link itself expires about 15 minutes after you create it. My first one expired while I was still sorting out permissions.
The permissions were the problem. To redeem the link, the instructions tell the agent to run Spacefast’s CLI straight from npm and pass it the link. Claude Code runs with a safety layer that checks risky actions before they happen, and downloading code from the internet and handing it a credential is exactly what that layer is built to stop. It blocked the setup. I generated a fresh link and told Claude it had my permission, and it was blocked again. I added a permission rule to my settings, and the third attempt was flagged because the command didn’t match the rule exactly!
Frustrating start.
Eventually I connected it using Spacefast’s Claude Code plugin, which signs in through a normal browser login (OAuth). One install command, a reload, a sign-in page, and Claude could read my account. No expiring link, and no raw key in a terminal.
I don’t know if this is down to my own Claude Code setup and safety settings. Other early users seem to have had an easier time.
Onur Ozcan, Sep 23 (on X)
Building a live AI plugin tracker
In July, I published a study where I counted every plugin on WordPress.org and found that about 1 in 6 new plugins in 2026 was an AI plugin. It was a snapshot, and snapshots go stale, so I asked Claude to turn it into a page that keeps itself current.
As a warm-up, Claude first published a one-page summary of the study. That Space stays private, while the tracker is public.
What Claude built:
- A Zero app with two database tables, one for plugins and one for sweep runs
- A cron job that checks the newest plugins on WordPress.org every hour and classifies them. So far, Spacefast’s cron scheduler seems broken (bug report filed).
- My study’s Python classification rules, ported to TypeScript and checked against all 68,651 plugins from the July snapshot with zero differences
- History seeded from a fresh sweep of the full directory, which now lists 74,404 plugins
- A dashboard page with headline numbers, a monthly chart and a list of the newest AI plugins
It took about 15 minutes from the first file to the tracker going live at wp-ai-plugin-tracker.view.fast. A fresh sweep of the entire WordPress.org directory ran in the background and took longer than the build.
What impressed me most was how little setup there was. The scheduled job is one line in the project’s config file. The database tables are declared in the app’s code and created when you publish. Making the site public was one more line in the same file, and the scheduled job’s secret is stored on Spacefast as a write-only variable. There was nothing separate to wire up. To be clear, I did none of this! It was all Claude.
The numbers have moved since July, too. When I wrote this, the tracker counted 4,138 AI plugins, and 16.6% of plugins added in 2026 are AI plugins. The monthly share peaked at 19.2% in June and was 14.4% in September, a month that was also the biggest on record for new plugins overall, at 3,165.
What broke (according to Claude)
Spacefast is a research preview, so I expected rough edges. None of these stopped the build, and most are small documentation fixes.
- The project template Spacefast generates told Claude that apps can’t make outbound web requests, while the docs said they can. They can, which matters when the whole point of the app is calling WordPress.org.
- Each scheduled run gets about five seconds. Fetching one page of results from WordPress.org takes about three, so Claude designed the sweep to read one page per run and catch up over the following runs if it ever falls behind.
- Testing the app locally needed a cookie the docs don’t mention. Claude found it by reading the CLI’s source code.
- Making the tracker public through the plugin got stuck on an approval step and changed nothing. One line in the config file did the job instead.
Two questions I had going in
How is this different from a Claude artifact?
I use Claude artifacts all the time to share reports and drafts, so this was my first question. An artifact is a page that lives inside Claude. A Space is a real website.
| Claude artifact | Spacefast Space | |
|---|---|---|
| Where it lives | claude.ai | Its own address, or your domain |
| What it can be | A single page | Static sites, framework builds, full apps with a database and logins |
| Versions | Republishing replaces the page | Every publish is a version you can roll back to |
| Who can make one | Claude, in a conversation | Any agent, the CLI, the API or a Git push |
If the thing I’m sharing is for people already on Claude and won’t outlive the conversation, an artifact is quicker. If it needs to stand on its own, Spacefast is the better fit.
Can you publish a WordPress Playground site to Spacefast?
I haven’t tested this yet, so here’s what I’ve been able to find out so far.
The most promising route looks like the Spacefast plugin for WordPress. Its static mode exports a site with Simply Static and publishes the snapshot to a Space, and in principle that should work for a WordPress Playground site too. What I don’t know yet is whether it works from inside Playground, which runs WordPress in your browser tab. The plugin needs to sign in to Spacefast and upload files to its API from there.
As far as I can tell, a static copy is the ceiling either way. Anything that needs PHP on each request, like forms, search, comments or logins, won’t carry over. The plugin’s other mode, which uses WordPress as a content source for a separately built site, needs a WordPress site that Spacefast can reach on the public web, and a Playground site isn’t one. I also couldn’t find a documented way to run your own theme and plugins on the WordPress that sits behind every Space.
What it means for WordPress
I’ve written before that WordPress needs a new MTP for the agentic era. Spacefast is a clear move toward a new role for WordPress, and Mullenweg went as far as calling it the future of WordPress and AI.
Mullenweg’s launch post says “You don’t have to know or think WordPress” to use Spacefast, and that’s true as far as it goes. You don’t have to think about WordPress, but it’s doing all the work. Every Space runs on it, and Batuhan İçöz, Spacefast’s creator, has described it as aimed at sites that don’t use a CMS at all, with “a ramp to WordPress and WooCommerce as needed.” Mullenweg’s launch post also said he’d like Spacefast to host apps for Lovable and others for less than they pay now.
Last month I wrote about the SaaSification of WordPress: plugin companies adding hosted services and usage credits, and building SaaS versions of their plugins that don’t need WordPress at all. Spacefast looks like Automattic’s version of the same move. It’s a hosted service for people who will never install a plugin, with WordPress doing the work underneath.
It’s early, and the project is small. I’m interested to see where Spacefast goes, and I’ll be following along and building more on it as it grows.