Skip to content

System & Settings

Operator Console

The Operator Console is the support desk for the hosted service. It lists the accounts on the service, shows what has been generated and why a run failed, and lets an operator switch an account off — with a reason that is recorded permanently. Most people will never see it. It appears only for accounts the server marks as operators, and it is not in the Toolbox.

At a glance

Accounts

The first tab lists accounts on the service, newest first. Search by email or display name, and narrow to active or disabled accounts with the filter.

Disabling and re-enabling an account

Disabling stops an account from making any request. It is the moderation tool for abuse, and it is always reversible — a switch you cannot switch back is an outage, not moderation.

Generation runs

The second tab lists AI generation runs across every tenant, so a support question like "my Kard stopped half way this morning" has somewhere to be answered. Filter by status; Failed only is the default, because that is what usually brings someone here.

One row is one Kard. A Kard is built from several AI calls — an outline, one per stage, and a repair attempt for any stage that came back malformed — and the listing rolls all of them up, so a Kard is a single line with a single price however many calls it took.

Repairs says how many of those calls were retries, and Repair cost says what the retries came to. A stage that comes back malformed is asked again, and that second ask is charged like any other call — so a Kard listed as 26 calls of which 8 were repairs is a very different piece of work from a clean 18, and the difference is money. Runs generated before this was recorded show 0 for both: the figure was never captured for them, and it is left empty rather than guessed.

Selecting a run opens it call by call. Each names its phase — the outline, a content stage, a repair of one, or the web search that precedes a References stage — alongside its own status, tokens, price and reason. That is how a run that succeeded twice and then failed tells you exactly where it stopped, and what the recovery cost.

"Cross-tenant run listing is not available here"

This is a configuration message, not a failure, and it is worth understanding because it looks alarming and is not.

Listing runs across every tenant is the one thing the console does that the ordinary database connection deliberately cannot do — the isolation that keeps every customer's data separate is exactly what stops it. It needs a second, read-only database credential, and a deployment that has not been given one answers this instead. Accounts, disable and re-enable, and the audit trail all keep working. If you see it and expect otherwise, the deployment has not been updated; nothing is broken and no data is at risk.

Good to know

Troubleshooting