Overview

The Mel agent is an AI teammate that lives inside your terminal. Start a conversation with ctrl+enter (cmd+enter on macOS), describe what you want, and the agent reads your code, edits files, runs commands, and verifies its own work — all in the same pane where you'd otherwise be typing shell commands yourself.

Models and keys

The agent's model traffic goes only through Mel's backend (saving a provider key makes one check call from your computer to that provider). The agent thinks and plans there — on Mel's server, never on a model running on your computer — and streams the answer from whichever model the turn resolves to. The model picker offers models from Anthropic (Claude), OpenAI (GPT), Google (Gemini, Gemma), xAI (Grok), Groq, DeepSeek, Moonshot (Kimi), Z.ai (GLM), MiniMax, Alibaba (Qwen) and Xiaomi (MiMo); see Models & pricing. Where the provider key comes from depends on your plan:

• Pro, Max and Business: nothing to configure. The backend holds Mel's provider keys server-side, and turns draw on your plan's credits.
• Free: the agent runs on your own provider key, added in Settings → AI → Provider API keys. Groq and Google AI Studio both give keys at no cost — see Get a free model key.
• Any plan: you can add your own key; a turn on it costs 0 Mel credits. The key is stored on your device (the OS keychain, or a file only you can read on Linux) and travels with each request to the backend, which uses it for that request and never stores it.

Pick a model explicitly or leave the chip on auto and let the router decide per turn. See Models & routing, and Agent streaming if you want the wire-level details.

Tools run on your machine

The backend never touches your files. When the model wants to act, it asks for a tool call — read_file, grep, edit_file, run_command, and friends — and Mel executes it locally, in the working directory of your pane, then sends the result back for the next step. Your code goes to a provider only as the context you and the agent put into the conversation; the file and command tools themselves are local (web search and page fetching go through Mel's backend). The full toolset is documented in Tools & approvals.

You stay in control

Reads are low-risk and run freely, and so do commands that only read (ls, cat, git status and the like, decided by a closed list). Anything that changes state — writing a file, editing a file, running another command — pauses the run on an approval card: Run command or Allow edit, a box to always allow that kind of action for the rest of the conversation, and Deny. An edit card shows the diff of exactly what will be written. A command Mel recognises as impossible to undo, a credential file (or a command that names one), a write outside the project and every connector call stop for you whatever you've allowed — see Security & privacy. Every applied change renders a diff card with + / - line counts so you can see exactly what happened. When you trust a run, flip on autonomous mode and let it go hands-off.

Folders, and staying in one

The Folders button above the footer opens a short list of the folders Mel read from and the folders it changed in this conversation, with a count for each, grouped under your project and "outside this project". Click a folder to open it in your file manager. A command that does not name a path (a build, a test run) cannot be placed, so the list says how many ran instead of guessing.

The same panel has a Stay in this folder switch, off by default. With it on, Mel asks before its file tools, or a plain reading command such as cat or grep, read a named path outside the project's folder. It is a check on those reads, not a sandbox: a program that opens a file by itself (a Python one-liner, a copy) is not seen. That card, like the one for a write outside the project, cannot be waved through by "always allow" or a hands-off run, and cannot be answered from a phone. If nobody is at the desk the read is refused. The switch is saved with the conversation; while it is on, a Staying in this folder - turn off button shows above the footer. A new conversation starts with it off, a cloud task or a hand-off to your phone does not carry it (they run in a disposable machine), and the temp folder is always free.

What a run looks like

A typical turn: the agent reads the relevant files first, posts a live task checklist, works through it — check-offs stream into the transcript as they happen — and finishes with a summary plus a usage line under the answer (model, tokens, what it cost, time), and the conversation's running total. A long task that is still making changes carries on by itself past one turn's limit, so one prompt can scaffold and build a whole project; one that stops making progress ends with a report of what was done and what is left. See Tasks & the agent lifecycle and The conversation view.

Where to go next