We use it every day

Cooling

GPU fan control

The task, on screenshot 1: the GPU fan is connected to the motherboard; it should follow the GPU temperature, run at full speed for a minute to confirm the control works, then get optimal levels, and after a reboot everything must work automatically.

1. 1
   Request

   An ordinary Telegram message, with no technical commands.

2. 2
   Reconnaissance

   First, without administrator rights, the agent established: Z10PA-U8 board, Tesla P100 GPU, GPU temperature readable (39 °C), but nothing yet to drive the fan with. It asked for administrator rights with a single command and laid out the plan. Once it had access, it found the Nuvoton NCT7904D chip (9 tachometer inputs, 4 PWM channels) and, sweeping each channel from 0 to 255, matched them: pwm2 → fan5, up to ~5300 RPM, which is the P100 blower. The other three channels stayed on BIOS automatic control.

3. 3
   One minute at full speed

   pwm2 = 255 for 60 seconds: within 5 seconds fan5 went from 1468 to 5294–5421 RPM and the GPU dropped from 37 to 31 °C. Then control went back to the curve (255 → 195 → 90); the tachometer readings confirm it works.

4. 4
   Curve

   ≤35 °C → 35%, 45 °C → 47%, 60 °C → 67%, 75 °C → 86%, ≥85 °C → 100% (the P100 throttles at 91 °C, so there is headroom). Speed changes smoothly, by at most ±15% every 5 seconds; if nvidia-smi stops responding, the fan goes to a ~78% failsafe.

5. 5
   Reboot

   The driver loads automatically and the control runs as a service that starts on boot. The agent actually rebooted the machine and checked everything from scratch: module loaded, service active, fan5 at 1319 RPM, GPU at 35 °C.

• From us: one command to grant administrator rights, the reply «Ready» and one confirmation along the way.
• ≈ 30 minutes (06:26–06:57 from the screenshots)

Configuration

Technical question, by voice

A practical task: in a voice message we asked how the system is set up. It answered with real data from our machines: hardware, disks, AI model and speed. If an item isn't clear, just ask right away what it means.

What the answer shows: two machines, claryel01 and P2002; processor, memory, GPU and disks; software versions; AI model; measured speed.

In this job the backup model was external (Grok) and had no filter. For our local system this is not acceptable, so the backup model was replaced with a second local one. Today cloud models are called only through the filter and, when needed, after the user’s explicit confirmation.

A technical term isn't clear? Ask the system right away, directly in the conversation: it explains it in plain words.

Machine fleet

Three machines, one agent

The request, on screenshot 1 (07:47): for each machine running Strata, memory size and type, NVMe, GPU and video memory, Strata version, model, agent version and the model's speed on that machine; a short answer in English.

