LexiChat — first-party conversations
Chat with a running model using the Panel's own conversation store and engine adapters. Open Chat to check model readiness, select a model, and use the composer. Camelid is not required.
Open LexiChatModel availability is checked on the Chat page; this link does not mean an engine is running.
Running models
Every
llama-server on this box, each
asked on its own port. Start / Restart / Stop below act only on the managed one
(main's system unit); everything else on this tab describes that one too.Live, every engine the same numbers for llama.cpp, vLLM and SGLang, on this box and registered remotes, read from each server's /metrics every 5 s while this view is open
starting…
Remote endpoints model servers on other machines (llama.cpp, vLLM, Ollama, LM Studio, any OpenAI-compatible API), listed above by address
Processes on this box are found on their own; a server
on another machine has to be registered by address (http(s)://host:port). Its API key is stored readable only
by the panel and never shown again. "Through the gateway" also serves it at /v1 on
this panel under its name and model names. Adding and removing need the admin role.
Instance
Instance profiles
A saved copy of a whole instance: the parameters for every backend, all three fallback tiers,
and the devices it ran on. New instance creates a separate instance from one.
Apply writes one into the instance selected above without restarting it; that
instance keeps its own port.
Server
Hermes Agent
Use this instance as the model of
Hermes Agent
(Nous Research), with LexiPanel's MCP tools (read-only unless you change it). Paste the block into
~/.hermes/config.yaml.
config.yaml for this instance
llama.cpp web UI
Generate
negative prompt
Run
Runs a job on one of this instance's
models. The first run of a model loads it (seconds for speech, longer for music). Models and
their fixed settings are on the Parameters tab.
model options for this run
Blank = the instance default (Parameters tab) or the model's own default. Hover ? for what each does.
Recent outputs
Throughput
Decode vs context depth
One decode figure is the shallow best case. Agent sessions drift across context sizes,
so this is what you actually feel: decode measured at fixed depths on this instance's
running model, with GPU temperatures recorded during each request.
Measure again
Uses the server's only slot for the whole run: agent requests queue behind it, and its
prompt cache is replaced by the test text. Depths are walked upward reusing the cached
prefix, so the run costs one cold prefill of the deepest point (about 18 minutes to
240k on the 7900 XTX), plus a few seconds per sample. The run pauses before a request
at the pause temperature, and cancels the request in flight if the junction stays at or
above the abort limit.
Safe restarts
Every planned restart (auto-fit apply and rollback, or the button below) runs one journaled
procedure: the gateway holds new requests instead of failing them, requests in flight
finish first, the server must come back on exactly the intended settings (a fallback
tier fails) and pass a canary (a fixed prompt at temperature 0 must answer as it did
on this configuration before). A failed check puts the last known-good settings back and
verifies them; if those fail too it stops and says so. Clients that talk to the engine port
directly (e.g. an agent on :8081) are waited for, not held: point them at the gateway
(/v1 on this panel) for restarts they never notice.
Live
VRAM drops to near zero when idle — amdgpu evicts to GTT and pages back on the next request. Judge placement by the peak while serving, or by t/s.
Backend
Model preset
Camelid models
Camelid loads one GGUF per server. It
supports a curated list (the catalog below); pulls go to its models folder. Pick a file with
Use, then Restart the instance.
Models on this instance
What this audio.cpp server offers.
Each entry is one installed package with the task it serves and its fixed settings
(load and session options apply when the model loads; default request
options apply to every run unless the run sets them). Save, then Restart the
instance on the Status tab to apply.
Model catalog
Every model family this audio.cpp
build knows, from its
model_specs. Packages download from Hugging Face into
~/audiocpp/models, shared by all audio.cpp instances. Q8_0
packages are smaller and usually as good; check sizes before installing music models.Memory calculator
Live estimate for the values in the form below, before you save. The per-token KV
cost is solved from a real measurement of the running server, not a datasheet, so
it tracks this box.
Host RAM budget
VRAM is not the only ceiling. When the card runs near full, amdgpu evicts model
weights into GTT — host RAM pinned by the driver, which shows up in
neither
ps RSS nor the cgroup. GTT ceiling + prompt cache + process
overhead has to fit in physical RAM. It did not between Sep 4 and Sep 8,
and nothing in this panel was modelling it.
Launch parameters
SPEC_DRAFT_MODEL must stay empty for embedded MTP. Pointing it at a
full-size target loads a second copy of the model and has hard-locked this box twice.
Only a small sidecar (≈862 MB FastMTP) is valid. The panel and the launch script both reject
anything over 4 GB.
All other options from this build
Read from the
--help of the build this instance launches, so a new daily build's new
options show up here without a panel update. Only options the form above does not already set are
listed. Ticking one writes it into the extra-arguments field above; press Save to keep it.Model profiles
Named parameter sets saved per model file. Load fills the form above without
saving, including the model and backend it was saved with; you still press Save.
Shows profiles for the model currently selected in the form.
Defaults & fallback tiers
Three saved parameter sets. The launch script picks one from the number of
consecutive failed starts, so systemd's three allowed retries become three
different attempts instead of the same failure three times.
Load puts a tier into the form without saving — you still press Save,
so a misclick cannot change what is running.
Optimize
The optimizer tunes llama.cpp servers
(context, KV cache, speculative decoding, sampling). It does not apply to stable-diffusion.cpp
instances.
Autopilot · optimize my workload
Say what matters and the hard limits; the autopilot measures instead of guessing, on this
instance, in stages: baseline (full suite, speed, decode at your depth) →
model files → one lever at a time (backend, speculative type, KV type,
projector placement, batch, draft tuning, cache reuse; anything that cannot fit at your
context is skipped, never launched) → second pass (near misses retried on the
final combination) → depth curves on the top configurations → full quality
suite on the finalists. Every result records the build, driver, kernel, power cap and
model checksum it was measured on. Typically 5–8 hours at quick budget; the server
restarts many times. Your saved settings are restored at the end. Nothing is applied until you
press Apply, and Apply can be rolled back.
loading…
Optimize
Benchmarks the selected instance on agentic coding work and searches for faster, more
accurate and more consistent settings. Every task is graded by a program: coding answers
run against hidden unit tests in a sandbox, tool calls are checked against their schema,
and a proposed bug fix is applied and executed.
Launch-setting phases restart the server many times, and clients see errors during
each restart. Your saved settings are snapshotted first and restored when the run ends or
is stopped. Nothing is applied until you press Apply on a result.
Validate running instance
Runs the pinned golden-answer suite against the instance currently serving chat. A soak repeats
these checks for actual wall-clock time. Failed cases count as failures and do not qualify
hardware. Validation never changes saved model settings.
Results
no runs yet
Compare endpoints
The same graded tasks on several model servers at once: this box's instances (llama.cpp,
vLLM, ONNX Runtime) and registered remote endpoints (another box, LM Studio, Ollama, SGLang,
anything OpenAI-compatible). One model in two formats, one format on two engines or two
devices: each task goes to every endpoint before the next, in a new random order each round,
and the replies are graded by programs (code against hidden tests, tool calls, JSON). Pass
rates come with their 95 % interval, speeds with theirs, and each endpoint is compared with
the first. Each server answers with its own sampling, and a busy server is measured busy.
math, reasoning, attention are generated from a seed when they run (exact answers, nothing to license or
memorize); attention gives each stack's effective context. Every stack gets an LS (LSM v1): quality,
performance, efficiency and reliability against the best stack here, under the profile you pick, after your
hard requirements - with the Pareto frontier marked.
Compare two models · perplexity and task suites
Candidate against baseline, measured the same way twice or more: perplexity (and KL divergence) of two GGUF
files on the CPU with
llama-perplexity, without touching a running server, or a task suite
(multiple choice and exact answers, JSON file) sent to two running instances you name. The difference comes with a
95 % interval; an interval that includes zero is called inconclusive. Each run is kept with a qualification
record. A KL-divergence run writes the full baseline logits under panel/evals/work while it runs:
tens of GB for a large model and corpus.loading…
Bench
Bench measures llama.cpp servers.
Bench · measurements that say how sure they are
Every number here carries an interval, and every comparison ends in a verdict:
better worse
small (real, under your margin)
same (equivalent within the margin)
undecided (no detectable difference at the precision reached).
Speed is measured at temperature 0 with a fixed seed, so draft acceptance cannot wobble
between runs; decode is measured at the depths your real requests reach; comparisons run
A-B-B-A and stop as soon as the answer is clear. Real requests come first: one that
queues behind a Bench request cancels it, and the block is measured again when the server
is quiet. Bench uses the server's only slot while it measures, and the prompt cache holds
test text afterwards (an agent's next request may have to re-read its context).
Your traffic
No GPU needed: what the requests of the last 14 days
say about noise, how much traffic it takes to see a change, and a verdict for every
configuration change they span.
loading…
Calibration · the platform's own error rates
loading…
Run
Profile the running server as it is (no restart)
Calibrate A/A: the saved settings against themselves, then the self-test
Compare A/B: saved settings (A) against saved + your changes (B); restarts the server
One setting per line, e.g. UBATCH=1024.
The saved files are snapshotted first and put back afterwards, and the server ends on the saved settings.
From another tool's command line (an optimizer's recommendation, a forum post): paste it, and measure the claim here
Goodput concurrency: 1..N simultaneous agent turns
Runs
no runs yet
Qualification records
What each finished Bench run, depth curve and optimizer run
measured, pinned down: the exact model file (SHA-256), the runtime build, every launch setting (secrets, addresses and folders left
out), the cards and drivers, what was run and what came out, sealed with a digest. Export one to share it,
Import someone else's to compare (it is refused if its digest does not match), tick two and Compare to
see exactly what differs between them.
Workload
What this instance's real requests look like, learned from
the traffic it already serves: how deep sessions go, how long answers are, how many run at once, which hours of the
week are idle, and how real decode compares with the measured curve. Every completed request is kept (llama-server
wipes its log on each restart); LexiPanel's own measurements are left out. Auto-fit, off until you turn it on,
uses this to measure changes in idle windows, then proposes them, or applies speed-only wins by itself, and checks
every change against the next real requests, rolling back one that made them slower.
What your requests look like
Context depth of requests
Busy and idle hours
Findings
Auto-fit
Proposals
History
Gateway: queue and batch jobs
Requests through the gateway (/v1
on this panel) never reach a server beyond its slots (llama.cpp parallel slots, vLLM's requests at once): the rest
wait here, interactive before batch. Mark a request as background work with the header
X-LexiPanel-Priority: batch or submit many at once to /v1/batches
(they run at batch priority and their results download as JSONL). Clients that call an engine's port directly
bypass this queue.
loading…
Connect a chat app (Open WebUI or any OpenAI-compatible client)
loading…
Fleet
Full LexiPanel on every box; one box is the primary and sees
them all. Members report every minute (outbound only). The primary can start, stop, safely restart and re-configure a
member's instances only where that member allows it (Remote actions, on the member); every command is signed,
runs once, goes through the member's own checks and is audited on both boxes.
Boxes
Link reliability and drift
loading…
reading network inventory…
reading storage locations…
Access
Single-user: Caddy's one login in front, as before.
Multi-user: the panel checks every request: users with a role (viewer reads; operator also starts, stops and runs
benchmarks and experiments; admin everything), API keys for scripts and MCP, and an audit log of every change.
Use systemd/Caddyfile.multi-user.new with it. Locked out: python3 auth.py mode single.
Users
Result vault
Encrypts finished results on disk - Compare runs, qualification records,
optimizer and Bench runs - so a copied disk, backup or support bundle does not give them away. Each record is sealed to the
vault's public key (X25519 + ChaCha20-Poly1305, RFC 7748/8439), so new results are encrypted even while the vault is locked;
reading them needs the private key: your passphrase (held in memory after Unlock) or a key file you keep elsewhere (a USB
drive). Lose both and encrypted results cannot be read by anyone, including you. Settings and runs in progress stay
plain, so recovery after a crash never waits for you.
Model verification
When on, the model library lists only GGUF files whose SHA-256
matches a verified record: a Hugging Face download checked against its listing, or a file admitted with its exact
SHA-256 and size. Files copied in by hand stay on disk but are hidden until admitted. Off by default.
API keys
Audit log
Panel layout
Fit: requants made for your cards
Plan maps goals to built-in recipes and estimates size with the selected quantizer.
Output, embedding and MTP choices override the recipe. Speed, quality and VRAM fit
need measurement on your hardware; these plans are not benchmark results.
Planning and building keep the server serving.
1 · Plan
Recipes · read how a GGUF was made, make it again
Explain compares a quantized file with its full-precision source and finds the
llama-quantize command that reproduces every tensor's format: the stock mix it started from,
the overrides on top (output layer, embeddings, MTP block, per-layer rules) and whether an
importance matrix was used. A final dry run proves it tensor by tensor. Headers only:
seconds, no GPU, nothing restarts. Build runs a recipe on a source here (CPU, low
priority; the server keeps serving). Export gives a JSON file someone else can import
to build the same layout; this box's paths are left out of it.
An importance matrix changes which formats llama.cpp picks, not only the rounding, so a
recipe made with one needs one to match. The maker's own is usually private: build or import
one in card 4.
2 · Candidates (report card)
Built models in
~/models/fit.
Verify runs the optimizer in models mode on the chosen instance: today's model first,
then each selected candidate, with the same coding and agent tasks, speed probes, a decode curve
by depth, and the VRAM each one really occupies. It restarts the server once per model; your
saved settings are snapshotted and restored. Progress shows in the Optimize tab.Refusals · uncensoring, phase 0
How often the running model refuses,
scored the way Heretic scores abliteration: prompts aligned models usually refuse
(
mlabonne/harmful_behaviors) and ordinary ones (mlabonne/harmless_alpaca)
to catch over-refusal, each reply's opening checked for refusal phrases. Downloaded on first
use, not shipped. Nothing restarts: it sends one chat request at a time to the running
server, so other clients wait a few seconds between them. Refused counts only a
first-person refusal at the start of the reply ("I can't…", "I won't…", "Sorry…").
Keyword is Heretic's own score, for comparison: it also counts an answer that opens
with "this is illegal" and then complies, so it runs high. Check the listed verdicts.3 · Your cards: measured formats
Measure formats on an instance's cards (phase B)
Makes one single-format test file per
format from the source (CPU, the server keeps serving), then stops the instance,
runs llama-bench on each of its cards with the instance's own KV and batch settings, and
starts it again. When the disk is short it works in rounds. Test files are deleted
afterwards unless you keep them.
What each vendor's cards are good at
4 · Importance matrix
Runs a high-precision copy of the
model over calibration text and records which weights carry signal, so the quantizer rounds
those more carefully (the i-quants gain most). One-time cost per model, reused by every
build. GPU work: stops the instance for the collection (roughly 20-40 min on a Q8_0
reference that spills a few layers to the CPU; ~10 min on today's model, less accurate).
The Q8_0 reference is built first on the CPU (~15 min, ~29 GB disk).
Import an importance matrix made elsewhere
Copied into this list and checked against the source picked in card 1 (which of its
weights it covers). One made on another fine-tune of the same base model loads, but it measured that model, not this one.
Default text is a code-heavy mix: Python sources, package docs and licences on this box. Agent transcripts from your own work make it better.
5 · Parts and other engines
llama.cpp cannot load a projector from
inside the model file; it always takes
--mmproj separately, so Fit builds the
projector as its own file (Q8_0 is ~2/3 the size of F16). stable-diffusion.cpp keeps the VAE at
f16 by default: it is small and quantizing it shows as banding. audio.cpp takes per-prefix keep rules.6 · Upstream watch
Once a day (05:10 UTC) the panel asks
Hugging Face whether each source's repository moved past the pinned revision, and flags
candidates built with an older quantizer. It only reports: fetching a new revision is ~110 GB
and is your call.
Fetch and convert a source (phase A)
Disk
Other engines · the same source for ONNX Runtime, vLLM / SGLang and AutoRound GGUF
Builds, from the full-precision Hugging Face folder, the
formats other engines serve - each by that format's own tool (ONNX Runtime GenAI's builder, llm-compressor,
AutoRound), in the same job slot as Fit (one heavy job at a time) under a memory and disk guard. The plan says what it
will weigh, what RAM, VRAM and disk it needs against what is free now, and the exact command - and refuses what cannot
fit. Every output gets a record (source and output SHA-256s, tool versions, calibration, time, peak memory); Check
tests it in its engine's terms; Measure scores it against its source on the same held-out tokens through its own
engine (paired, with a 95 % interval). Tools: bash install-factory.sh.
Built
What was measured
Available models
disk: …
Delete is permanent and these files are re-downloadable only over the link that took hours the first time. A model held by any backend profile or fallback tier cannot be deleted — hover the reason to see which file still points at it, and repoint that first.
Fetch by URL
Saves into ~/models. Resumable — re-submitting the same URL continues a partial file.
Use the repo's /resolve/main/<file> link, not the repo page — a page URL
returns 200 with HTML and is rejected here rather than saved.
Vision projectors (mmproj-*.gguf) download here too, then get
selected with Use on the Models tab. Each model repo ships its own and they are
not interchangeable: a projector from another repo has the same shape, so it loads
with no error and only the image answers are wrong.
Hugging Face access token
Gated repos (e.g.
meta-llama/Llama-3.2-1B-Instruct)
refuse anonymous downloads. Accept the repo's terms on huggingface.co with your account,
create a read token, and paste it here. It is stored in
~/.cache/huggingface/token (mode 600) — outside panel/, so
backups never include it — and handed to curl through a header file, never on its
command line. Only sent to huggingface.co.Publish measured model to Hugging Face
Preview a generated card and file list before any upload. Requires a Hugging Face write token above and sealed panel qualification IDs for the model. All files are relative to the panel's model folder. New repositories are private by default.
Transfers
Installed templates
Jinja chat templates in ~/models. The launch script SHA-pins
the selected template and aborts on a mismatch; the panel writes the matching pin
on every save. So editing a selected template on disk will stop the server starting —
re-save on the Parameters tab to re-pin it.
Use a model’s own template
Every GGUF here embeds the template it was built with. This lifts it out
into ~/models as a file you can select, instead of hunting for it on
Hugging Face.
Paste a template
Checked with Jinja2 before it is written. llama.cpp parses with minja, a subset of Jinja, so a clean parse here is necessary but not sufficient — Diagnostics reads the authoritative result out of the server log after a restart.
Download a template
Use the Download tab with a direct link to a .jinja
file (the /resolve/main/… form). It saves into ~/models
and appears in the table above.
GPUs
The cards below show this instance's primary device in detail.
Power cap
A cap limits average board power (PPT). It lowers sustained draw and heat, but sub-second spikes still go through, so it is not a fix for transient trips. Applied caps are saved and re-applied by the panel at start and every minute, so they survive reboots and GPU resets. Clear forgets the saved cap; the live value stays until the next reboot.
Memory
VRAM
GTT (host RAM over PCIe — high here means the model spilled)
Per-process residency
From DRM fdinfo. This is the trustworthy placement signal — unlike the whole-GPU counter, it isn't distorted by idle eviction.
Thermals & power
Clocks & link
VRAM vs GTT over time
amdgpu_top
GPU tuning
Every card in detail; its clocks, voltage, power cap
and fan changed through the power helper (range-checked, read back, logged in Power options); and each change
measured on this box's own workload. Changes here are live only: a reboot brings back the card's stock
table unless a boot profile (Power options) says otherwise, so an unstable setting is undone by restarting the
box. Apply and test runs the benchmark straight after the change and puts the previous values back if
the run fails, the server dies, the driver resets the GPU or a thermal limit trips. LLM decode reads every
weight for each token, so it is bound by memory bandwidth (fit/FINDINGS.md): memory
clock tends to move tokens/s, core clock mostly moves watts. Measure it here before you believe it.
Card
Clocks, voltage & power
Profiles
Save the values under “change to” (or the card’s live values) as a named fan / voltage / clock profile, test it with the benchmark, and set the winner to apply at every boot. Stored with the Power options profiles, so a boot profile is applied before the inference servers start and every change is in the same audit log.
Benchmark
The same llama.cpp request, repeated, against a running
instance on this card, with its power, clocks and temperatures sampled every second. Nothing restarts and no
setting changes (except with Apply and test). Run one at stock first: it is the baseline.
Board power during the benchmark
Results
Advice
VBIOS
Usage
Throughput
Prefill excludes prompts under 200 tokens — on short prompts the figure is almost entirely fixed overhead and reads misleadingly low.
Decode rate, recent requests
Prefill rate, recent requests
Plotted separately from decode on purpose. Prefill runs hundreds of t/s against decode's tens; sharing one axis would flatten decode into a straight line.
Draft acceptance
Workload dependent — around 0.82 on long documents, 0.48–0.61 on short chat turns. No fixed baseline: acceptance depends on what is being written, not on the card.
Recent requests
Checks
For a model
Bundle carries pre-analysed findings with evidence and fixes, the exact command line and env, the VRAM/GTT series, usage stats, known baselines and the trap list — so a model can diagnose without re-deriving what we already know.
Configuration backup
Packages every hand-tuned config on this box: the launch script and its revisions, this panel and its params history, the chat template, systemd units, the Caddyfile, ttyd config, netplan staging, and the archived engine logs — plus a live-state snapshot to diff against later. Excludes the 17 GB of .gguf weights and the llama.cpp binaries, which are re-downloadable. Roughly 700 KB. Built fresh on each click. Contains the Caddy basicauth hash, so treat the file as a secret.
Live command line
Power options
The equipment that decides whether this box
stays up, and the power settings that keep it up. Settings go in profiles; the boot profile is
applied at every start, before the inference servers, and drift from it shows here. Every change
is logged with the value before and after. Stability counts uptime and unclean stops per profile,
so a setting is kept on evidence. Changes need the one-time root helper below; everything is readable
without it except PCIe link states.
Host restart & shutdown
This controls the entire machine, including a LexiOS live session, not the selected inference instance. Active instances and jobs may be interrupted. Requires an administrator and the current root power helper.
Equipment
Settings
Profiles
Stability by profile
From the journal: a boot that ended with no
shutdown sequence stopped uncleanly. A manual power-off looks the same, so mark those; a stop marked as a
power cut is counted, but not blamed on the settings. Peer notes come from the heartbeat below.
Power budget & UPS
Change log
Crash analysis
Reconstructed from the journal and the parameter history, not from the live
process. Diagnostics only ever describes what is running now, so minutes
after a hard lock it reports every check green — which is exactly what it did
on the morning this was written. A host hard lock leaves no shutdown sequence in
its boot, so the test used here is negative: a boot that ended with no
poweroff/reboot markers and is followed by another boot died on its feet.
Findings
Boot history
Parameter changes
Every save writes a backup, so file mtimes are a real changelog. This is what
lets a crash be attributed to a setting rather than guessed at.
Automatic updates
Once a day at the time given (UTC), fetch the newest release of each chosen flavour,
unpack it beside the existing builds and check that it runs. Hold then waits for you
to press Activate; Auto also makes it the active build. Nothing ever restarts a running
server: a new build is used the next time an instance on it starts, and every older build
stays on disk for rollback unless you set how many to keep.
Installed llama.cpp builds
Builds live side by side under
~/llama; each backend records which one
it launches from in panel/builds.env. Nothing is overwritten in place,
so rolling back is the same dropdown as upgrading. A build is classified by the
ggml library it ships, not by its directory name.
Changing the active build needs a restart to take effect.
Engine capabilities
What each installed engine binary accepts, read from its own
--help once per exact build (by SHA-256)
and kept. Saving or starting an instance checks its settings against this: a flag the build does not know blocks,
anything else is a warning. After an upgrade, Flag changes shows what the new build added or dropped.reading the engine binaries… (a build is read once; vLLM can take ~20 s the first time)
Build from source
A llama.cpp pull request, a fork's branch or tag, or a commit plus a patch: where a new
architecture, format or speculative decoder lands before a release has it. It is built here
(at the lowest priority, on part of the CPU), installed beside the releases with a record of the
exact commit and patch, and never activated by itself. Qualify on any build checks a model
with it and compares its greedy output with the active build's, on the CPU, without touching a
running server.
Available upstream
Recent releases from
ggml-org/llama.cpp carrying an x64 Ubuntu asset
this box can run. Downloads unpack to a staging directory and are only promoted
once they yield a working llama-server of the expected flavour, so a
dropped connection cannot leave a half-build selectable.
Transfers
Log window
Refreshes every 5s while this tab is open. The view sticks to the bottom only if you are already at the bottom, so scrolling back to read something will not be yanked away by the next refresh.
Engine log
Launch log
Files ~
Drag & drop files or folders anywhere on this card, or
Click to select (Ctrl / Shift for more), double-click a
folder to open it. Drag rows onto a folder, the .. row or a path above to move them; hold Ctrl to copy.
Keys: Ctrl+A, Ctrl+C, Ctrl+X, Ctrl+V, Delete, F2 rename, Backspace up, Esc clear.
Folders and multi-selections download as a zip.
Rooted at your home folder. Hidden system folders (.ssh, .config…)
are not reachable from here, panel/ is read-only, and a file a server is using or a
setting points at (models, projectors, templates, a log being written) cannot be deleted, moved or renamed.
Disk usage tree
Apparent file sizes grouped by directory, compared with the selected drive's free space. The scan has strict entry/time/depth limits; a partial tree is an undercount, not the complete drive usage. Symlinks and other mounted drives are never followed. A full-system scan is available to administrators on request.