Device Details

The website/features look promising. I got it but it just linked me to Github when I selected my AI agent choice. I don't know what to do to make it work.

Gemini CLI and the other 3 AI selections show a crossed out grey symbol when I highlight the selections.

Hello !

I've updated the device here, as well as on the website (https://agent4live-7cfed.web.app/) and on GitHub (https://github.com/romsau/agent4live). Hopefully this resolves your issues. Feel free to reach out to me on X as well: https://x.com/romainsauvez. Thanks for reporting these bugs to me.

Now I got this far with the updated agent4live. I was able to select Gemini CLI but it said "Waiting for the first agent call....." There is no visible prompt to allow input.

Good news! The device is now waiting for your agent to make a call. Once Ableton is open and you have dropped the device on a track, open Gemini CLI in your terminal and ask it to do something. Example prompt: "In my current Ableton project, change the tempo to 75 bpm."

It's functioning fine now. I like the interface of ReaAssist in Reaper 7 more. Maybe you could update agent4live to have a multi-option menu like in the ReaAssist Github script for Reaper and also an automatic Gemini CLI login. That would enhance the AI experience of agent4live.

ReAssist is an AI assistant for Reaper that like I said is more advanced/feature filled than agent4live. Here's a link to it https://reaassist.app/ Maybe you could advance your m4l but there must be other Live AI stuff on it's way.

Ableton made their own working MCP, this one does not work and completely ignores the fact that security matters. I would read all this code before using this. https://claude.ai/directory/connectors/ant.dir.gh.ableton.ableton-knowledge

Confirmed working great using Gemini CLI, token burnage was wild tho.

Hi Blasto,

Thanks for your feedback!

Unfortunately, the Ableton MCP you're referring to only exposes the knowledge base — it doesn't expose Ableton's API.

I'm sorry to hear the device isn't working for you. Could you explain the issue you're running into?

Security is very important to me and I'm trying to move forward on this topic as fast as I can! All sources are available on GitHub: https://github.com/romsau/agent4live

Here's what's already in place:

Loopback-only network surface — exclusive bind on 127.0.0.1 for HTTP MCP (app/server/index.js:365,484) and for the JSON-TCP bridge with the Python companion (app/server/python.js:15). Inaccessible from the network.

16-byte crypto-random Bearer — generated at boot, verified on every /mcp request, regex validation ^[a-f0-9]{32,}$ before adoption (app/server/config.js:60; app/server/mcp/server.js:54-64; app/server/discovery.js:47-58).

Token persisted across reboots — in ~/.agent4live-ableton-mcp/endpoint.json so CLI configs don't break on every relaunch (app/server/discovery.js:109-137).

Origin check on /mcp — blocks requests whose Origin header isn't 127.0.0.1 or localhost, explicit 403 with log (app/server/mcp/server.js:27-46).
chmod 0o600 on sensitive files — endpoint.json and preferences.json readable only by the user running Live, double-write mode + chmodSync (app/server/discovery.js:125-130; app/server/preferences.js:92-96).

Token never exposed via /ui/state — stripped by destructuring before JSON serialization (app/server/index.js:91). If the jweb is compromised, it cannot leak the Bearer.

Opt-in consent to modify CLI configs — the device never touches ~/.claude.json, ~/.codex/config.toml, ~/.gemini/settings.json, or ~/.config/opencode/opencode.json without explicit consent recorded in preferences.json (app/server/preferences.js:8-23; app/server/index.js:184-192).
Silent migration only for localhost entries — the first-boot scan rejects any non-loopback scheme via _isLocalhostUrl() (app/server/preferences.js:146-189,222-224).

Subprocess without command injection — execFileSync with args as an array (not exec with a string), no shell interpretation even if the token contained special characters. Strict timeout (app/server/discovery.js:179-186).

Isolated Python companion — communication only via loopback TCP socket in JSON-line format, no eval / no exec / no unsafe native Python deserializer, Python methods strictly validated on the companion side (app/server/python.js:25-77).

Tool input validation (Zod) — each tool defines a Zod schema, the MCP SDK validates args before calling the handler. No LOM injection via malformed tool args (app/server/tools/define.js:35).