The agent scanned the network itself and confirmed there are three machines (the other addresses are a printer and the Mac's Wi-Fi port). All three run Strata v0.1.45 with the same Qwen3.8-Flash-Next IQ3_S model (context 262 144), so the answers are consistent whichever machine serves them.

Generation speed: P2002 46.8 tok/s, Mac Studio 60.0 tok/s (the fastest), P1005 16.2 tok/s: a 78 GB model with 31 GB of memory, so this machine handles background jobs. All three are driven by one agent instance on claryel01; fallback follows the chain P2002 → Mac Studio → Grok.

In this job the backup model was external (Grok) and had no filter. For our local system this is not acceptable, so the backup model was replaced with a second local one. Today cloud models are called only through the filter and, when needed, after the user’s explicit confirmation.

Installation

Strata on a new machine: the agent worked through every pitfall itself

There is no ready-made Mac build: the Metal engine compiles from source (~5–15 min). The 0.1.45 Mac build turned out to be broken; the agent found the open PR #2895, applied it to the release, and the rebuild went through.

The 79 GB model: over HuggingFace via Starlink it would have run at ~6.5 MB/s (~3.4 h), so the agent copied it with rsync from P2002 using SSH agent forwarding, in 2 h 05 min. Then every request to the engine returned 400; the agent found the --no-prefill-borrow workaround in the source code.

Result: the Mac ≈ P2002 on generation (~58 vs ~57 tok/s) and clearly faster on prefill (+36%). The agent saved every pitfall in the strata-mac-deploy skill, so a repeat is almost a copy.

Update

The agent updated the engine of its own “brain”

Question (04:30): which Strata version the “brain” runs and which is the latest on GitHub. Answer: P2002 runs v0.1.43.1, the latest is v0.1.45 (released 17 October 2026). The agent warned that the update would restart the engine it runs on itself: a couple of minutes of downtime, with a rollback as a safety net.

On the command “update yourself” (04:31) the agent launched the update separately from itself: git pull → build of the HIP 0.1.45 engine → service restart, while a watchdog checks the engine for 5 minutes and rolls back to 0.1.43.1 if it does not come up. The build was clean (34 MB, 0 errors), but replacing the running file failed (“Text file busy”) and the engine stopped. The agent kept the old file as a backup, installed the new one manually and restarted the service.

Check (04:50): v0.1.45 is running, model Qwen3.8-Flash-Next IQ3_S, context 262,144. Speed with the same script: short answer 31.0 (before 33.5–33.7), 1024-token generation 47.7 / 44.4 (before 53.0–60.1), 1.5K prefill 874 / 531 (before 488–490). The agent’s reading: prefill clearly better, generation ~10–20% lower in two runs; with only two runs it does not call it a regression and offers 3–4 more runs and a rollback to 0.1.43.1 if the slowdown is confirmed.

In this job the backup model was external (Grok) and had no filter. For our local system this is not acceptable, so the backup model was replaced with a second local one. Today cloud models are called only through the filter and, when needed, after the user’s explicit confirmation.

Monitoring

Morning check of the home and the computers

The setup in the picture: Strata v0.1.43 + Qwen3.8-Flash-Next (IQ3_S) + the agent. The agent reads Home Assistant sensors (temperature, humidity, motion, light, energy) and checks backups, disks and computer temperatures. We talk to it through Telegram.

What the check found: the room with the computers is at 28.8 °C, noticeably warmer than other rooms, so ventilation and cooling should be checked; the sensor batteries in the office (20%) and on the terrace (30%) need replacing; the “Leo” door sensor shows ON, but the reading may be outdated and should be checked on site.

Viktor did not even open the Home Assistant interface. Supporting tools that day: ChatGPT drew the picture for the post, ChatGPT Go + Codex helped with the setup, and the agent from time to time turned to Grok 4.7 as an additional model for complex reasoning.

In this job the backup model was external (Grok) and had no filter. For our local system this is not acceptable, so the backup model was replaced with a second local one. Today cloud models are called only through the filter and, when needed, after the user’s explicit confirmation.

An illustration for the post, not a screenshot.

Model speed

31 tok/s with RAM almost free: the model is read from the SSD

Settings: model Qwen3.8-Flash-Next IQ3_XXS (~47 GB), context 64K (65,536 tokens), 8-bit KV cache, low-RAM mode: part of the model’s “experts” is read from the SSD. GPU: AMD Radeon RX 9070, ~16 GB.

The result on the Strata monitor: 12,136 tokens in 396.3 s, generation 31.0 tok/s, VRAM 15.7 of 16 GB, RAM 3.2 of 31 GB, GPU 45 °C. 5,681 “experts” (9.2 GB) sit in video memory; the rest is read from disk.

Takeaway: a large model runs without a huge amount of RAM, because the engine keeps what matters most in video memory and reads the rest from a fast SSD. That is a path to much more affordable computers for local AI.

Model speed

256K context: 26 requests on a single 16 GB GPU

The goal was simple: to understand how to automate such runs later on different hardware and how to format the results for comparison. Machine: Intel Core Ultra 7 270K Plus, 31 GB RAM, AMD Radeon 16 GB.

The total since Sunday morning (09:44): 26 requests, 169,326 prompt tokens read at 108 tok/s (another 1,923,247 taken from the conversation cache), 166,539 tokens written at an average of 20.5 tok/s. The context is 62% full (162k of 256k).

Not everything went smoothly: the list shows one request “Closed” and one “Stopped”. The video in the original post shows the model writing a long technical answer; there Viktor also explains what went wrong.

Model speed

More RAM: 45 tok/s on a 164,000-token context

Computer: Intel Core Ultra 7 270K Plus (24 threads), AMD Radeon 16 GB, 62 GB RAM, context 262,144 tokens. Now the engine uses RAM too: 53.5 of 62 GB in use.

Two requests of about 162,000 tokens each: the first was read at 1,176 tok/s with generation at 48.3 tok/s; the second came almost entirely from the conversation cache (162,199 tokens), generation 45.2 tok/s.

The trade-off is clear: with more RAM generation is noticeably faster, but less memory is left for other tasks. With 31 GB the engine barely touched RAM, and the computer stayed free for other work.

Model speed

An old Xeon and a Tesla P100: 19–27 tok/s

The model does not fit in RAM and runs from video memory (15.7 of 16 GB) and from an NVMe drive over PCIe 3.0. The CPU is at about 45%, RAM is almost free, so the computer can be used for other work too.

On the monitor: generation now 26.9 tok/s; in the request history, 19.3 tok/s on a short answer (253 tokens) and 25.3 tok/s on a long one (12,686 tokens in 504.1 s). GPU at 36 °C, 97 W of 250.

For us this is the key price benchmark: even old, inexpensive hardware with a properly configured engine is already fit for real work.