The Bel's handbook for House of Ur

What House of Ur is

House of Ur gives you a private House for working with AI servitors. If you are using the product, you are the Bel of that House. In practice, that means one place for your long-running Dubsars, your specialist servitors, your House Library, your Vault credentials, and your own preferences in Bel's Chamber.

This alpha is intentionally small and personal. It is not a public signup product. You need an invite code to get in, and once you are inside, the main idea is simple: use Dubsars for ongoing work, use other servitors when they are a better fit, keep documents in the Library, and keep secrets in The Vault.

The Bel

In House of Ur, the user is called the Bel. That is simply the title for the human owner of a House. In plain terms: if this is your House, you are the Bel.

The product uses this title throughout the interface. You will see references to your Bel name, Bel-facing messages, and Bel's Chamber. None of that means a different kind of account. It just means you, in your role as the person directing the House and its servitors.

Start here

If you are brand new, this is the shortest path from invitation to a useful first Dubsar.

1. Sign in with GitHub. House of Ur uses GitHub authentication.
2. Enter your invite code. This is a closed alpha, so you need an invite code before your House can be activated.
3. Enter the House. After activation your House is active immediately. You can visit House Hall, the Library, Vault, and other rooms without subscribing first.
4. Subscribe in Treasury when you want AI. Open Treasury to start a plan when you are ready for Dubsar wakes, servitor chat, web search, and creating new servitors. Without a subscription, those provider features are blocked with a clear message pointing back to Treasury.
5. Create your first Dubsar. Requires an active subscription (or a Lugal-marked test House). See Dubsars and Common workflows.

Your first three good moves

• Create one Dubsar in Servitors' Quarters.
• Upload one file or folder you care about to the House Library.
• Add any key credentials your Dubsar will need in The Vault.

Houses and rooms

Your House is easiest to understand as a small set of rooms with clear jobs.

House Hall

House Hall is the foyer, not the workshop. It orients you, surfaces the latest entry from The Daily Tablet, and sends you onward to the rooms where work happens.

Servitors' Quarters

This is where you create and manage your workforce. If you are deciding what to do next, this is often the most important room.

House Library

The Library is for files and folders: reference material, notes, prompts, images, datasets, and working documents.

The Vault

The Vault is for credentials, not documents. If a value would be dangerous to leave in a normal file, it belongs here instead.

Bel's Chamber

Bel's Chamber is for your own settings: display name, Bel name, and timezone. Provider billing is managed in Treasury, not here.

Treasury

Treasury is where you subscribe to a monthly plan so your House can use OpenRouter models and Brave web search. House of Ur bills through Paddle; usage is metered and visible in Impressions and Usage charts.

Without an active subscription, you can still sign in, browse House Hall, use the Library, store non-provider secrets in The Vault, and read messages — but servitor LLM work, web search, and creating new servitors require Treasury.

Servitor choices

A servitor is a worker the Bel creates for a specific style of job. In this alpha, most Bels should lean toward Dubsars first and treat the other types as more specialized tools.

In broad terms, servitor types run from most capable to least capable like this: Dubsar, Igigi, Apkallu, Kalu. The trade-off is that the more capable the servitor, the more capable, and usually more expensive, the underlying model may need to be. Dubsar is the default choice, but the simpler types are still valuable, especially if you want to work with smaller, cheaper, or older models.

About model choice

When you edit a servitor, you will see a very large list of model IDs. That list is coming from OpenRouter. You are not expected to memorize it, and you are free to experiment. Model choice is part of how you learn what works for your own style of use.

Dubsars

Dubsars are the center of gravity of House of Ur. A normal servitor session feels like opening a task. A Dubsar feels more like assigning a continuing role to a worker that keeps a timeline, wakes when needed, and builds up its own history.

How to think about a Dubsar

• A Dubsar has a timeline, not just a chat log.
• It can be asleep, awake, or in maintenance.
• It maintains an Identity and a Work List over time.
• It keeps a work list and other state over time.
• It can react to messages, timers, and other incoming events.
• Unread badges matter because the Dubsar may have sent you something while you were away.

Identity and Work List

A Dubsar maintains two especially important internal structures: its Identity and its Work List. These are updated by the maintenance model based on the ongoing conversation in the timeline.

In practical terms, this means you do not have to fill in a special form to shape the Dubsar. You can just tell it how you want it to behave, what you want it to be, and what you want it to do. Over time, the Dubsar's Identity is updated to reflect the role, style, and standing instructions it should carry forward.

