Z-Town: 25 residents, one gaming GPU

The problem

Most non-player characters run on scripts and behaviour trees, so they do what they were written to do. A language model can choose more freely, but a typical transformer keeps every token it has read in a KV cache, so the memory a character takes grows the longer it plays. With many characters in a long session, that growth has to be budgeted.

Z-Next, our own architecture, has no attention layer and no KV cache. Each session is held in a fixed-size state. When we grew the input from 952 to 31,926 tokens, the state stayed the same size. Z-Town is where we test whether that property is useful for game characters.

What we built

Willowbrook is a small 3D village of 25 AI residents. They work, eat, travel and visit each other. Each resident is its own Z-Next session, and all residents share one copy of the model. Decisions come from the Z-Next product variant.

The village keeps a word-for-word record of what happens, including each resident's diary. Everything we quote on this page comes from that record.

What the game rules do, and what the model chooses

If the model is not available, residents wait; no rule-based fallback acts for them.

The record says what a resident did. It does not say why, and we do not add motives.

How it runs

The whole village runs on one Linux PC with one NVIDIA RTX 5070 Ti: one shared copy of Z-Next and 25 resident states. Visitors need only a browser. Z-Next's weights take about 3.8 GB in fp32, and the model runs on a 16 GB GPU.

Because each state is fixed in size, adding a resident adds a known amount of GPU memory, and that amount does not grow while the village runs. After a restart or an update the same residents carry on from where they stopped.

Village time runs faster than real time, so village days in the record do not match calendar days.

Speed. A resident's decision takes about a second. The measured figures are in the shipping questions table.

Results from the record

The village started on 24 October 2026. The first table is from the village's statistics screen on 11 November 2026. The second holds the counts that have no newer value; they are as of 28 October 2026.

Each of those five software updates paused the village briefly; afterwards the same residents carried on, and so did the village clock. Refusals count only invitations the invited resident actually answered; busy or missed invitations are not counted. No script or rule produced them: each refusal was the model's choice for the invited resident at that moment.

These counts show that residents' choices vary and are not scripted. They do not show that choices get better over time.

One morning, word for word

Clara Silva had eaten twice before Iris Reed came to see her, and did not talk with her; Iris ate at 10:08. That is all the record holds about this moment.

What is not done yet

• Open conversation. Visitors can talk with residents in the live village today, with no account. It is a 1B model, so replies can be wrong or drift; the figures on this page come only from what the village record logs.
• Audience and language. The village is open to adults only. Residents speak and decide in English. The village interface also offers Turkish.
• Learning. Residents learn from what they live: after each village night the model is tuned on the village's own record. We are still measuring how much that changes their behaviour, and will publish the figures when we have them.
• Recall. The fixed-size state is about memory cost per character: how much GPU memory each one takes. Recall, meaning remembering what was said many turns ago, is a separate and weaker result at this model size. On a natural-language needle test, Z-Next's long-context recall was 0.306 against a chance level of 0.25. That is at 1B parameters and 10B training tokens, and the same-size transformer is also near chance.
• Speed. Each Z-Next step is slower than a step of a comparable transformer, and serving hundreds of live sessions together has not been measured in the village.
• Safety. Z-Next has had no safety tuning: no RLHF, red-teaming or content filter. A game shipped to players would need this work first.
• Platforms. Today it runs on NVIDIA GPUs with PyTorch and CUDA. Quantising the model, fixing seeds and measuring on your hardware are part of a pilot. A port to a console or mobile runtime is a separate piece of work that we scope with you.

Stack

The product variant passed 14 of its 17 pre-registered gates, so it is recorded as a fail. It is still our best chat variant, so Z-Town uses it, labelled as not passing. The Z-Next model card and the system card give the full evaluation.

Shipping questions for game studios

Pilot one character in your game

You tell us about the scene, the character and the constraints of your game. We reply within one working day and tell you whether we can help. A first job is a pilot of one character in your build, on an NVIDIA GPU, and takes two to four weeks. Its scope and price are fixed in writing before it starts, and you owe nothing until you accept them. Larger work is quoted only after it, when both sides have the pilot's numbers.

The pilot puts one Z-Next character into your build. You get the measured memory per character and decision speed, and the character's full decision record.

The steps

1. After a first call, you send us the moves your character may make and the game state it can see.
2. We connect one Z-Next character to your build.
3. We run it on your hardware and measure.
4. We review the numbers with you.

A pilot measures decisions first; a spoken line with each move is optional. Z-Next weights are not published, so the pilot runs under NDA.

If your studio wants a smaller first job, such as a forecast built from the player data you already keep in spreadsheets, or a review of what that data can support, see our smaller jobs.

To see the village itself, enter the live village, or watch the 31-second teaser on Hugging Face.