How it works
- In Automation, describe the automation in your own words. With a flow already open, describe the change instead - the assistant refines that flow.
- BenchMesh sends your request to the model together with the flow format, safety rules and the vocabulary of your bench: which instruments exist and what each can read and set, with its limits.
- The model answers with a complete flow and a short explanation - what it does, what to check before running it, what it assumed.
- BenchMesh validates the flow against your bench. If it has errors, they go back to the model, which may correct itself - up to two times.
- The result, its explanation and any remaining issues are loaded into the editor. Nothing runs automatically: you read it, change what you want, and start it yourself - arming it if it switches an output on.
The model is told to address only the instruments and operations on your bench, to put every number you may want to tune into the flow’s settings with a unit, to switch off in the cleanup every output or input it switches on (setting safe setpoints first), to bound every loop and not poll faster than needed, to add checks for limits you mention, and - when your request is ambiguous or would need a guess at a voltage or current - to choose the conservative value, make it a setting and say so.
Bring your own key
The assistant uses your account with an AI provider. Open Automation → Settings, pick a provider, paste its API key and choose a model (the list comes from the provider).
| Provider | What it uses | Key |
|---|---|---|
| Anthropic | Claude models through the Messages API. Default model claude-sonnet-5-5; pick another from the list. | API key from the Anthropic Console |
| OpenAI | Chat Completions API. Choose a model from the list. | OpenAI API key |
| OpenRouter | Many vendors’ models behind one key and one bill. Choose a model from the list. | OpenRouter key |
| Custom | Any OpenAI-compatible endpoint given by its base URL - a local Ollama (http://localhost:11434/v1), LM Studio’s server (http://localhost:1234/v1), or a company gateway. The model must support tool (function) calls. | Optional - local servers usually need none |
The key is stored on your computer, in ~/.benchmesh/automation.json (readable only by you on Linux and macOS). After saving, the app’s page never sees it again - only a hint such as sk-…a1b2. Each provider keeps its own key; saving an empty key removes it.
What is sent where
Requests go directly from BenchMesh on your computer to the provider you chose and are billed to your account there. There is no BenchMesh server in between, and BenchMesh never receives your key or your requests.
| Sent to your provider | Not sent |
|---|---|
|
|
Your provider’s own terms decide what it keeps. With a local model (Ollama, LM Studio) nothing leaves your computer.
Example requests
“Discharge the battery on the load at 0.5 A until 3.0 V and record voltage and current.”
Expect Params for the current (0.5 A) and the cut-off (3.0 V); setup with a prompt to connect the battery, constant-current mode, the current setpoint, a recording of the load’s VIN and IIN, then the input on; a repeat … until the voltage is at or below the cut-off, with waits; cleanup switching the input off. Running it asks you to arm the load input.
“Sweep the PSU from 0 to 12 V in 0.5 V steps, wait a second at each step and log the current.”
Expect A sweep from 0 to 12 by 0.5 that sets the voltage, waits, reads IOUT and logs it; the output switched on in setup after the first setpoint and off in cleanup; the step size and dwell as params.
“Hold 5 V on the DMM by adjusting the load current, never more than 2 A.”
Expect The classic regulation loop: read the DMM, raise or lower the load current in small steps, clamp with min / max to 0 … 2 A, a bounded repeat, the load input off in cleanup.
“Change the flow so it also stops if the supply current goes above 1.5 A.”
Expect With a flow already in the editor, the assistant gets it along with the request and returns the whole updated flow - here with a read of IOUT and a check that stops the run above 1.5 A, the limit as a new param.
Compare the result with the worked examples - they are the kind of flow a good model produces.
Tips for good requests
- Name the instruments as they appear on your bench (“the PSU”, “the OWON load”, “the DMM”) and say which channel when a supply has several.
- Give the numbers: targets, limits, step sizes, durations, cut-offs. What you leave out becomes a conservative setting the explanation mentions.
- Say when to stop - a voltage, a time, a number of points - and what counts as a failure (“stop if the current exceeds 1.5 A”).
- Say what to keep: “record voltage and current”, “log the efficiency at each point”.
- Refine in steps. Start simple, run it at low limits, then ask for changes to the open flow.
- Read the explanation and the flow before running it, especially setpoints and what the cleanup switches off.
Limits and troubleshooting
- “no API key for …” - add one for that provider in Automation → Settings.
- “the provider refused the API key” (401 / 403) - the key is wrong, revoked or lacks access to the model.
- “rate limited or out of credit” (429) - wait a moment, or check the balance and limits of your provider account.
- “choose a model” - OpenAI, OpenRouter and custom endpoints have no default model; pick one in the settings.
- “cannot reach the provider” - no internet, a proxy or firewall, or (custom) the local server is not running at that base URL. A request gives up after 120 s.
- “the model did not submit a flow” - the model answered in text instead of calling the flow tool. Use a model with reliable tool calling.
- Issues left after the corrections - the flow is still loaded with its issues listed; fix them in the editor or rephrase the request.
- Choosing a model. Larger, current models follow the format and the safety rules best. Local models are private and free to run, but smaller ones often produce weaker flows - more corrections, missing checks, odd settings. Review their output with extra care.
The same is available over the local API, for scripts:
GET /automation/assistant
{"provider": "anthropic", "model": "claude-sonnet-5-5", "models": {}, "base_url": "",
"keys": {"anthropic": "sk-…a1b2", "openai": null, "openrouter": null, "custom": null},
"providers": ["anthropic", "openai", "openrouter", "custom"]}
PUT /automation/assistant
{"provider": "custom", "base_url": "http://localhost:11434/v1", "model": "qwen3:14b"}
POST /automation/assist
{"instruction": "Discharge the battery on the load at 0.5 A until 3.0 V and record voltage and current"}
→ {"flow": {…}, "explanation": "…", "issues": [], "attempts": 1}