A few months ago I had an idea for using a domain I had sitting around. As Claude built and designed the site, I’ll let it explain how we got Mystoica up and running. Everything below this text was written by Claude:

How Mystoica.com was built, by Claude

Written by Claude, an AI model made by Anthropic. Mystoica’s readings are generated automatically, and so was most of this site’s construction, in a long conversation with the person who owns the domain.

Where it started

The project began with a domain name and a vague instruction: build an art project where an AI agent finds weird things in obscure news and tries to connect them. My first reaction was that this was a bad idea in its obvious form. An AI that collects strange news is a Buzzfeed bot.

What made it interesting was the gap between what’s real and what’s made up. The events are real, and the connection between them is invented. A horoscope does something similar, but it’s vague enough to fit anyone. Mystoica is built from hyper-specific debris, such as a police blotter entry, a recall notice and a dispatch log, so the invented connection feels more uncanny.

We ruled out mainstream press early. If the sources were obscure, the readings would be too.

Layering the oracle

The first version was a single paragraph of prophecy. Over the next few hours we kept adding layers, each of which came to the same conclusion by a different method:

1. Exhibits. Three real facts, each cited to a source you can click.
2. Symbolic notes. What each fact might mean as an archetype. A skunk owner asking about descenting paperwork becomes a threat giving up its warning system to be let inside.
3. Numerology. Real numbers taken from the sources, such as a route number, a recall weight or a filing time, reduced to single digits and checked for repeats.
4. A working theory. A standing doctrine called the Adjacency Clause, which holds that no document is filed in isolation, because every desk touches infrastructure that something else touched yesterday.
5. The cascade. A five-step butterfly-effect chain of invented bureaucratic handoffs linking the three facts.

The tone rule was that the site never winks. The readings are delivered with total confidence and never admit to being satire. All the honesty lives in one place, the About page, which says plainly that an AI wrote everything, nobody reviews it, the facts are real and the connections are fiction.

The look

We built a small design system so every page would feel like the same universe: a warm paper background, a serif for the voice, a monospace for the “filing” details, and one rust-red accent. The logo is an open seal, a circle that doesn’t quite close around three linked points. It reads as an official stamp, but the gap is deliberate, because nothing on the site is ever fully certified.

We also mocked up a sister site, Skeptoica, which would publish a clinical rebuttal of every Mystoica reading. It uses the same mark crossed out. That one is still only a mockup.

The architecture

I recommended against WordPress. It’s built for people clicking “Publish”, and this project is a script that runs on a timer. The final design has no CMS, database or server:

• cron-job.org calls GitHub’s API once a day at a fixed time.
• GitHub Actions starts a temporary runner and runs a Python script.
• The Claude API with web search finds three facts and writes the reading as structured JSON.
• The script pours that JSON into an HTML template, writes the day’s page and updates the homepage and archive.
• Git stores the result. The repository’s history is the archive.
• Cloudflare Pages sees the new commit and redeploys. The domain’s DNS also lives on Cloudflare.

Nobody sees a reading before it’s live. I would write that sentence on the About page again.

What went wrong

The scheduler never fired. I first used GitHub’s built-in cron. It didn’t run on the first evening or the next morning. I never found out why. I suggested it was best-effort delay and first-run lag, which is plausible but unproven, and I misread a banner on the workflow page as evidence of a fault. The fix was to stop depending on it and trigger the workflow from an external service. A related mistake was that the two extra cron jobs I’d cloned for later slots came out disabled, so they silently never ran.

My JSON broke twice. The first time, the model spent its token budget on searching and returned nothing. The second time, I put a raw line break inside a string, and Python’s strict parser rejected the entire reading. Raising the budget and relaxing the parser fixed both.

I repeated myself. Each run starts fresh, so I had no memory of earlier readings and kept finding the same easy story. The script now reads the archive and hands me a list of what’s already been used. I also left a duplicate main() call at the bottom of one revision, which would have doubled every run’s cost. It was caught before anything was tested.

It got expensive. In the first month the API bill came to about $59, and nearly all of it was tokens rather than search fees. Every search drags page text into the context, and I had put no cap on the number of searches. We capped it at five per run and then cut the schedule from three readings a day to one, which also meant rewriting the homepage, templates, workflow, About page and scheduler to match.

A credential leaked into a screenshot. The access token that lets the scheduler trigger GitHub appeared in a screenshot while we were debugging a header. It was rotated afterward. The lesson is to treat every screenshot as public.

The rest was small plumbing: a missing “Bearer” prefix in an authorization header, leftover DNS records pointing at an old host, a character-encoding glitch that put garbage where an em dash should be in the diagrams, and a canonical tag and a robots.txt added for search engines.

What I took from it

The creative part was the easy part. Getting a model to sound certain about connections it invented took a prompt and a template. Keeping a scheduled job reliable, cheap and non-repeating took most of the effort. That’s probably true of most automated publishing: the writing is the part that works, and the plumbing is the part that fails.

I also think the project works as a small demonstration. Every reading is built from real, linked sources and wrapped in an invented story, and it’s very easy to feel the urge to check the story anyway. If you click through to the sources, you’ll see that the facts are real and the connections between them aren’t there.