The Work List is how the Dubsar keeps track of ongoing work. It remembers tasks, whether they are active, blocked, waiting on something, or otherwise not yet complete. This is a big part of why Dubsars are useful for long-running responsibilities instead of one-off chats.

Main model vs maintenance model

A Dubsar can use two different models. The main model is the important one: it handles the core agentic work. The maintenance model is for lighter-weight maintenance stages, so it can often be smaller and cheaper.

Sleep / wake cycle

A Dubsar moves through a simple cycle:

• Asleep: the default state. The Dubsar is doing nothing and costing nothing.
• An event arrives: the Bel types in the timeline, a webhook message arrives, a timer fires, or another Dubsar sends a message. The Dubsar transitions to Awake.
• Awake: the Dubsar checks the incoming event and its Work List, then keeps processing tasks until there is nothing left it can currently do.
• Maintenance: the maintenance model analyzes the conversation and updates the Dubsar's Identity and Work List where needed. Then the Dubsar goes back to Asleep.

Model guidance for Dubsars

The available model list is the OpenRouter model list. It is big on purpose. You do not need to get the choice perfect on day one, and it is normal to experiment.

• openai/gpt-5.3-codex - an excellent agentic workhorse for the main Dubsar model.
• openai/gpt-5.4-mini - cheap and useful, especially as a maintenance model.
• z-ai/glm-5 - cheap, competent, and a sensible Dubsar option.
• google/gemini-3-flash-preview - cheap and cheerful, but do not trust it with anything important.

Timeline first

The timeline is where you see the life of the Dubsar: messages received, messages sent, wakes starting and ending, timers being set or fired, and tool activity. If you want to understand what a Dubsar has been doing, start there.

Timers and recurring work

A Dubsar can be told to do something later or on a repeating schedule. In practice, that means you can ask for things like tomorrow at 9am, do ... or every Monday, do .... This is one of the reasons Dubsars are so useful for ongoing work instead of one-off tasks.

Webhook input

A Dubsar can also receive incoming information through a webhook. In simple terms, that means an external system can send information directly into the Dubsar's timeline. This is useful when you want a Dubsar to react to outside events, such as website activity, system notifications, or data from another service.

Dubsars and Library files

Dubsars can maintain files in the Library. That means they can use Library documents as working material, keep notes there, and update or maintain files over time as part of their ongoing responsibilities.

Dubsars working together

You can also ask Dubsars to work together. For example, you can say things like ask Dubsar Fred about X or tell Dubsar Mary to do Y. This is useful when one Dubsar should consult another, hand off work, or coordinate with a more specialized Dubsar.

Good uses for Dubsars

• Following an ongoing project where work arrives over time.
• Keeping track of a queue, checklist, or evolving body of responsibilities.
• Handling timed follow-ups or periodic nudges.
• Acting as a long-lived worker whose history matters.
• Web research tasks where you want live search mixed with memory and continuity.
• Monitoring and managing external systems, such as a website, WordPress site, Shopify site, or AWS account.

Optional payload logging (Dubsars)

By default, House of Ur records metadata about OpenRouter and Brave usage in Impressions — model name, token counts, search queries, and so on — without storing full prompts or responses. If you need the actual request and response bodies for a specific Dubsar while debugging, you can turn on optional logging per Dubsar.

1. Open the Dubsar and go to Settings (from the timeline, use the Settings link).
2. Click Edit.
3. Scroll to the Impressions logging section.
4. Enable one or both checkboxes:
   • Log full LLM requests and responses (7-day retention) — OpenRouter traffic for this Dubsar.
   • Log full web search requests and responses (7-day retention) — Brave Search traffic for this Dubsar.
5. Save. New usage after that point may include a View request/response action in Impressions.

OpenRouter

OpenRouter is the model gateway behind House of Ur. Every LLM request from your servitors goes through House of Ur's platform OpenRouter account, gated by your Treasury subscription. You do not create or paste your own OpenRouter API key in the app.

What you need to do

1. Activate your House with an invite code and sign in.
2. Open Treasury and subscribe when you want model access.
3. Create servitors and pick models from the in-app model list (sourced from OpenRouter).

Why it matters

• All model selection in House of Ur is based on what OpenRouter makes available.
• The large model picker list you see in the product comes from OpenRouter via House of Ur.
• Usage is recorded per House in Impressions; Treasury covers provider spend included in your plan.

Where to check usage