Defensive code on external configs — all CLI config reads wrapped in try { } catch (_) {}, hand-rolled Codex TOML parser (zero TOML dependency added, no RCE risk from a buggy lib) (app/server/preferences.js:150-187).

Multi-device: only one active — EADDRINUSE → passive mode with no filesystem writes and no discovery, avoids overwriting the active instance's token (see docs/ARCHITECTURE.md section "Multi-device — passive mode").

I still have a few points left to handle, which will be delivered in version 1.3.

Hi Conduct,

Glad to hear it's working well!

I'm trying to find solutions for the token issue, but it's not easy. Do you have any ideas?

On my end, I mostly use it with OpenCode and a local LLM to avoid token problems!

Hi Syn,

Thanks for taking the time to compare and share thoughts — really useful feedback.

Quick context on what's possible

Multi-option menu / capability cards — totally doable and it's already on
our roadmap. ReaAssist's welcome screen with starter prompts maps cleanly
onto two features we're planning: a library of clickable prompt templates
organized by category (composition / mixing / organization / debug) that
copy to clipboard, plus a "what can I ask the agent?" cheat sheet for new
users. Should land in upcoming versions.

Automatic Gemini CLI login — we already do half of it: agent4live
auto-registers its endpoint in `~/.gemini/settings.json` so Gemini CLI sees
the device on first launch (same for Claude Code, Codex CLI, OpenCode).
What we can't do is authenticate Google for you — your API key stays in
your Google account. ReaAssist works around this by being a chat client
itself ("bring your own keys" inside their app), but agent4live is a tool
server: the LLM relationship is between you and whichever CLI you pair us
with. We can't legally or technically intercept that auth.

One architectural difference worth flagging — Reaper is famously open
and scriptable (Lua/JSFX), which is why ReaAssist can generate scripts and
have agents run them inline. Live is more closed: no equivalent scripting
layer for third-party agents. So instead, we expose **232 LOM tools** (Live
Object Model operations) for the agent to call individually. More granular,
does the whole task" pattern. That's a real ceiling we can't bypass unless
Ableton opens M4L further — which would be great but isn't on us.

I’ll keep pushing what's possible from inside a Max for Live device. Thanks again for the push.

Hi romainsauvez, 
I'm by no means an AI expert, but am just now "deep diving" into this whole DAW MCP fad that has contenders popping up by month. Just stumbled upon ableton-cli, the developer has an article on token efficiency (haven't tested the tool itself myself, but the reasoning seems valid): https://zenn.dev/ryok/articles/ableton-cli-token-efficient-mcp?locale=en

On a positive note, this will work with dozens of other AI "agents" such as Cursor, GitHub Copilot, Windsurf, Cline, Kiro, and OpenClaw.
All of these "agents" are simply extra text that is passed along with your chat with the LLM. That is it. An agent is simple given the ability to run scripts on your computer (or a server etc...) So if it works with one of them, it will work with the others.

I didn't realize the official Ableton MCP doesn't expose the API, I just wanted to share the most official of the dozens of Ableton MCP out there.

There are dozens of other Ableton MCP implementations that have multiple active developers, why do we need this one, that uses a clunky max for live patch instead of using python that runs inside of ableton and gives you access to more than the 232 tools you mention. With python remote scripts you have access to redo/undo, you can focus windows, toggle the visibility of the Browser, Clip Detail, or Plugin windows, uses much less overhead compared to a m4l device/
The following are big projects that have been around a while
I have personally used
https://github.com/ahujasid/ableton-mcp
^^^ Uses a MIDI remote script instead of a max patch

http://github.com/Simon-Kansara/ableton-live-mcp-server
^^^ Uses OSC instead of Max Patch

Have not used:
https://github.com/uisato/ableton-mcp-extended
You would learn a LOT more by helping contribute to one of the active projects that have developers that are more experienced than you.

Understanding security is very different from having an LLM write stuff you don't understand.

Hi Blasto,

Thanks for this positive, kind, and open-minded feedback!

I've taken note of all your recommendations!

Have a great day making music with Ableton!