Consensus Engine

User manual

Bring Your Own Key · Account page · Smart setup

Account guide — your keys, your models

The Account page is where you decide who pays for what and which models run.
You can:

  • store API keys so the engine can call providers on your behalf;
  • tell each engine role ("participant seat", "orchestrator", "categorizer", …)
    which model to use;
  • or let the engine propose a complete role plan from two simple settings
    (Budget and Reasoning).

Getting started — first time here

Follow these steps to create an account, add an API key, and run your first
consensus.

1. Create an account

  1. Press Sign in in the top-right navigation bar.
  2. On the sign-in page, press Create one (the link below the form).
  3. Enter your email address and a password (at least 8 characters).
  4. Press Create account.
  5. You are now signed in and will stay signed in on this browser. The
    navigation bar now shows an Account link.

2. Get an API key

The engine calls models in the cloud, so every run needs a secret key. You can
bring your own key from any supported provider:

  • OpenRouter — go to openrouter.ai/keys and
    create a key. This unlocks hundreds of models through a single key. The key
    starts with sk-or-v1-….
  • Gemini — go to
    aistudio.google.com and create a key.
    The key starts with AIza….
  • DeepSeek — go to platform.deepseek.com
    and create a key. The key starts with sk-….

An OpenRouter key is the easiest starting point because it works with every
model in the catalogue. You only need one key to get started.

3. Add the key on the Account page

  1. Press Account in the navigation bar.
  2. In the API keys section, choose the provider that matches your key
    (e.g. "openrouter").
  3. Paste the key into the form and add an optional label (e.g. "my OR key").
  4. Press Save. The engine validates the key against the provider
    immediately — if the prefix is wrong or the key is expired, it tells you.
  5. When the key is saved, the table below shows it masked (e.g. sk-or…abcd).

4. Run a consensus

  1. Press Consensus in the navigation bar.
  2. Type a question or topic into the text area (at least 5 characters).
  3. Choose how many critique rounds you want (3 is a good start).
  4. Press Start consensus.
  5. The engine calls the models, streams progress, and opens the results page
    when done.

That is it. The engine used your key to call models on your behalf. The results
page shows every draft, every critique, the synthesised answer, and the
provenance trail.

Next steps

  • If the built-in models (Gemini, DeepSeek, GPT-OSS) show as unfunded, store
    their keys too or turn them off in the OpenRouter section on the Account
    page.
  • Use the Smart setup section on the Account page to let the engine propose
    a complete role plan based on your budget and reasoning preference.
  • Return to the Account page any time to add more keys, change bindings, or
    review who pays for each role.

1. API keys — bring your own key (BYOK)

A run calls models in the cloud. Every call needs a secret key. The Account page
stores your keys encrypted (AES‑256‑GCM), validates them against the provider at
save time, and never sends them to the browser.

Supported providers

Provider Key prefix Registry models
OpenRouter sk-or-v1-… The full live catalogue — hundreds of models
Gemini AIza… gemini-3.1-flash-lite
DeepSeek sk-… deepseek-flash, deepseek-pro
Groq (GPT‑OSS) gsk_… openai/gpt-oss-120b

You can store more than one key for the same provider (the newest‑saved one is
used), and you can have keys for any combination of providers. A key is checked
when you save it: the wrong prefix or an expired key is refused immediately.

If you hold only an OpenRouter key, the built‑in Gemini / DeepSeek / Groq
seats are not funded and cannot run. Turn the built‑in models off in the
OpenRouter section to avoid confusion.

2. Who pays for each role

Every running role needs to be funded by a key. The engine resolves each role
in this order:

  1. A manual binding — you assigned a model to the role explicitly (see §3).
  2. An auto binding — the Smart‑setup plan assigned it (see §4).
  3. The role's own provider — if you hold its key, the role uses its
    registry default model.
  4. The cheapest configured provider — for roles that are not identity‑bound
    (orchestrator, categorizer, helpers), the engine uses your cheapest provider
    as a fallback.
  5. Unavailable — if none of the above applies, the role reports why it
    cannot run.

The Account → Who pays for each role section shows the live resolution for
every role, so you can see what each run will use.

Anonymous runs

If you are not signed in, the run uses the operator's key set (the .env
file on the server). This is how the engine works for local development and
for anonymous visitors. You cannot use your own keys without signing in.

3. Role bindings — saying "use this model here"

A binding tells the engine "for role X, use model Y". The Role
bindings
table lists every engine role and lets you pick a registry model
(the built‑in set) for each one. The OpenRouter section lets you assign
any model from the live catalogue to any role.

When a binding is stored, the engine always uses it — even if the Smart‑setup
plan would pick something else. A binding beats an auto plan. The source
column shows where the model came from (binding, auto, role‑provider, …).

To remove a binding, press Clear next to the role. The engine falls back
to the normal funding rule.

The three legacy seats

