AryaInfer Control Center
An optional AryaCode plugin for the AryaInfer engine. The sidebar entry is AryaInfer. The Overview view starts, stops and restarts the engine and embeds its web UI for hardware health, inference monitoring and model management; the Benchmarks view runs the built-in benchmark lab. Open web UI opens the engine interface in a separate tab. The panel's top bar switches between Overview, Connection, Settings and Benchmarks. On Overview, Hide details collapses the engine summary and the divider above the engine page can be dragged (or nudged with the arrow keys) to give that page more room; the layout is remembered.
Harness compatibility
Verified on AryaCode 0.2.2-alpha.2 (build 0.2.2-alpha.2.AryaCode.0.1.0) on
2026-10-28: [email protected] installed from npm into a clean packaged
profile, the plugin loaded live with no import error, and its row renders in
Plugins → Installed with the switch on. An earlier attempt that installed the
same version from a temporary tarball failed to load (duplicate client factory);
the published package does not.
The package declares no dsh.engines.dsh range, so the market cannot state a
requirement for it: the card reads "Host requirement undeclared" when the
manifest is readable and "Host requirement unknown" when that lookup fails.
Setup
Keep the dsh-local-llm package identity for existing installations and updates. The engine controller is included in this package; no separate controller or agent preset is required. Its routes use /api/aryastrata, so an older standalone controller can coexist during an update without duplicate route registrations. Configure the strata fields on the llamacpp plugin row for the controller’s pythonPath, serverDirectory, configPath, baseUrl and port for the installed AryaInfer engine. The same six fields can be edited in the panel: Settings → Where this engine lives shows the values in force, says which of the four paths exist, and Save changes writes them back to this row (so a moved checkout needs no hand-edited profile). This machine uses C:/Users/KNPhu/AryaCode/KonnectSuite/AryaInfer and port 8080. The selected startup configuration is strata-qwen36s-ud-q4_k_xl.json; changes saved to it by AryaInfer are used on restart.
Stop and Restart require a process owned or adopted by the controller. Adoption matches the server entry point and configured configuration path; a process is never stopped merely because it occupies the engine port. strata.exe, strata-poly.exe and the AryaInfer engine aryainfer.exe are recognized. When the llama.cpp controller is configured on the same port as Strata, a Strata start skips that controller: the listener is the Strata server, not a second engine. Changing model architecture is handled by AryaInfer, without a Qwen-only model list in this page.
The page offers the Strata engine and the benchmark lab. Ollama, llama.cpp and FreeToken have no page controls; their existing backend APIs remain available to preserve saved model-provider integrations. Changing this page does not install, delete or move engines, model files or chats.
Arya Local preset
The package registers a fourth agent preset, Arya Local, chosen when a session is created and fixed for its life, like the shipped presets. It is built for a local model with a small context window: Arya Claude-style working rules adapted for a local model (about 6.7K characters, roughly 1.7K tokens), workspace instructions capped at 16 KB, and the full shipped DSH tool row set (shell, read/write/edit, search, background jobs, scheduling, skills, goals, plan mode, compaction, delegation, todo, ask, web, present, and the conditional Host plugin-manager/market rows). Only a compact core keeps its schema eager: the coding tools, read_image, and the three browser tools needed to open a page and see it. Every other tool, including inherited MCP and plugin tools, is deferred through the disclosure bridge below. The rules include a direct visual-artifact loop: plan the hierarchy, write the complete page, open it with the resident browser pack, snapshot it, read the image, fix what is wrong, then present it. It leaves out time context so the request prefix stays cacheable. Compaction starts at 80% of the routed window with 4K headroom and 16% retention, and tool results over 4 KB are pruned to 2K head + 512 tail; this preset keeps its own compaction policy rather than the stock one.
The working rules are adapted from Arya Claude, not Arya Standard: Standard is the Codex/GPT-5 prompt (apply_patch, Codex identity), which fights this preset's tool names and its disclosure bridge. The artifact section is the fix for the earlier terse persona, which produced minimal first-draft pages without ever rendering them.
Progressive tool disclosure is built in. A preset row mounts this package's own tool executor (preset-disclosure), which keeps a resident core eager and hides every other visible tool's schema from the request. The core is read, read_image, write, edit, bash/pwsh, glob, grep, exit_plan_mode, the three Windows browser tools mcp__wincu__windows_computer_use_list_windows, ..._set_value, and ..._snapshot, plus three bridge tools: tool_search (hybrid BM25 search over capability groups and call cards), tool_describe (one tool's call card and schema), and tool_call (run a deferred tool by name through the shared pipeline, so approvals, guards, and session events still reference the real tool). Instead of a flat manifest, the prompt carries a compact capability-group index — one line per MCP server or curated group, bounded at 500 tokens. On the first step of a user turn a deterministic tool scout injects one short context message with the most likely tools for that task; it is append-only, deduplicated by task/shortlist digest, and never changes the provider tool list. Search results are call cards with required arguments and a risk tag, and one tool result is capped at 6,000 characters so a large MCP answer cannot flood the local context. Inherited host tools are deferred by default (inheritedTools: defer), so an MCP server is discoverable whether it connected before or after the preset mounted; excludeInheritedTools hides names or prefix* families, and inheritedTools: hide restores the old blanket mask. No plugin installation is required; this is code in this package and uses the host's executor seam.
This implementation exists because the host's system-prompt/assemble waterfall cannot rewrite native tool schemas on this DSH build (tools are collected before it), which is also why the third-party dsh-tool-search native path is a no-op here. The executor seam is the supported one.
Configure it on the llamacpp row under localPreset:
localPreset:
inheritedTools: defer
allowInheritedTools: ['mcp__memory__*', 'generate_image']
excludeInheritedTools: []
budgetChars: 40000
skills: true
web: true
goal: true
toolSearch:
enabled: true
thresholdPct: 5
listingMaxTokens: 4000
contextWindow: 100000
minDeferredTools: 4
searchLimit: 10
shelfMaxTokens: 500
scoutMaxTokens: 260
resultTokens: 700
detail: cards
scout: true
riskAware: true
usageBoost: true
compaction: { thresholdRatio: 0.8, headroomTokens: 4096, retainRatio: 0.16, maxTokens: 4096 }
pruner: { thresholdChars: 4096, headChars: 2048, tailChars: 512 }
inheritedTools: defer (the default) leaves host-registered tools visible and defers their schemas; allowInheritedTools names the few that should stay eager, and excludeInheritedTools denies names or prefix* families. inheritedTools: hide is the legacy behavior: every inherited tool is masked unless named in allowInheritedTools. skills, web and goal default to true because the preset mounts the full shipped tool set; set any of them to false to trim the optional rows for a very small window. budgetChars is the point where the policy logs an over-budget warning for the combined tool schemas. shelfMaxTokens, scoutMaxTokens and resultTokens bound the three model-facing tool surfaces; thresholdPct/listingMaxTokens remain only as the fallback manifest budget. toolSearch.contextWindow is deliberately the 100K floor so a static configuration cannot grow with a 262K window. minDeferredTools stops the bridge from appearing in a composition with only a handful of deferrable tools. searchLimit defaults to 10 so a broad task such as "browser" or "render" can return the whole relevant family instead of being silently cut at five; the model can still ask for fewer. The preset does not choose the model: select the local model in the composer as usual.
Measured on this machine on 2026-11-03 with the packaged app and 0.19.0, before the preset mounted the full shipped row set: the same profile's standard preset sent 81 tools and 70,062 schema characters. Before 0.20.4, an Arya Local session's first request carried only 9 eager schemas (read, write, edit, pwsh, glob, grep, plus the three bridges), 8,236 JSON characters, plus a 7,072-character deferred manifest, about 3.8K tokens of tool definitions in total — below the 5K-token budget at a 100K window. The 0.19.3 persona adds about 1.5K tokens on top, so the complete first-request prompt overhead was roughly 5.3K tokens at 100K. The 0.20.4 core adds read_image and three browser tools, so a new measurement should show 13 eager schemas; the flat manifest has been replaced by the bounded capability index (500 tokens), the optional scout (260) and search/describe results (700 each), so the old manifest figure no longer describes current builds and the total tool-definition budget should be re-measured on the next release. Retrieval is covered by a deterministic 230-tool fixture with 77 labeled queries: exact-name Recall@1 1.00, Recall@5 0.985 and MRR 0.896, with no-match queries returning nothing. A follow-up turn in the older measurement called tool_search for jobs and then tool_call for job_list, which returned {"ok":true,"value":[]} through the real tool pipeline. Tool results are trimmed by the pruner before the next request, and a single bridge result is capped at 6,000 characters. Inherited host tools are deferred in both connection orders; excludeInheritedTools is evaluated when the preset mounts, so a name that registers later is still discoverable (searchable) rather than masked.
Compaction's exact trigger depends on the routed output reservation: floor(min(W × 0.8, W − O − 4096)). A 100K model that reserves 32K for output compacts at about 64K rather than 80K; lower that model's output limit to 16K for an exact 80K trigger. Retention is 16% of W − O. In the stock path there is no model-callable compaction tool; the persona's 60% rule stops context growth and the host's automatic compaction is the guarantee. When bili is active, the persona instead carries a billion-context section: call acp_status near 60%, compress at 15-20K+ compressible tokens or after a large write, and use search_context/decompress for folded detail.
billion-context owns compaction when it is active, and Arya Local stands down. bili's internal/config overlay disables the stock compaction rows by package name, but a preset definition registered through agentPresets.register() never resolves as loader config, so that overlay cannot reach this preset. The plugin therefore decides while building the definition: when bili's biliBasicCompactionPolicy gate service is present AND its __BILI_DSH_COMPACTION_VERDICT__ global reads active, compaction-basic and command-compact mount disabled and tool-result-pruner plus every other row stay mounted. Only a confirmed takeover counts; an expected bili (a profile bundle or overlay naming billion-context, or BILLION_CONTEXT_PROXY/BILLION_CONTEXT_ATTACH) is polled for the gate for at most 2s and 0.5s more for the verdict, and any timeout or inactive verdict keeps the stock engine with one warning. BILLION_CONTEXT_PLUGIN=0 and BILI_NATIVE_DSH=0 disable bili, and any BILI_PROVIDER_REWRITES value removes its native ownership; all three return immediately with the engine enabled. Registration is deferred to a guarded promise so the plugin's apply() stays synchronous and a disposed fiber registers nothing. The same takeover adds bili's four context tools to the eager wire and appends the billion-context compaction section to the persona, so the model does not wait for a stock 80% trigger that is no longer mounted.
Benchmark lab
The Benchmarks view runs the built-in benchmark lab (suite 3.0) against the models AryaInfer publishes. Add one to AryaInfer and it appears here. Chat model discovery, Benchmarks and model sharing with a paired computer are unchanged.
Five tabs: Board ranks models by a weighted Overall score with medals, per-suite bars and a suite-profile radar. Live shows a completion ring, per-model progress, ETA and GPU sparklines while a run executes; Cancel stops it. Results is a model × suite matrix; click any cell for a drawer with the check list, metrics, the model's answer, generated code downloads and website screenshots. Compare stacks up to three saved runs against a baseline with per-suite deltas and radars. Sites renders every generated website card with desktop/mobile captures, interaction play and 1–5-star visual ratings.
Batteries: Speed (◷ ×30) throughput probes; Readiness (✳ ×15) tool-call and vision probes; Context (⌖ ×15) long-needle tests up to 256K; Reason (∴ ×15) twelve deterministic short-answer tasks (arithmetic, logic, JSON extraction, formatting contracts) checked offline at temperature 0; Build (▤ ×20) eight website tasks scored by DOM contracts, design metrics and screenshots; Industrial (⚙ ×20) twelve engineering tasks — JavaScript with real Worker assertions, OpenNode PLCopen XML, Rockwell L5X generation and reading, ladder diagnosis, tag cross-reference, HMI screen specs, safety verdicts and EtherNet/IP protocol Q&A. PLC, HMI and network answers are offline deterministic fixtures, not vendor-validated content; PLC outputs need engineering review.
Readiness measures the live tool catalog: every chat turn with a local model records the tool definitions the host sends with it, and the readiness suite runs against the newest capture, so it always measures the real catalog of the running tool set. An arya-request-header.json snapshot in the engine directory is still accepted as a fallback. Start one local chat before running the readiness suite; the benchmark panel reports which catalog will be used.
Overall is the weighted mean of present suites, renormalized when a run skips batteries; Speed is scored against the fastest model in the run, so the ranking stays comparable across hardware. Pick a preset (Quick check, Standard, Full gauntlet) or tune suites, context, speed, thinking, repeats, vision and task lists by hand. Older 2.0 runs stay readable and comparable.
Scoring never asks a model to judge a model: every check is a fixed script run offline against the captured answer, so scores are reproducible across runs and machines.
Browser access
The web UI loads directly from the configured engine URL. A phone or another computer cannot access the host's 127.0.0.1; the page explains this instead of embedding the wrong computer. Configure a reachable, authenticated AryaInfer address before using it remotely. An HTTPS AryaCode page cannot embed an HTTP engine; use the separate-tab link or an HTTPS engine address. The engine's own authentication remains in effect, and credentials are never added to its URL.
A paired computer is more capable than a bare address: its own Host asks the paired address whether the engine's port answers there, and offers the interface only when it does. Publishing the engine port on the tailnet is enough — this machine uses tailscale serve for port 8080 — and the panel then embeds the engine UI instead of asking the user to walk to the other computer. When the port does not answer, the panel says so rather than showing a broken frame.
Another computer
Install this plugin on both computers; 0.7.4 or newer is needed on both for the fixed pairing address and every engine model (model sharing needs 0.7.2, control alone 0.7.1). Control is set up with a short pairing code, the same way a phone is connected:
- On the engine computer open AryaInfer → Connection → Let another computer control this engine and choose Create pairing code.
- On the other computer open AryaInfer → Connection → Pair a computer.... Choose the engine computer from the list of machines on its tailnet, or type its Tailscale address, then type the eight-character code — the one it displays beside the addresses a second computer can reach it at. Letters and digits only; the dash is ignored.
- Pair and control exchanges the code once for a private token and starts controlling that engine. The code expires five minutes after it is created.
The address the code offers is served by this plugin on a fixed port (45900) bound to the engine computer's tailnet address, and it forwards only the routes a paired computer uses: /api/aryastrata/* and /api/local-llm/*. Everything else on that address is a 404. The port matters because AryaCode chooses its own web port afresh at every launch — an address saved against that port stops working on the next restart, which looks like a network failure. With the fixed port the pairing survives restarts. Set strata.pairPort to use a different port, or 0 to turn the relay off (the offer then names the page's own port again). Set strata.pairHost when the tailnet address is not the one to bind. The first time it listens, Windows may ask whether to allow the app to accept connections — allow it for the tailnet, not for public networks.
The paired computer appears under Connection → Paired computers on the engine computer, where it can be unpaired; unpairing revokes its token immediately. Pairing does not need a secret pasted by hand, and no token is shown on screen. Use this computer points the page back at the engine it runs itself.
A panel that has a strata.controlToken on its llamacpp row still accepts that token, which is what an older installation uses:
- id: llamacpp
config:
strata:
controlToken: a long random value
Restart AryaCode after editing it — the row is read at startup, and a page reload does not reload host code. A computer with no token and no paired computer keeps answering only itself, which is the safe default; the page says so rather than letting a connection fail as a 401. Under Control another computer → Use a control token instead, the same address and token can be entered directly.
Start, stop, restart, the engine snapshot and logs are then answered by the engine computer, and the page names the computer it is controlling. The same code also shares the engine's models: every installed model is offered, and the paired computer lists them all in AryaCode's model picker (provider Remote Local LLM) with their real context windows. One code, one token, control and models together; revoking the paired computer ends both.
An engine serves one model at a time but can switch: choosing a model the engine has not loaded asks it to switch (POST /api/models/load) before the request is sent, so chat moves between models without visiting the Control Center. The engine finishes the request it is running first, and refuses with the reason when that takes longer than its switch window. Models the engine reports as unusable are left out rather than offered and then failing.
The models are also listed in the engine computer's own Local model library, so the host can chat with its engine without a separate provider row.
The engine's own web interface still listens on the engine computer, so it is opened there rather than embedded when its port is not reachable.
The hop is server to server: the page stays on its own machine's origin and the token never reaches the browser. Choosing a computer to pair with is local to that computer, and redeeming a code needs the code itself; nothing else changes which computer a page controls. Plain http is accepted only for loopback and Tailscale addresses, where the transport is already encrypted; any other address must be https. The status and control routes demand the token from every caller that is not on the engine computer, and an origin the engine computer never named is refused outright.
Validation
npm run typecheck
npm run build
npm test
node tests/aryastrata-ui.mjs
The browser test covers lifecycle controls, desktop/mobile layouts, an embedded web UI and errors retaining the current UI. To exercise a real local engine, set ARYA_STRATA_LIVE=1 before running that test. This explicitly stops, starts and restarts the configured engine; run it only when no inference request is active. The live test loads the built Control Center package itself.
Legacy backend reference describes retained compatibility APIs, not the current page.
Chat output limits
Open AryaInfer → Settings → Chat output, choose one of the models this plugin publishes (the engine's models, the GGUF profiles and Ollama's), adjust Output tokens per response, and save. The limit is kept beside the plugin's own settings and becomes that model's default for new requests. The number includes thinking, tool arguments and the final answer. Changes apply to subsequent requests. The editor supports values from 1,024 tokens to below the configured context window; input and output still share that context. Saving preserves other model settings. The desktop application can embed loopback engines through its dsh-app origin as well as a localhost browser.
Updating from the two-package release
Install or update only dsh-local-llm 0.7.1 or newer on both computers in a remote-control setup. The old dsh-strata package may be uninstalled; its source and previous archives are retained for older installations. If you customized its controller row, move those configuration values into the strata object on the Control Center’s llamacpp row before removing it. The retired dsh-strata-agent preset is unrelated to engine control and is not included. Model files, chat history and saved model-provider settings are preserved.