Bionic (local LLM subagent via LM Studio)

What this actually talks to

The user has a desktop app called Bionic, made by LM Studio, for running LLMs locally. Bionic itself is a GUI-only Electron app with no CLI or API — there is nothing to script against it directly. But the model it runs sits on top of LM Studio's own runtime, which does expose a scriptable interface:

• lms CLI at %USERPROFILE%\.cache\lm-studio\bin\lms.exe — lists/loads/unloads models, starts/stops a local server.
• That server exposes a normal OpenAI-compatible REST API (default http://127.0.0.1:1234) once started.

So "ask Bionic" in practice means: make sure a model is loaded in LM Studio, and send it the task over that local REST API. The user does not need Bionic.exe running at all for this to work — LM Studio's own server is the actual engine.

Configuration panel

There's a clickable config app, "Subagent BionicClaude" (desktop shortcut, or run scripts\Subagent-BionicClaude.ps1 directly), where the user sets: which model to use by default, the server port, temperature, and max tokens, plus buttons to start/stop the server and load/unload/download models. Settings saved there land in config.json next to this SKILL.md, and bionic-ask.ps1 reads that file automatically for any parameter not explicitly passed on the command line — so if the user says "I changed the default model in the panel," you don't need to pass -Model yourself, it'll already pick up the new default.

Activity panel

The Subagent BionicClaude config panel has a built-in black-background/green-text terminal section at the bottom labeled "Bionic Activity - live subagent transcript." It auto-refreshes every second and shows what's being sent to the local model and what it replies, in near real time. Every call to bionic-ask.ps1 appends the task, files, and full response to transcript.log next to this SKILL.md; the panel just tails that file. You don't need to do anything extra for this to work — it's automatic as long as you invoke the local model through bionic-ask.ps1 as documented below.

How to use it

Run the bundled script for every request to the local model — don't hand-roll Invoke-RestMethod calls, since the script already handles starting the server and picking a loaded model:

powershell -File "C:\Users\John\.claude\skills\bionic\scripts\bionic-ask.ps1" -Task "<what you want it to do>" -Files @("path\to\file1.py","path\to\file2.py")

Parameters:

• -Task (required) — plain-language description of the subtask. Be specific; this model is smaller than you and does better with a narrow, concrete ask than an open-ended one.
• -Files (optional) — array of file paths to give as context. The script reads and embeds their contents; the local model cannot read the filesystem itself.
• -Model (optional) — an LM Studio model identifier. Leave this out unless the user has explicitly told you which model to use. Which models are installed changes over time (the user downloads/deletes them via the config panel), so don't hardcode or guess a model name — a name that was valid last session may no longer be installed, and the script will error out clearly rather than hang, but it's still wasted a whole round trip. Omitting -Model lets the script fall back, in order, to: the default saved in the config panel, then whatever's currently loaded in LM Studio. If you genuinely need to know what's installed (e.g. the user asks "what models do I have"), run & "$env:USERPROFILE\.cache\lm-studio\bin\lms.exe" ls rather than assuming.
• -Temperature, -MaxTokens (optional) — tune if the default (0.2 / 4096) doesn't fit the task.

The script validates that a requested model is actually installed and actually loads before sending the task — if it isn't, you'll get a clear error listing what is installed, instead of the request silently hanging against a model that was never loaded.

The script prints the model's raw response to stdout. Read that output yourself before doing anything with it — treat it the same way you'd treat a suggestion from any other subagent: useful signal, not something to blindly trust.

Applying results — always review first

The local model has no filesystem access; it can only propose text back to you. When it proposes a full file's contents, it prefixes the block with a line like:

FILE: path\to\file.py

followed by a fenced code block with the new contents.

Do not write these changes to disk automatically. Show the user what the local model proposed (a summary, or the diff against the current file) and get their go-ahead before you apply it with your own Edit/Write tools. This mirrors how you'd handle output from any other subagent whose judgment hasn't been vetted — the local model is smaller and more error-prone than you, so treat its output as a draft, not a patch.

Staged-diff mode (saves your tokens on large file edits)

There's an opt-in toggle in the config panel ("Staged-diff mode"), off by default. When the user has it on (or you pass -StagedDiff "true" explicitly for one call), the script changes its output for any FILE: block that modifies a file that already exists: instead of printing the full new file contents, it writes the proposed content to a staged copy on disk and prints a diff against the original instead. New files are unaffected (nothing to diff against, and no doubling-up cost to avoid). The output tells you the staged file's path.

This matters because without it, a large file's full text passes through your context twice -- once when the local model's raw response lands in your context, and again when you re-emit the whole file yourself via Write/Edit to apply it. With it on, you only see a diff (usually far smaller), and once the user approves it you apply the change with a plain file copy instead of retyping the content:

Copy-Item "<staged path from the output>" "<original file path>" -Force

Still show the user what changed (the diff itself is exactly that) and get their go-ahead first, same as always -- this mode only changes how the proposal is transported to you, not whether it still needs review. If the user hasn't mentioned this setting, don't assume it's on; it defaults to off, and normal full-content behavior applies unless they've explicitly enabled it or ask you to for a specific call.

If the user just wants an opinion, explanation, or second take rather than a file edit, there's nothing to apply — just relay what it said.

These are small models (7-8B parameters) running locally, and in testing they sometimes keep generating past a clean answer — echoing training-format artifacts, fake follow-up turns, or restating the prompt back. Read to the end, pull out the actual answer, and don't just forward the raw output verbatim to the user; trim the noise the way you would clean up any messy subagent response.

When the server or model isn't ready

The script already handles the common cases (starting the server if it's down, using whatever model is loaded if -Model isn't given), and will error out with a clear message + suggested fix if nothing is loaded and no model was specified. If that happens, tell the user what happened and either ask which model to use or offer to load one yourself with:

& "$env:USERPROFILE\.cache\lm-studio\bin\lms.exe" load <model-name>

Run & "$env:USERPROFILE\.cache\lm-studio\bin\lms.exe" ls to see what's installed.

Why not automate the Bionic GUI itself

It was tempting to drive Bionic.exe directly, but it's a plain Electron app with no IPC, CLI, or HTTP surface exposed for automation — its only open port returns 404 on every route. UI-automation (simulating clicks/keystrokes in the Electron window) would be fragile and is not worth the complexity when the same model is reachable cleanly through LM Studio's own server. If a future LM Studio/Bionic release adds a real API, this skill should be updated to use it.