Run a Local Coding Agent with LM Studio

What each tool does

• LM Studio lets you browse and load models, then start a local server that OpenPilot can use via an OpenAI-style API.
• OpenPilot is the desktop coding-agent app. You choose a project folder, and the agent can read and edit files and run shell commands as part of its workflow.
• The model interprets your request and decides how to use the tools. Its coding ability, instruction-following, and context capacity affect the outcome.

This split is useful because OpenPilot isn't locked to one model provider. You can configure multiple models in OpenPilot and switch between them per chat. That makes it easier to keep a smaller model for quick edits and move to a larger one when a task needs more capability - assuming your hardware can actually run it.

What local does and does not mean

Running a model locally means the model runs on your computer instead of being sent to a hosted model API. That's a legitimate privacy and control win for personal experiments. But "local" doesn't automatically mean "private everywhere" or "risk-free." OpenPilot's telemetry is enabled by default, and you can turn it off during Getting Started or in Settings → About. The project says the anonymous usage data includes app opens, feature and model usage, and token counts - not your chats, files, paths, or keys.

Also, an agent can still make real changes on your machine. Running locally only changes where the computation happens. You still need to review edits and approve commands. Treat the model as a tool that can be wrong - not as an authority on your project.

For the project and its current releases, see OpenPilot on GitHub or the OpenPilot website.

1. Download a Qwen 3 model

In LM Studio's model search, look for a Qwen 3 model. The OpenPilot author reports good results with Qwen 3 8B and Qwen 3 27B. If you're unsure what your machine can handle, start with the 8B model.

There isn't one "correct" model size for everyone. RAM/VRAM, the model's requirements, and what you want the agent to do all affect how it feels. Pick a model that loads reliably, then test it on a small task before deciding you need something larger.

2. Increase the context length when loading

When you load the model, raise the context length above the default. This is easy to miss, and it can make the agent look worse than it is.

An agent doesn't just send your newest instruction. Over a task, the context can include file contents, tool outputs, and the conversation history. A small context window can fill quickly - especially when the agent reads multiple files or triggers several tool interactions.

If the agent starts getting confused or stops halfway through, check the context setting early. Increasing context can help, but the best value depends on what your system can support. Don't assume the maximum setting will always work - start with a value your machine can handle and increase only if your tasks really need it.

3. Start the local server

In LM Studio, open the Developer tab and enable Start server. You can also start it from a terminal with:

lms server start

By default, the server address is http://localhost:1234. For an OpenAI-compatible client, the base URL is http://localhost:1234/v1. If you changed the server port in LM Studio, use that port here.

Keep the base URL and the server address straight: OpenPilot needs the /v1 endpoint. If you enable authentication in LM Studio, you'll need to provide the configured token when you connect the app.

4. Install OpenPilot

Choose the release for your system:

• Windows: use OpenPilot-Setup.exe; a portable executable is also available on the releases page.
• macOS: there's a beta .dmg for both Apple Silicon and Intel Macs.
• Linux: there isn't an installer yet. Run the source with Git and Node.js 20 or later:

git clone https://github.com/ibmshaikh/OpenPilot.git
cd OpenPilot
npm install
npm start

The project's Windows and macOS builds are not code-signed. On Windows, SmartScreen may show a warning; the source instructions say to select More info, then Run anyway. On macOS, the documented workaround is to right-click the app and choose Open. These are platform security prompts you should understand before proceeding. Only install software from a source you trust, and check the project's release information if you're unsure.

Enter the connection details

Start with these values:

• Name: the identifier shown in LM Studio for the loaded model.
• Base URL: http://localhost:1234/v1, unless you changed the port.
• API key: LM Studio doesn't require one by default, so you can use a placeholder in OpenPilot. If you enabled authentication in LM Studio, enter the token you configured there instead.

After the connection works, you can add more models later in OpenPilot's Settings and switch per chat. That's a practical way to compare a smaller model versus a larger one without changing the rest of your workflow. Keep the test requests consistent - if you test different models on totally different tasks, it's hard to tell what's model-related and what's just the prompt.

Start in a folder you can recover

For your first test, pick a Git-tracked project or a disposable folder. That makes it easier to inspect what changed and roll back if needed. Avoid starting in an important directory with uncommitted changes you can't easily separate from the agent's edits.

A good first request is narrow and easy to verify. For example:

Look at package.json and add a Scripts section to README.md explaining each one.

This gives the agent a specific source file and a bounded documentation change. You can confirm the README scripts match the actual entries in package.json, then review the diff. That's a better test than asking the agent to "improve the whole codebase," because you can see whether it read the right file and made the expected small edit.

OpenPilot shows file reads, edits, and shell commands as cards. It also prompts you to approve or deny sensitive actions. Read those prompts and don't auto-approve by habit - the point of the interface is that you can see what the agent plans to do right before it matters.

Use the first task as a capability check

Don't treat one successful edit as proof that the model can handle every type of coding work. A simple documentation update tests basic file access and instruction-following, but it doesn't tell you how it'll do with debugging, architecture changes, or long runs of dependent steps.

A sensible progression looks like this:

1. Have the agent inspect a small, well-defined part of the project.
2. Ask for one focused change with a clear expected result.
3. Review the file edits and any command prompts.
4. Check the diff and run the relevant test or command yourself.
5. Move to a larger task only once the smaller workflow is predictable.

This isn't ceremony. It's the fastest way to figure out what the selected model does well before giving it a bigger job. If something goes wrong, a small diff also makes it easier to isolate whether the problem was the instruction, the context window, the model's behavior, or the project state.

Small models are better suited to focused work

Smaller local models can do well on bounded edits, but they're less reliable on long, multi-step chains. If your task spans many files or requires a sequence of decisions, split it into smaller requests. Aim for one clear outcome, inspect it, then decide what to do next.

If smaller tasks still exceed the model's limits, try a larger model if your computer can run it. That's not magic - bigger models can require more memory, and you still need to review what they generate. The goal is simply to match the model to the task and your hardware, not to assume that one size will be ideal everywhere.

Watch for repetition and incomplete work

OpenPilot currently has no loop guard, so the model can sometimes repeat itself. If it starts cycling - restating an action without making progress - stop the run and rephrase the request. Letting a loop continue usually wastes time and tokens.

Similarly, if the agent gets confused or stops halfway, it can be a context window issue. Check that before changing multiple other parts of your setup. Troubleshooting is easiest when you isolate one variable at a time: connection details, model loading, context capacity, then the task.

Treat agent permissions as part of the design

The agent works inside the folder you select and can run shell commands. That's why folder choice matters. For experiments, use a Git-tracked project or a disposable directory so changes stay inspectable, and approve sensitive actions only when you understand what they do.

The same goes for the human side: make sure you can recover your files before testing an agent on work that actually matters. Version control isn't about "AI needing a special process" - it's about making it easier to assess any automated change against a known baseline.

Account for release and telemetry limitations

Windows and macOS builds are unsigned, macOS is still in beta, and there's no Linux installer yet. Those details might be fine for a personal experiment, but they can be deal-breakers for a managed or production workflow. If you're evaluating this for a team, compare the distribution and support details to your organization's requirements before rolling it out.

Telemetry is enabled by default. The project says it collects anonymous information like app opens, feature and model usage, and token counts - not chats, files, paths, or keys. You can disable it during Getting Started or later in Settings → About. If you have a specific privacy requirement, verify the current settings and documentation rather than assuming "local inference" means "no data."

If you want a different local-model route, see the OpenPilot guide using Ollama. The best choice depends on your preferred model-serving workflow and how you want to manage models locally.