LTspice Agent Automation
A Python-controlled LTspice simulation, analysis, and automation toolkit built for agent-driven electronics workflows. It treats text netlists (.cir / .net) as the reproducible execution boundary, while still supporting real LTspice .asc schematics.
- Language
- Python
- Simulator
- LTspice (batch mode)
- Boundary
- Text netlists — .cir / .net
- Interfaces
- Python API, REST API, MCP server
- Storage
- Run manifests, SQLite history
- Status
- Active
What it is
LTspice runs simulations from the command line perfectly well. Everything around that — getting waveforms back out in a usable form, sweeping a parameter across a hundred runs, remembering what you ran last week and what it produced — is left as an exercise for you. This toolkit is that exercise, done once, in Python, and shaped so an AI agent can drive it end to end.
The decision the whole design rests on: text netlists are the execution boundary. A .cir or .net file is plain text, so it diffs, it versions, and it reproduces exactly — which is what you want when an agent is generating and mutating circuits. Real LTspice .asc schematics are supported too; the netlist is simply what actually gets run.
What it does
- Batch wrapper
A cross-platform Python wrapper around LTspice batch mode.
- Waveform I/O
Binary and ASCII .raw waveform parsing, with CSV export and plotting.
- Result extraction
Pulls .meas results and native .step sweep data out of a run.
- Analysis
Parameter sweeps, Monte Carlo analysis, and target-response search.
- Run bookkeeping
Durable run manifests, SQLite history, and a static HTML dashboard.
- REST API
A local REST API with both synchronous and asynchronous endpoints.
- MCP server
Exposes the whole toolkit as native tools any MCP-aware AI agent — Claude Code included — can call directly, with no HTTP client in between.
A Sallen-Key filter that peaks and rings
The project started out on simple RC circuits. This one is the first with genuine 2nd-order dynamics: a Sallen-Key active low-pass filter, with the op-amp modelled as an ideal fixed-gain E-source at K = 2.5 and Q = 2. Which means it does the two things a first-order RC never does. It peaks, and it rings.
- Topology
- Sallen-Key 2nd-order active low-pass
- Op-amp
- Ideal — fixed-gain E-source
- Gain (K)
- 2.5
- Q
- 2
- Passband gain
- 7.96 dB
- Peak
- +14.26 dB @ 933 Hz
- Overshoot
- 44.4%
- Settles to
- 2.50 V
In the frequency domain the response peaks at +14.26 dB at 933 Hz, well above the 7.96 dB passband gain. In the time domain the same poles show up as 44.4% overshoot and visible ringing before the output settles to 2.50 V. Both were verified against the closed-form theoretical predictions rather than eyeballed off the plot.
The schematic is a real file, not a picture of one
The same filter also exists as an actual GUI-editable LTspice .asc schematic — the file in Fig. 1. It was hand-authored from LTspice's own installed symbol library, with the exact pin geometry read out of the real .asy symbol files rather than guessed at or assumed, then verified pin by pin by opening it in the live LTspice application and visually confirming every connection.
That is the part worth pointing at. It is a real, working schematic that anyone can open in LTspice and edit — not a mockup and not a drawing of a circuit.
LTspice's batch mode can't netlist a .asc on macOS
LTspice's -b batch mode cannot netlist a .asc schematic file on macOS. It is not something odd about this project's schematic either — it reproduces against LTspice's own officially bundled example schematic. .cir and .net text netlists batch flawlessly.
It is a genuine limitation, and an annoying one to walk into blind, so it is written up in the project's LEARNINGS.md for anyone who hits the same wall.
Go read the source
The netlists, the .asc schematic, the MCP server and the write-up of the macOS batch mode limitation are all in the repository.