Model console (router)

Audience: people who operate the model service (router ops console, not one Cadau deployment’s admin console).

In user language: each Cadau deployment must be opened here before it may call large models. Monthly plans include quota; agents on “Auto” are billed at a flat rate; a named model is billed at that model’s list price. Evals also happen here.

What you do in the console

1. Open the model console (local default http://localhost:3002; start the router first).
2. Sign in with an ops account (console in config; sample admin / change-me).
3. Sites: create one per Cadau, copy the token into that deploy’s OPENAI_API_KEY. Pick a plan and expiry; you can add quota or extend.
4. List prices: set the Auto flat rate, plus input/output price for each listed model (per million tokens, CNY). The price index in the model list is a multiple of the cheapest priced model in this table — glance who is expensive.
5. Usage: how much was billed per site.
6. Call log: each chat or code-send — which Cadau sent it, the original forwarded to the model or SMS/email channel, and what returned to Cadau. The code itself is not stored. The list is paged; open a row for full text.
7. Models: register models to list (fill by hand, or paste vendor notes, have an existing model read them, then check); run smoke (can it work today) and capability suites (who is stronger, for Auto).

Register a new model

1. Open Models, tap Register model.
2. Register by hand: in the dialog fill code, display name, vendor URL, key, upstream model name, tick image / audio / video recognize and generate, tap Register.
3. Or paste vendor docs / console notes into “Parse from a paragraph”, pick a working model, tap “Parse into form”, check, then register. With no models yet, register the first by hand.
4. After register tap Smoke to confirm it works today. When Auto needs a strength comparison, run the capability suite.

If not opened, disabled, expired, or quota exhausted, that Cadau’s chat says the model service is not opened or has expired.

Plans and billing

• Default tiers: Basic / Pro / Flagship, each with monthly quota. Phase one: ops open, add quota, and extend by hand.
• Auto: flat rate, regardless of which model was actually used.
• A named model: that model’s own list price.
• Eval consumption is booked to platform ops, not spread to sites.

Two eval layers

• Score: each item 0–5, max 5. 5 full · 4 good · 3 usable · 1–2 weak · 0 failed. 3 and above counts as pass.
• Smoke composite: can it work today. Average of connect, format, tools, simple arithmetic (image-recognize counted if declared). Suggest 3+ before business use.
• Suite composite: who is stronger at getting things done, for Auto. Average of format, tools, reasoning, long text (image-recognize counted only if it passed). Higher is preferred. The suite also tests streaming and six media items. An item is marked capable only at 3+. No second model as judge.
• Six media items (must verify, not just filenames):

- Recognize image: send a red-block image; must answer red. - Generate image: image API or chat must contain verifiable image data (real PNG/JPEG etc.); mentioning .png is not enough. - Hear audio: send a short clip with no speech; must answer “none”. Only “this is audio” does not count. - Generate audio: audio API or chat must contain verifiable audio data; mentioning .mp3 is not enough. - Watch video: must actually understand the picture. If the probe clip has no usable picture, only record “received” — do not mark watch-video capable. - Generate video: video API or chat must contain verifiable video data; mentioning .mp4 is not enough.

• Media capabilities ticked at register are initial values. After a capability suite, suite results overwrite the flags. Old evals that “passed chat image/audio/video out” are downgraded to fail; re-run the suite under Models.
• In progress it shows which question it is on. Each Q&A is written under the router directory eval-transcripts/ (subdir by time); background logs also print per question.

Capabilities, parameters, and vendor usage

Capabilities (image recognize, tools, etc.), generation-parameter ranges, and how each vendor sends files are all determined on the router, not rewritten per Cadau.

When Cadau gets things done it uses one vocabulary: an image in chat is recognize-image; a video is watch-video; the user saying “generate an image of…” is generate-image, and Cadau asks the router to produce it with the currently selected model. The router rewrites to the vendor’s format per that model’s usage docs. MiniMax-M3, for example, adds resolution and a thinking switch, and uploads oversized video then cites it.

At register you can specify the adapter (auto / OpenAI-compatible / MiniMax / Volcengine Ark); empty infers from the vendor URL. The right-hand detail shows temperature range and that model’s usage notes.

SMS and email verification codes

Codes for login, register, and password reset are also sent by the router. Channel secrets live in router config — do not put them in a Cadau server config. Cadau only uses the site token from open to ask the router to send.

Each send logs usage: which deploy, SMS or email, masked number or mailbox, success or fail. The code itself is not stored. View by site under model-console Usage. Full original (still without the code) is in Call log.

If the channel is not configured, that Cadau says SMS or email service is not configured.

vs the Cadau admin console

The Cadau admin console manages users, knowledge, and memory in that deployment. Open, billing, eval, and “how this model is called” are not there. SMS and email channels are not there either.