AnchorShell characterization
Choose a request characterization engine and understand intent, confidence, background completion, and Smart Group decisions.
Request characterization describes what a request is asking a model to do. Relay records the result alongside routing and timing information so you can inspect workloads and, with hosted Smart Groups, use request intent when selecting models. It is separate from generating the answer.
Choose an engine
Open Settings → Request Characterization, choose an available engine, and save. The change applies to subsequent requests.
| Engine | Availability | Setup |
|---|---|---|
| AnchorShell Classifier Basic | Community default | Built in; no separate worker required. |
| AnchorShell Classifier Pro + Enhanced | Hosted; proprietary | Provided by hosted Relay. Selecting its upgrade option in Community does not activate it locally. |
| Laya | Community and configured hosted deployments | Community requires the local Laya worker. |
| Jev (typesafe.ai) | Coming soon | Not an active engine yet. |
The built-in AnchorShell classifiers do not require you to connect another generation provider just to characterize requests. System One models provide an alternative classification path; their outputs and confidence scores should not be assumed equivalent to the built-in engine.
Read the result
Open Logs and inspect a request's characterization. Depending on the engine and available evidence, the result can include a primary action, confidence, coding requirements, and additional context. Not every engine supplies every field. Automatic Laya classification focuses on primary action and coding specialization; absent richer fields do not mean the request failed.
Characterization metadata records the requested engine, the engine that actually handled the request, and classification duration. A fallback can therefore produce a valid AnchorShell result even when Laya is selected. An unknown result means there was not a usable classification; it is not itself a provider error.
Background work and Smart Groups
For ordinary requests, characterization need not block provider dispatch or the response. A request may finish while classification is still pending, then receive its characterization afterward. When this work overlaps provider execution, its duration is not extra time to add to the total.
Hosted Smart Groups use characterization to select a configured intent or coding model list. Low-confidence decisions use the default list. Access rules, capacity limits, guardrails, and availability still apply. Choosing a classifier alone does not turn an ordinary Group into a Smart Group.
Payload storage is separate
Characterization needs to process request-derived text, but enabling it does not automatically turn on request-body retention. Store request payloads in Settings controls optional request and response body storage. Bodies can contain sensitive information; enable retention deliberately. Classification labels may remain available even when bodies are not stored.
If a selected Laya worker becomes unavailable, Relay falls back for that request and keeps the saved selection. See Laya troubleshooting before changing engines.