Chat Lab
Try models, presets, and routes before connecting an app
Stop wiring up an app to test a model. Chat Lab lets you try a configured model, preset, or route pack from the Console while Nexus keeps using the same gateway, tokens, and policy.
It lives under Serving in the machine sidebar. It is a lab for verification, not a separate chat product.
Clients address the same targets outside Chat Lab as:
One place to verify serving
Chat Lab combines:
- A stable target picker for models, presets, and route packs
- A scoped client token picker for the request identity
- Generation controls for quick comparisons
- Live thinking, tool activity, and performance counters
When you send, Nexus resolves the target, validates the endpoint family, and forwards with the Runtime-held credential — exactly like an external POST /v1/chat/completions call.
Prepare chat
- Open Chat Lab under Serving.
- Confirm Runtime is reachable. If access is denied, refresh the machine and try again.
- Choose a client token. Create one in Client Tokens if none exists.
- Choose a chat-capable target. Hidden models are excluded from the picker.
- Send a short hello prompt to confirm the path works.
If no target is selectable, add or sync a model in Models first, then return.
Try a model, preset, or route
Start small: one direct model, then one preset, then one route.
- Pick a direct model such as a visible local or provider model.
- Send:
Say hello in one line. - Switch to
@preset/<slug>to verify preset defaults and overrides. - Switch to
@route/<slug>to verify fallback and lane selection. - Use Try in chat from Models, Presets, and Smart Routes to jump in with that target pre-selected.
A strong first pass is intentionally narrow: one reliable target and one representative prompt. Add variations only after the basic path succeeds.
What the target controls
The target picker chooses what Nexus serves. The message chooses what you ask it to do.
| Target | Good for | Example |
|---|---|---|
| Direct model | Verify a single model is reachable | Check a newly pulled local model |
| Preset | Verify reusable defaults without editing the app | Compare temperature or max-token behavior |
| Route pack | Verify fallback and routing policy | Confirm traffic lands on the intended lane |
Direct model IDs take precedence over aliases. Route packs fall back when no lane matches or the selected target is unavailable.
Test before connecting an app
Test at least:
- An obvious hello prompt for the target.
- A longer prompt representative of real work.
- A preset override, such as a different temperature for one turn.
- A route-pack prompt that should use the fallback.
If replies look wrong, fix the target configuration first in Presets or Smart Routes before changing the prompt. Chat Lab shows serving behavior; it does not save target policy.
Understand every reply
Chat Lab separates live replies from longer-term evidence:
- Reply shows streaming text, thinking summaries where reported, and tool activity.
- Performance shows token counters, generation speed, and timing where available.
- History keeps the current in-memory session for comparison and retry. It clears on New chat, token switch, target switch, machine switch, or reload — there is no saved past-sessions list.
Use Stop to interrupt a slow turn. Use Retry to regenerate the last reply. Use New chat to clear session affinity and start clean.
Request history and Usage record aggregates and counters without storing prompt or response text.
Keep sessions coherent
Nexus tries to keep related turns on a useful target to preserve cache warmth and avoid reprocessing a stable prefix elsewhere.
When the work changes substantially, pick a better target explicitly instead of forcing a long session to cover unrelated tasks.
Generation controls
- Temperature for variation between turns.
- Maximum output tokens, including thinking.
- Thinking display where the model reports it.
- Current time tool for time-aware replies.
Chat Lab overrides apply to the session only. Saved preset defaults stay unchanged. Validate substantial preset changes in Presets before depending on them in clients.
See Presets for reusable defaults, Smart Routes for routing policy, and Gateway for the POST /v1/chat/completions contract and error.code handling.
Limits and access
Chat Lab needs gateway access for the machine and a valid client token. Token revocation, model visibility, inference capacity, and tool policy still apply.
If a machine update is required, update Runtime before retrying. Existing sessions keep their prior results; new turns use current access and policy.