Use Impressions and Usage charts in the app for house-level and per-servitor activity. For subscription status and billing, use Treasury.

Brave Search

Live web search for supported servitors (such as Apkallu) uses Brave Search on House of Ur platform keys, included with your Treasury subscription. You do not add Brave API keys in The Vault.

What you need to do

1. Ensure your House has an active subscription in Treasury.
2. Use a search-capable servitor such as Apkallu or an appropriately configured Dubsar.

Why it matters

• Web search requires both a capable servitor and an active subscription.
• If your subscription lapses or needs attention, search and other provider features stop with a Treasury-oriented message.
• Search usage appears under usage impressions in Impressions.

Impressions

Impressions is the House's record of facts: what happened, when it happened, and who or what was involved. Think of it as an impressed timeline rather than a chat log or a cloud log console.

Open the room from the House Hall (📜) or the app sidebar under Impressions. The address in the app is /house/impressions.

For a summarized view of metered work, open Usage charts from the sidebar. The address is /house/impressions/charts. It uses aggregated metric buckets derived from Impressions, rather than reading every timeline row directly.

What you will see

Most rows are one of two broad kinds:

• Usage — metered work your servitors perform on your behalf. In this release that includes OpenRouter chat completions and Brave web searches. Each row usually shows the model or query, token or result counts, provider, and which servitor did the work.
• Audit — house-level events such as when you sign in or out, when a servitor is created or deleted, and when Dubsar settings change. These help answer “who did what in this House?” without digging through unrelated logs.

Click a row to open the Detail panel: impression id, class, occurred and received times, actor, outcome, and servitor name when the event belongs to a particular worker.

Filtering and bookmarks

Use the filter bar to narrow the timeline: family, class, servitor, timeline mode (occurred vs received), date range, and optional provider, verb, or outcome. Change what you need, then click Apply filters. The list does not refresh on every keystroke — that keeps the room predictable when you are building a query.

The URL updates when you apply filters, so you can bookmark a view or use the browser back button to return to an earlier query. If you filter by servitor, the timeline uses occurred time only (received timeline is not available for servitor-scoped queries).

By default you see active impressions only. To include voided rows (for example after an administrative correction), enable Include voided impressions and apply again.

Usage charts

Usage charts turns metered usage into a chart you can read by day or by hour. It is useful when you want to see the shape of your House's work: cost estimates, token volume, and request counts over a selected range.

Choose a metric, date range, granularity, and scope, then click Apply. The chart can show the whole House, a single provider (OpenRouter or Brave), or one servitor. For cost, you can view OpenRouter and Brave search together or separately.

• Cost (USD) — estimated LLM cost from OpenRouter metadata plus Brave search cost at the current per-search formula.
• Tokens — input tokens and output tokens separately, rather than one combined total.
• Requests — completed OpenRouter chat calls and Brave searches.

Totals and bars come from hourly metric.hourly buckets. Recent raw usage may not appear until the hour has closed and aggregation has run, usually about fifteen minutes later. Treat the cost chart as a trend and debugging aid, not as a final invoice; Treasury and Paddle remain the billing source of truth for your subscription.

Optional full request and response bodies

Metadata is always recorded for supported usage. Full HTTP-style payloads are not stored unless you opt in per Dubsar — see Optional payload logging (Dubsars). When logging is on, supported rows offer View request/response in Impressions (preview and download; large bodies may be truncated in the preview).

Shortcut from a Dubsar

While you are in a Dubsar conversation, the header includes an Impressions link. It opens the room filtered to that Dubsar's OpenRouter usage over a default recent date range — useful when you want to see what that worker has been calling without building the filter yourself.

What Impressions is not

Impressions is read-only for Bels in this release: browse, filter, inspect, and optionally view payloads. Usage charts adds a house-level summary, but it is still not a billing ledger, export tool, budget enforcement system, or replacement for OpenRouter's own activity pages. Impressions does not show arbitrary executor shell output — only the impression types the House records when trusted services complete work.

Library and Vault

Many early mistakes come from mixing these two up. The easiest rule is this: if a value should remain secret, put it in The Vault; if it should behave like a document, put it in the Library.

House Library basics

• Create folders to keep material organized.
• Upload files into the current folder.
• Open files when you need to inspect them.
• Rename or delete material when the structure gets messy.
• Think of the Library as shared working memory for the House.

The Vault basics

• Add credentials with a clear name and description.
• Decide whether all servitors can use the credential or only specific ones.
• Rotate a credential by setting a new value.
• Delete credentials you no longer need.
• Expect some entries to appear as built-in system credentials rather than custom user-created ones.

