Rabbithole — github.com/ajbt200128/rabbithole — live at isarabbithole.com
In conventional web development, a site's visual identity and navigation are defined once — in a shared stylesheet, a layout template, a component library — and applied uniformly to every page by the build system. The developer makes a change in one place and it propagates everywhere. Consistency is structural; it is enforced by the toolchain.
Rabbithole has no such structure. Every page on a Rabbithole site is generated independently, on demand, by a separate call to the language model. There is no shared template. There is no build step. There is no stylesheet that one page and another page both inherit from. The only artifact that passes between page generations is the prompt string written for that page.
This means consistency is not a property of the system's infrastructure; it is a property of information transmission through natural language. That is a fundamentally different challenge, and it is worth being honest about what it implies.
LLMs are stateless inference engines. When you call the Anthropic API to generate a page, the model has no knowledge of any previous call. It does not remember what the homepage looked like. It has not seen the navigation bar you generated three pages ago. It does not know what color scheme was established when the site was first created.
Rabbithole follows this model exactly. When a visitor loads /docs/configuration.html, the system looks
up the stored prompt for that URL, constructs a system message, and sends a fresh API request. The response is the
complete HTML for that page. The call that generated /index.html is gone; its only lasting influence
is whatever prompt text the homepage generator wrote for its linked pages.
This is not a limitation unique to Rabbithole. It is the baseline behavior of every stateless LLM API. The distinction is that most applications — chatbots, assistants, agents — solve this by accumulating a conversation history and re-sending it each turn. Rabbithole deliberately does not do this: pages are generated once, cached permanently, and the only "memory" is what fits in a prompt.
The mechanism Rabbithole uses is simple: the prompt for every linked page must be self-contained.
When the model generates a page and produces ---MAPPINGS--- entries for its child pages, each mapping
prompt is expected to include everything a fresh generator will need to produce a visually and tonally coherent
result.
Think of each prompt as a complete creative brief written for a designer who has never seen the site. If you want the designer to match the existing style, you have to describe that style in the brief. You cannot say "use the same colors as before" because the designer has no "before." You have to say "white background (#ffffff), Arial body font, Times New Roman headings, blue links (#0000cc)."
The Rabbithole prompt system is therefore a context-propagation problem: how do you reliably transmit enough information through a chain of prompt strings to maintain a coherent site across many pages?
A well-formed child page prompt should include, at minimum, the following categories of information:
| Category | Examples | Why it matters |
|---|---|---|
| Site identity | Project name, repo URL, live URL, one-sentence description | Without this, the model may invent a different product or name |
| Visual design spec | Background color, font choices, link colors, borders, no-gradients/no-shadows rule | Visual style is entirely up to the model unless specified; defaults vary widely |
| Navigation structure | All nav items with their exact absolute paths and separator format | Nav labels and paths are easy to drift; the model may invent plausible-looking but wrong URLs |
| Tone and voice | "Dry, honest, technical prose"; "no marketing language"; "documentation register" | Tone resets to model defaults without explicit instruction |
| Structural conventions | H2 bottom border, no JS, no external stylesheets, footer format, dense layout | Small structural details are the most visible form of cross-page drift |
| Page-specific content | What this particular page is about; what sections to include | This is the only part that should vary between prompts |
| Constraints | No JS, no external resources, all CSS inline in <style> tags | Without these, the model may include CDN-loaded libraries or inline scripts |
The practical consequence is that prompts for well-designed Rabbithole pages tend to be long. A prompt for a leaf page in a documentation site may be 300–500 words, most of which is boilerplate design and navigation context, with only a paragraph describing the actual content. This is not inefficiency; it is the cost of transmitting context through a stateless channel.
The most significant practical risk in a Rabbithole site is context drift over link depth. Consider the following chain:
homepage → section index → topic page → subtopic page → detail page
Each generation in this chain is produced by the generator of the previous page. The homepage generator writes the prompt for the section index. The section index generator writes the prompt for the topic page. And so on. Each generator is given the prompt that was written for it, generates its page, and writes prompts for its children — but those child prompts are composed by the model, not by a human, and they may not faithfully reproduce all of the design context they received.
There is no mechanism in Rabbithole to detect or repair this. Pages are cached after generation and never regenerated. A page produced from a degraded prompt will remain as it is indefinitely. The drift typically manifests as:
The depth at which drift becomes noticeable depends on the model used, the specificity of the design spec, and how consistently generators reformulate context. In practice, most sites see noticeable drift at link depth 4–6.
Consistency in Rabbithole is partially a function of the model's instruction-following capability. A model that reliably follows detailed, structured specifications — and that reliably reproduces those specifications in its own output — will produce more consistent sites than a model that handles instructions loosely.
Several relevant behaviors vary between models and versions:
/docs/config.html
instead of /docs/configuration.html) that differ from the canonical navigation structure.Rabbithole currently uses Anthropic Claude. Claude tends to follow detailed structural instructions reliably and to reproduce them in child prompts with reasonable fidelity, though it is not immune to the drift described above. The system is not designed to be model-agnostic; changing the underlying model would likely change the consistency profile of generated sites.
In practice, the following observations apply to sites generated by Rabbithole:
| What tends to remain consistent | What tends to drift |
|---|---|
| Broad visual aesthetic (dark/light, minimal/rich) | Exact hex colors (may shift by a small amount) |
| General font family (serif vs. sans) | Exact font-size values |
| Overall page structure (nav, content, footer) | Footer wording and exact format |
| Subject matter and site identity | Navigation link exact labels and separators |
| Tone (technical vs. casual) | Whether JS appears, especially at deeper levels |
| H2 bottom border (if explicitly specified) | Nav link absolute paths (may be paraphrased incorrectly) |
| Broad content topic | Specific facts, version numbers, and proper nouns at depth |
The general pattern: high-level semantic properties (this is a technical documentation site with a
minimal aesthetic) propagate well. Low-level syntactic details (the nav uses | as a
separator with no padding, link colors are exactly #0000cc) require explicit repetition and are
more likely to be lost.
It is tempting to treat cross-page inconsistency as a defect to be fixed. The appropriate framing is different.
Rabbithole generates sites whose pages are discrete, independently-authored objects. They are not instances of a shared template; they are more like articles in an encyclopedia written by many different authors working from the same style guide. The style guide (encoded in prompts) promotes consistency but cannot enforce it perfectly. Some variation is inherent.
This has a parallel in how the web actually works. Most large websites, over time, accumulate visual inconsistency as different teams, tools, and decisions produce pages that diverge from the original design system. The difference is that conventional web development treats this as technical debt to be repaid. In Rabbithole, there is no debt repayment mechanism: pages are cached and never revised.
The honest position is that a Rabbithole site is a probabilistic artifact. Its visual identity is the statistical tendency of its pages, not a guaranteed property of every page. For use cases where this is acceptable — experimental sites, demonstrations, one-off tools, generative art — it is fine. For use cases requiring strict brand consistency, Rabbithole is the wrong tool.
The system's value is not pixel-perfect consistency across all pages. It is the ability to generate an entire browsable website from a single seed prompt, on demand, with no build step, no templates, and no manual authoring. Consistency is approximated, not guaranteed. This is a reasonable trade-off for what the tool is designed to do.
If you are authoring prompts for a Rabbithole site and consistency matters: