Junie vs Aider: Which Agent Works Better with Local Models?

I have two candidates for the agent layer: Junie CLI and Aider.

Both fit the architecture I'm looking for. They run independently from the IDE, work with local models through Ollama, and provide access to the repository rather than limiting the AI to a chat window.

On paper, Junie looks closer to the autonomous agent I have in mind. Aider is more repository-centric and tightly integrated with Git.

Now I want to see what happens when I connect them to the same models.

To keep the comparison controlled, I start with a temporary Git repository rather than one of my real projects.

The first goal is simple:

Can the agent, Ollama, and local model communicate well enough to perform a basic task?

Starting with Junie

I start with Junie because its architecture is closer to the agent loop I'm trying to build.

For this experiment, I only need Junie CLI. I'm deliberately leaving its optional IntelliJ integration out so I can evaluate the command-line agent independently.

The installation is straightforward:

curl -fsSL https://junie.jetbrains.com/install.sh | bash

Then I verify it:

which junie
junie --version
junie --help

The version installed for my test is Junie CLI 26.9.7.

Connect Junie to Ollama

Before connecting anything, I verify Ollama:

ollama ps
curl http://localhost:11434/api/tags

Then I create an empty test repository:

mkdir -p ~/junie-test
cd ~/junie-test
git init
git commit --allow-empty -m "Initial commit"
junie

Inside Junie, I select:

Custom models and endpoints
        ↓
Ollama
        ↓
http://localhost:11434

Junie successfully discovered the models already installed through Ollama.

The first part of the connection worked:

Junie
  ↓
Ollama detected              ✅
  ↓
Models discovered            ✅
  ↓
Model selected               ✅

I start with Qwen2.5-Coder 7B, my default candidate from the standalone benchmarks.

Now comes the important part.

A deliberately boring test

I don't start by asking Junie to create an application or refactor some Java code.

The first prompt is intentionally harmless:

Explain what files currently exist in this project.
Do not create or modify any files.

This isn't really a coding test.

I'm checking whether the model can participate in Junie's agent protocol: receive the task, respond in the expected format, allow Junie to interpret that response, and reach whatever repository tools it needs.

Qwen 7B failed with:

The model returned an unexpected response format.
Try again or switch to a different model.

I tried it again and got the same result.

This is already different from the standalone model tests. Qwen can answer coding questions through Ollama without a problem, but in this test it couldn't produce what Junie expected from the agent interaction.

Try the other models

One failed model doesn't tell me much, so I keep everything else unchanged and switch models.

I test all four models from the earlier benchmark:

Model	Ollama detects it	Junie selects it	Basic Junie task
Qwen2.5-Coder 7B	✅	✅	🔴 Failed
Qwen2.5-Coder 14B	✅	✅	🔴 Failed
Ministral 3 8B	✅	✅	🔴 Failed
gpt-oss 20B	✅	✅	🔴 Failed

The Qwen models reported an unexpected response format.

Ministral and gpt-oss stopped with a more generic error:

The task was stopped due to an error. Try again.

None of the four models reached meaningful repository inspection or tool execution.

This result is particularly interesting for gpt-oss. It had the strongest standalone benchmark score of the four, but the additional reasoning capability didn't help it complete this basic Junie interaction.

The problem is no longer simply:

Is the model capable?

There is another compatibility layer:

Model capability
       +
Agent protocol
       =
Usable agent

Junie works with Ollama, but the models don't reach the agent loop

I want to be careful about what these results prove.

The connection itself worked. Junie discovered Ollama and the installed models, and I could select each one.

The failure happened afterward:

Junie
  ↓
Ollama                     ✅
  ↓
Model discovery            ✅
  ↓
Model selection            ✅
  ↓
Model response             ?
  ↓
Junie agent protocol       🔴
  ↓
Repository tools           ❌ Not reached

I can't conclude from these tests that Junie is a bad agent, or that these models are incapable of agentic coding.

I can conclude something much narrower:

Junie + Ollama is not a viable configuration with these four models in my current setup.

I could spend more time changing the configuration, looking for another model, or troubleshooting Junie-specific behavior.

But I have another harness waiting.

I'll test the same runtime and model through Aider instead. If the model gets further there, I'll have a much more useful data point than I would get from continuing to troubleshoot Junie.

Install Aider

Aider is a Python application, and I don't want its dependencies mixed into the Python installation used by the rest of my system.

The preferred installation path creates an isolated environment:

python3 -m pip install aider-install
aider-install

In my case, the existing Homebrew Python setup got in the way, so I used Aider's isolated shell installer instead:

curl -LsSf https://aider.chat/install.sh | sh

Then I verify the installation:

which aider
aider --version
aider --help

The installed version for this experiment is:

Aider 0.86.2

Now I have the second harness ready without changing Ollama or any of the models.

Connect Aider to the same Qwen model

I verify Ollama again:

ollama ps
curl http://127.0.0.1:11434/api/tags

Then I configure the endpoint only for the current terminal session:

export OLLAMA_API_BASE=http://127.0.0.1:11434

Aider addresses Ollama models using the ollama_chat/ prefix, so I launch it with:

aider \
  --model ollama_chat/qwen2.5-coder:7b \
  --no-auto-commits \
  --no-dirty-commits

The last two options are important for my workflow.

Aider normally has strong Git automation, including automatic commits. I want the agent to make changes while I retain control of the commit:

So automatic commits stay disabled.

The same model gets through Aider

I start with the same conceptual test:

Explain what files currently exist in this project.
Do not create or modify any files.

This time, Qwen responded normally.

Aider reported:

Tokens: 608 sent, 39 received.

There was no unexpected response format and no agent protocol error.

The complete path worked:

Aider → Ollama → Qwen2.5-Coder 7B → Model response → Aider

The repository was empty, so there wasn't much for Qwen to inspect yet. But the test answered the first question.

The exact same Qwen model that couldn't complete the basic Junie interaction successfully communicated through Aider.

Agent-harness compatibility is already affecting the result.

Give Aider something to discover

Communication alone isn't enough. Now I need to know whether Aider can provide useful repository context without me manually attaching every file.

I add two tiny Java classes.

Calculator.java:

public class Calculator {

    public int add(int first, int second) {
        return first + second;
    }

    public int multiply(int first, int second) {
        return first * second;
    }
}

GreetingService.java:

public class GreetingService {

    public String greet(String name) {
        return "Hello, " + name + "!";
    }
}

Then I commit them so Aider has a clean Git repository to inspect:

git add .gitignore Calculator.java GreetingService.java
git commit -m "Add Aider context test files"
git status

I restart Aider without manually adding either Java file:

aider \
  --model ollama_chat/qwen2.5-coder:7b \
  --no-auto-commits \
  --no-dirty-commits

I want to test Aider's automatic repository context rather than help the model by selecting the exact files it needs.

Can Qwen understand the repository?

The first prompt asks for repository discovery:

What Java classes exist in this repository?
For each class, list its methods and briefly explain what each method does.
Do not modify any files.

Qwen found both classes.

Good.

It also told me that Calculator contained subtract and divide.

It didn't.

The actual class contained only:

add
multiply

So the result was mixed:

Repository awareness    ✅
Exact understanding     ⚠️
Hallucination           🔴

Aider successfully gave the model enough context to know which classes existed, but the model still filled gaps with plausible-looking methods.

This is exactly the kind of error I care about for agentic coding. subtract() and divide() sound perfectly reasonable inside a class named Calculator.

Plausible isn't the same as present in the code.

Exact implementation works better

The next prompt is narrower:

What exact string format does GreetingService.greet return?
Give one example for the name "Jeison".
Do not modify any files.

Qwen correctly identified:

Hello, Jeison!

So it clearly had useful information from the repository.

But something else happened: the response was interpreted as edit-oriented output, and Aider asked for permission to make a change.

I rejected it.

No unwanted modification reached the repository.

The model understood the implementation but didn't reliably stay inside my read-only instruction.

One more dependency test

I try a relationship question:

Does GreetingService depend on Calculator,
or does Calculator depend on GreetingService?

Explain based only on the repository code.
Do not modify any files.

Qwen correctly determined that neither class depended on the other.

Then it again produced unnecessary edit output, including an attempted addition of a divide method to Calculator.

I rejected the change.

The three tests produced an interesting result:

Test	Reasoning	Behavior
Repository discovery	⚠️ Found classes but hallucinated methods	No useful edit needed
Exact implementation	✅ Correct	⚠️ Attempted unnecessary edit
Dependency reasoning	✅ Correct	🔴 Proposed unrelated code
Repository awareness	✅ Worked	Context supplied automatically
Read-only instruction	🔴 Unreliable	Model tried to edit
Edit protection	✅ Worked	Aider let me reject changes

The harness solved one problem and exposed another.

Safety controls suddenly stop being theoretical

When I defined the agent requirements, permission controls were mostly architectural.

Now they have a very concrete purpose.

Qwen received:

Do not modify any files.

and still produced output that could lead to a modification.

Aider stopped the process and asked before changing files that hadn't been explicitly added for editing.

I said no.

The repository stayed unchanged.

The permission boundary compensated for the model's behavior.

This gives me a useful way to think about agent safety:

Model instruction following
          ↓
      first defense

Agent permissions
          ↓
      second defense

Git diff + human review
          ↓
       final defense

I don't want the safety of the workflow to depend entirely on the model remembering every instruction.

Junie vs Aider in this setup

At this point, the comparison is much simpler than I expected.

Result	Junie CLI	Aider
Installation	✅	✅
Ollama connection	✅	✅
Local model discovery/configuration	✅	✅
Qwen 7B communication	🔴 Failed agent protocol	✅ Worked
Repository context	❌ Not reached	✅ Worked automatically
Read-only reasoning	❌ Not reached	⚠️ Model attempted edits
Permission protection	❌ Not reached	✅ Prevented unwanted changes
Useful local setup	🔴 Not with tested models	🟢 Technically viable

Junie is still closer to the autonomous agent architecture I originally imagined.

But architecture on paper isn't enough.

With the models my M2 can realistically run, Junie never reached the useful part of the agent loop.

Aider did.

The harness matters more than I expected

Before this comparison, the model looked like the main variable:

Better model
    ↓
Better agent

The results made that picture incomplete.

A more realistic model is:

        Model
          +
        Harness
          +
        Context
          +
    Tool protocol
          +
      Permissions
          ↓
    Agent behavior

Qwen2.5-Coder 7B is the clearest example.

Through Junie, the experiment produced:

Qwen 7B
   ↓
protocol failure
   ↓
no useful agent task

Through Aider, it produced:

Qwen 7B
   ↓
repository context
   ↓
useful reasoning
   ↓
hallucinations / unwanted edits
   ↓
permission boundary

Aider didn't suddenly make Qwen reliable. The hallucinated methods and ignored read-only instructions are warning signs.

But it gave the model a working path to the repository, and it gave me enough control to stop some of its mistakes.

For the current M2/16 GB setup, Aider is the agent layer worth carrying into the next stage of the experiment.

The next question is harder.

Connecting a model to a repository is one thing. Giving it permission to actually change code, run commands, see failures, and try again will move the experiment much closer to the agent loop I'm trying to build.