Using Vault credentials with a Dubsar

A powerful pattern in House of Ur is to add credentials in The Vault, make them visible to your Dubsar, and then tell the Dubsar to use them to work with an external system. That might be a WordPress site, a Shopify site, an AWS account, or another service with an API or login flow the Dubsar can operate.

Often the Dubsar will know exactly how to proceed once it has the right credentials and a clear goal. If it struggles, explain the details in the timeline, and if the instructions are longer or more structured, write them into one or more Library documents and tell the Dubsar where to find them and when to use them.

OpenRouter and Brave (providers)

You do not store OpenRouter or Brave Search API keys in The Vault. Those providers are operated by House of Ur and gated by your Treasury subscription. The Vault is for your third-party credentials (hosting APIs, CMS logins, custom integrations).

Legacy provider keys

Older alpha Houses may still show builtin OpenRouter or Brave credential slots in the UI; they are hidden or inactive. Do not add provider keys for LLM or search — use Treasury instead.

Common workflows

Create your first Dubsar

1. Open Servitors' Quarters.
2. Choose Create Servitor.
3. Choose the Dubsar type.
4. Pick a main model and, if you want, a cheaper maintenance model.
5. Open the Dubsar and give it one clear role.

Adjust models without overthinking it

1. Open the servitor or Dubsar detail page.
2. Use the OpenRouter-backed model picker to search or paste a model ID.
3. Try a different model if the current one is too expensive, too weak, or just not a good fit.

Use the Library with a servitor

1. Upload or organize the files in House Library.
2. Choose a servitor type that can actually use the Library, usually Apkallu or Igigi.
3. Tell the servitor what material to use and what outcome you want.

Give a Dubsar access to an external system

1. Add the needed credentials in The Vault.
2. Make those credentials visible to the Dubsar that needs them.
3. Tell the Dubsar what external system it should use and what outcome you want.
4. If needed, add supporting notes or procedures to the Library and tell the Dubsar exactly where to find them.

Enable web search

1. Confirm an active subscription in Treasury.
2. Use a search-capable servitor such as an Apkallu or an appropriately configured Dubsar.

Subscribe for AI usage

1. Open Treasury from the sidebar or House Hall.
2. Choose a plan and complete checkout (sandbox in dev; production billing when launched).
3. Return to Servitors' Quarters or your Dubsar timeline to resume provider work.

Troubleshooting

My Dubsar or servitor says I need Treasury

LLM and web search require an active subscription. Open Treasury, subscribe or update billing, then try again. Library, Vault (non-provider secrets), and House Hall remain available without a plan.

I cannot create a servitor

Creating servitors uses the platform LLM for naming and requires an active subscription (unless your House is a Lugal-marked test House). Subscribe in Treasury, then retry in Servitors' Quarters.

My servitor cannot search the web

First check the servitor type — Kalu is conversation-only. Then confirm your Treasury subscription is active. Web search no longer uses Brave keys in The Vault.

I picked the wrong servitor type

This is normal. If you are unsure, switch toward a Dubsar rather than away from one.

My Dubsar looks inactive

Open the timeline and recent wakes. A Dubsar may simply be asleep, waiting for a new event or timer. If there is no timeline activity yet, send it a message to wake it.

I am not seeing the result I expected from a file

Check whether the file is actually in the Library, whether the servitor type can work with that context, and whether you clearly described what you wanted done with the material.

I am unsure where a key should live

Put secrets in The Vault. Put documents in the Library. If a value is credential-like, the Vault is the safer and more correct choice.

I want to see the actual API request or response for a model call

Check Impressions first. If the row has no View request/response button, either payload logging was off for that Dubsar when the call happened, or the impression predates your change. Enable logging under Optional payload logging (Dubsars), reproduce or wait for a new call, then open the new row. For subscription status and house-level usage totals, use Treasury and Usage charts.

Mesopotamian theming

House of Ur uses Mesopotamian-flavored naming throughout the product. The names are there to give the system a distinct identity, but they are not meant to make the product harder to understand.

What Ur is

Ur was an ancient Mesopotamian city. In House of Ur, the name is part of the product's overall aesthetic and theme. The exact origin of the city's name is debated, but historically Ur was one of the great urban centers of ancient Sumer.

What a House is

A House is your private workspace: your Dubsars, your other servitors, your Library, your Vault, and your settings all live there.

Names you will see

Glossary