Three participant keys are permanent: gemini, deepseek, gptoss. They keep
their names in every round and every report, because stored run history and
exported data depend on them. You cannot rename them, but you can:

  • turn the built‑in trio off (the OpenRouter section toggle) — the three
    legacy seats disappear from every run;
  • point the seat at a different model — use the Role bindings table to
    pick a different registry model, or the OpenRouter section to assign an
    OpenRouter model (which then runs as an OpenRouter call, not the built‑in).

Participant seats or1…or5

In addition to the three legacy keys, five dynamic participant seats
(or1…or5) can each hold an OpenRouter model. They exist only when assigned
(the OpenRouter section or the Smart‑setup plan creates them). A run needs
at least 2 live participant seats and a working orchestrator; with only 1
seat it is refused before any token is spent.

4. The Smart‑setup plan (auto‑select)

The Smart setup card at the top of the account page proposes a complete role
plan from two simple settings.

Budget

Budget What it means Seat count
Low cheapest third of eligible models 2
Medium up to the middle third 3
High no cap; 4–5 seats 4 (up to 5)
Custom a maximum estimated cost per run 2–5

The planner only ever proposes models you can pay for — providers whose key
you have stored (or the operator's key set on anonymous runs).

Reasoning

Setting Orchestrator requirement
Standard none
Advanced must support reasoning
Maximum must support reasoning, and at least half the seats too

Build, apply, re‑roll

  1. Pick Budget and Reasoning.
  2. Press Build plan. The preview table shows every proposed role — seat,
    orchestrator, categorizer, helpers — with the model, vendor, one‑line
    reason, estimated price, and who funds it.
  3. Check the estimate. The footer shows an estimated cost range per run.
    It is a rough guide (the real cost depends on answer length).
  4. Press Apply to write the plan's choices as auto bindings. Auto is now
    on: your runs will use exactly these seats and roles. A legacy seat the
    plan did not choose will not run while auto is on.
  5. Re‑roll to see an alternative. The next‑best set of models is chosen
    (deterministic — not random). When the AI advisor is on, you get a fresh
    sample.
  6. Clear auto assignments removes the plan's auto rows and switches auto
    off again. Manual bindings are never touched.

Editing a role from the preview

Each preview row has a Pick button and a Set button:

  • Pick opens a search panel. Type a vendor name (e.g. claude, gemma)
    and press Search, then click the model you want. The model id is copied into
    the input and the panel closes.
  • Set saves the current model id as a manual binding for that role.
    The row then shows a manual badge and the reason "your manual choice — it
    wins over the plan"
    . Apply will never overwrite it.

The form below the table lets you add a participant to any free seat.

5. The OpenRouter section

Below the bindings table, the OpenRouter section has a model search,
an assign form (pick a role and paste an id), and a table of every stored
OpenRouter binding with a Remove button.

Saving here writes a binding just like the preview's Set button — source is
manual, and an auto plan will never overwrite it.

The built‑in models toggle turns the three legacy seats on or off for your
account. When off, only your OpenRouter bindings and any Smart‑setup plan's
seats will run.

6. Troubleshooting

"Project contains no examples" / no run

A run needs at least 2 live participant seats and a working orchestrator.
If the engine refuses before spending any token, check the Account page's
Who pays for each role section for the missing role. Common causes:

  • You hold only one API key (e.g. only OpenRouter) and the built‑in trio is
    turned on. The engine cannot fund the trio with only an OpenRouter key.
    Either add the missing keys or turn the built‑in models off.
  • No OpenRouter key stored but the Smart‑setup plan chose an OpenRouter seat.
    Store an OpenRouter key or clear the auto plan.
  • The plan chose a model that is no longer in the catalogue. Re‑build the plan.

"The built‑in models are still speaking"

Two reasons:

  1. Auto is off. The plan was never applied. Build a plan and press Apply.
  2. Auto is on but the plan includes the built‑in trio. With auto on, a
    legacy seat the plan did not choose is excluded. If the trio still appears,
    turn the built‑in models off in the OpenRouter section.

A model returns empty or fails silently

The helper roles need a plain text‑only chat model. A model whose output
is ["text","audio"] (e.g. a music generator) will be rejected by the planner
with "not a text‑output model". The planner avoids reasoning models for
helpers; if you assigned one manually, consider switching to a plain model.

"My subscription to that model was blocked"

OpenRouter returned a 402 (out of credits) or 404 ("no endpoints found").
Check your OpenRouter account balance and the model's availability.

The estimate seems wrong

The cost estimate is a rough range using default token‑count estimates, not
the actual answer length. Use it as a relative comparison between plans.

7. Key points

  • Nothing changes until you press Apply. Saving settings only remembers
    the dials.
  • A manual binding always beats an auto plan. Apply never overwrites it.
  • The preview is a snapshot. The manual badge shows what actually runs
    after an edit.
  • The header and footer show your real models — never a hard‑coded default.