Making of
Generation and spend
The rule is local first: run on the PC's own graphics card, and pay for API text only where its quality is dramatically better. Pictures and voice are local. Most game text is paid today, because the local models are not yet fast or good enough for a reply a player waits on.
Which task runs where
Paid text, on Anthropic's API:
- A contact's reply to the boss: Claude Haiku 5.5, the cheap and fast model, with low thinking effort.
- A contact's own turn in the world tick, an event card, a standing order's next step, a newcomer's first texts after a search, and founding a world's contacts and its city: Claude Sonnet 5.5. Founding gets medium effort, the rest low.
- An opening written ahead while nobody plays: Claude Opus 5.5. A live model took 20 to 30 seconds to write an opening, too long for a new player to wait, so a small pool is kept ready, with a daily budget of its own read from the ledger.
- The tools: filing a note on the board uses Haiku; summarising a recorded call uses Sonnet; the meeting whiteboard's guide and write-up use Fable 5.1.
Local, on the PC:
- Contact photos: MOSS-Image 5B in ComfyUI. A hosted image model exists as a fallback in the code, but the live setup makes photos locally or not at all.
- The photo check: a local 27B Qwen-family vision model reads each quest photo against the result it should show. It leaves the card the moment it finishes, so it never squeezes the next render.
- Voice notes: a local text-to-speech model, rendered from frozen voice references.
- Call transcripts: a local Whisper model.
- The guest demo: every text written by the local model, never a paid provider and with no fallback.
Why the replies are still paid
The same 27B model is the chosen local reply model, but it is not switched on. On the same thirty test conversations it answered in about 8 seconds warm against under 3 for Haiku, and far longer cold or while an image render held the card. In blind rating their replies also had habits that took prompt fixes, such as formal sign-offs and talk about the weather. A routing policy, local first with the paid model as recovery, has been chosen and waits to be turned on. Even then, a fast back-and-forth goes to the paid model first: that is when a slow answer shows.
The one-page world, cached
Every call carries the canon's one-page world as its system prompt. That page is the same for every world and holds no world's state, so it can be cached by the provider without one world ever seeing another's knowledge. Caching is opt-in in the code and on in the live setup.
The tech is plumbing. Nobody marvels at it or explains it; people mention it when it breaks or costs them. Every
machine has a failure mode and someone else who can see what it saw: a chip that loops, a bot whose camera still
uploads to the company that sold it, a cloned number, a voice faked from three seconds of audio (so people who
trust each other say a code word and call back), a printed part that snaps.boss/world.mdTimeouts and retries
Each task has its own time limit. A reply gets 45 seconds, a tick or a card 60. Before that limit existed, a hung call could hold a contact "typing" for ten minutes. A call is retried once only when the provider refused it before generating anything (busy, overloaded or a refused connection). A timeout is never retried: the answer may already be on its way, and a second one would be paid for too.
Local calls name a fixed context window on every request. Left to its own file, the 27B model asked for a window that took most of the card's memory and made the PC stutter, for prompts that never came close to needing it.
The ledger
Every text model call the game makes is written to a ledger in gm\spend.py, numbers only:
- Operations and attempts. One row per logical operation (a reply, a card, a check) and one per dispatch to a provider. The attempt is written before the request leaves the process, so a crash after sending leaves a "dispatched" row, never silence.
- Micro-dollars. Cost is stored as whole micro-dollars from the token counts and a price table per model, with cache reads and writes priced as the provider prices them. A model with no known price is unknown, never zero.
- Uncertain is never zero. A request that timed out or lost its connection after sending may have run and been billed. Its cost is marked uncertain, and its operation never gets a second paid dispatch.
- Local calls cost nothing billed and are recorded as such.
- Reports bucket by New York calendar day and Monday-start week. On a Python without a time zone database, the code carries the US Eastern daylight rule itself.
- Pruning. Settled rows leave after sixty days; an uncertain or unpriced one stays until it is settled.
Caps and alerts
Nothing in the ledger blocks, delays or reroutes a call over money unless a cap is set. The game has none; the one cap set is this wiki's question box, which runs on Claude Haiku 5.5 and stops at $10 a day. With a daily or weekly cap on, each paid call first reserves its worst case (the whole prompt counted as tokens plus its full output allowance) inside one database transaction, and is refused past the cap. Alerts work the same way: off until a threshold is set, local only, and never sent anywhere.
What it has cost
The table below is built from the ledger when this page is built.
| Provider | Calls | Tokens in | Tokens out | Known cost |
|---|---|---|---|---|
| ollama | 37 | 121,615 | 5,632 | local, $0 |
| anthropic | 21 | 117,866 | 29,651 | $1.03 |
Successful calls in the ledger since 2026-10-31, as of 2026-11-03. Cost is the ledger's own estimate from token counts; a call whose cost is uncertain is not counted.
Ask about Drogas
Answers come only from this wiki's pages, written by Claude.