Yuga

• 

  Landing page

• 

  Intake form

• 

  Sample from world bible

• 

  Agent run log

• 

  Auditor detection test

• 

  Token usage stats

• 

  Delivered email

The problem we chose

Every worldbuilder hits the same wall: the blank page. A game master with a session on Friday, an indie developer who needs a setting their mechanics can live in, a self-publishing author who needs a world for their story to stand on. The obstacle isn't imagination — it's the overhead of turning an idea into a coherent, usable foundation. Existing tools mostly hand you an empty wiki and wish you luck.

Yuga doesn't build the world for you. It gives you a foundation you own and shape: a structured world bible deep enough to start from and specific enough to argue with.

Why this is AI-native, not AI-assisted

Yuga is not a chatbot with a worldbuilding prompt. It is a multi-agent production pipeline in which the AI executes the key creative decisions.

A buyer submits genre, scope, and themes. A Loremaster (Gemini 2.5 Pro) interprets the brief, sets the world's core premise, and directs five specialists running in parallel on Gemini 2.5 Flash — Cartographer, Historian, Culture Designer, Linguist, Ecology Architect — each generating against that shared premise. A seventh agent, the Consistency Auditor, reviews the assembled world for internal contradictions. The output is a structured world bible in PDF and Markdown, delivered in under two minutes.

What the central tension is, how history and geography and culture interlock, where the world's originality actually lives — those decisions are made by the models in production, on every generation. The human sets the brief. The AI runs the pipeline.

The evidence, including the part that isn't flattering

We ran a blind A/B evaluation: the full pipeline against a strong single-prompt baseline, scored by a three-judge LLM panel. On a small sample (n=3) the pipeline won two of three, separated by a measurable originality delta of +0.67. We report the sample size because it is small.

The more useful story is what happened next.

Our Consistency Auditor had been rating worlds clean. Then a user we had given a free world bible to read it closely and found a contradiction the Auditor had missed: a world with no metal geology that nonetheless ran on piston-and-gear technology.

We treated that as a production incident. Fed a world containing four known cross-section contradictions, the Auditor flagged zero of four. Run five times against one unchanged world, it returned five different verdicts.

Our first diagnosis was wrong. We concluded the Auditor was sampling section pairs rather than checking them exhaustively — a coverage problem. Reading a live production run disproved it. The prompt already contained an exhaustive pairwise step; the model found one genuine contradiction, quoted both passages, proposed a sound resolution, then declared the step complete and stopped. The failure mode was satisficing, not coverage.

The fix followed from the corrected diagnosis. The pairwise step is now fifteen individually enumerated calls, each required to return a verdict row, so no pair can be silently skipped and the task cannot be discharged after a single finding. Determinism is restored: five runs, five identical results. One defect remains open and we are not claiming otherwise — with enumeration guaranteed, the model still returns "clear" on contradictions we know are present. Coverage is fixed. Sensitivity is not.

The hard part of running AI in production is not getting a model to generate. It is building the instrumentation to know when it is wrong. We found this ourselves, measured it, traced it to a root cause we had to correct once against a live run, shipped the fix, and disclosed what remains broken — rather than shipping a consistency guarantee we cannot substantiate.

The same instinct produced our cost data. Rather than estimate, we instrumented the pipeline to capture token usage directly from live API responses. That surfaced something an estimate would have hidden: reasoning tokens account for 72% of billable output and are invisible in the generated text. Measured cost per world bible is $0.093 across the reporting window. The Auditor rebuild described above raised it to $0.191 going forward, which is what a run costs today — we report both rather than quoting whichever is lower.

Viability, honestly

We have earned no arms-length revenue in the window. We treat that as the central open question, not a footnote.

What the data does establish is the shape of the business underneath it. Against a $19 price, inference costs 9.3 cents across the reporting window and 19.1 cents at the current architecture — one percent of price at worst. Infrastructure runs flat and is currently absorbed by free-tier capacity. The largest per-sale cost isn't the AI at all; it's payment processing, estimated at roughly $1.45 from the processor's published merchant-of-record rate — still several times the cost of generating the product. Contribution margin is 92% for the period and ~91% forward, verified two independent ways: token instrumentation and the cloud billing ledger agree. Total operating expense for the period is $60.65. Customer-acquisition spend is $0.00.

The economics work. Demand is unproven. Those are different problems, and we know which one we have.

Our go-to-market is organic and manual: free custom world bibles offered to real world-needers in exchange for structured feedback, with every interaction logged. To date the log holds eighteen entries across seven communities and platforms — two soft-promotional posts, one world bible delivered, one substantive feedback response (the geology catch above, which became a prioritized engineering fix), two server applications, and twelve documented scanning passes that produced zero qualified candidates. In one such pass we evaluated roughly three hundred posts and replied to none of them, because none were the customer we built for. The volume is small and we are not going to present it as anything else. Distribution is the problem we are working, and the log is its honest record — including the days it records nothing.

Category relevance — Entrepreneurship & Job Creation

Yuga's customers are themselves micro-entrepreneurs. The indie developer shipping a commercial game, the self-publishing author with a book to sell, the game master running paid sessions — each is a one-to-three-person business whose output is capped by content production they cannot afford to outsource. A commissioned world bible costs hundreds of dollars and takes weeks. Yuga delivers a comparable foundation for $19 in minutes, and the buyer owns the output outright, in open formats, with no subscription or lock-in.

That doesn't replace creative labour; it removes the unpaid overhead sitting between a small creator and a shippable product. The 92% margin matters here too: the price can stay where solo creators reach it while the business stays viable.

The entrant is the same case. One founder in India, under a $200 total budget, selling cross-border through a Merchant-of-Record layer built for individual sellers who can't access conventional payment rails.

Category impact — the position we're defending

The 2026 worldbuilding-tool category is racing toward persistent memory: campaign managers that track every NPC and faction across sessions. That's a real direction, and it isn't ours. Yuga is deliberately the opposite — the best possible cold start. Competitors are becoming tools you live inside; Yuga is the foundation you begin from and take anywhere.

For the deadline-pressed GM, the under-resourced indie developer, and the self-publishing author, the scarce resource isn't session memory. It's the first solid thing to build on. The more the category crowds toward memory, the clearer that gap becomes. What exists is live, in production, and generating worlds today.

Origin and prior work

Yuga was created new for this hackathon. The first commit dates to May 29, 2026, after the May 19 start of the submission period. No pre-existing product, codebase, prototype, or prior version was carried in.

The project depends on standard open-source frameworks and vendor SDKs — FastAPI, Python tooling, and client libraries for the Gemini API, Dodo Payments, Resend, and Cloudflare — but uses no starter template, boilerplate repository, or scaffold. All application code, agent prompts, orchestration logic, PDF generation, evaluation harnesses, and diagnostic scripts were written during the submission period.

Built With

• cloudflare-workers
• dodo-payments
• fastapi
• gemini-api
• google-cloud-run
• python
• resend