I wanted to use Meta's Muse Glimmer as a local agentic engineering assistant inside OpenCode.
Not as a chatbot in a browser. I wanted an agent that could inspect a repository, understand a task, edit files, run tests, and explain what it did.
The command was refreshingly short:
ollama launch opencode --model muse-glimmer
The model, however, is a 30-billion-parameter coworker who arrives carrying an approximately 18 GB suitcase and expects a 128K-context office.
The onboarding meeting
First, I checked Ollama:
ollama --version
Then I started the local service if needed:
ollama serve
I verified that the local API was alive:
curl http://localhost:11434/api/version
Then I launched OpenCode with Muse Glimmer:
ollama launch opencode --model muse-glimmer
The first run downloads the model. This is a good opportunity to make coffee, reconsider your disk space, and remember that “local AI” does not mean “tiny AI.”
To inspect installed models:
ollama ls
On Apple Silicon, Ollama also lists an MLX variant:
ollama launch opencode --model muse-glimmer:30b-mlx
The standard model is listed at around 18 GB. That is the model's luggage, not the entire hotel bill. Leave memory for the context, OpenCode, the operating system, and the repository you are asking the agent to understand.
Why OpenCode changes the experiment
The interesting part is not just running Muse Glimmer locally. It is putting the model inside an engineering workflow.
With OpenCode, I can ask the agent to:
- Inspect the repository.
- Find the relevant files.
- Explain the current behavior.
- Propose a plan.
- Make a focused change.
- Run the project's tests.
- Read failures.
- Revise the patch.
- Show the final diff and verification result.
That is the difference between asking a model for code and asking an agent to help complete an engineering task. The model can still be confidently wrong. The workflow gives me more chances to catch it before the wrongness becomes a pull request.
The first repository tour
I opened the repository in OpenCode and started with a read-only request:
You are working in a local software repository. Inspect the project structure and identify:
- The application entry point
- The test command
- The main source directories
- Configuration files that affect development
- Any obvious contribution or safety constraints
Do not modify files. Report the evidence and ask before making changes.
This is a better first task than “fix everything.” It tests whether Muse Glimmer can build context without immediately turning the repository into modern art.
The key signal is whether the response points to actual files and commands. A useful agent should report evidence, not invent a project architecture because the folder name sounded familiar.
The first engineering task
After the repository tour, I gave OpenCode a small, testable issue:
Find the bug in the relevant average function. Explain the edge case, propose the smallest fix, and add a regression test. Do not change unrelated files.
The current implementation is: average(values) = sum(values) / len(values) + 1
The extra + 1 is suspicious. It is the kind of bug that enters production wearing sunglasses and saying, “Nobody will notice.”
A good OpenCode session should locate the real implementation, find the project's existing test style, make the smallest patch, and run the relevant test. A locally generated patch is still a patch. It needs review, tests, and version control like any other change.
Planning before editing
I asked OpenCode to separate investigation from implementation:
Before editing, write a short implementation plan with:
- Files you expect to inspect
- The behavior you expect to change
- The test you will add or update
- The command you will run to verify the change
Wait for approval before modifying files.
This creates a useful checkpoint. It also prevents the classic coding-agent experience where you ask for one small fix and receive a surprise framework migration, a new abstraction layer, and a README poem.
OpenCode is the interface where this loop becomes practical: inspect the plan, approve the direction, watch the diff, and ask for verification in the same engineering session.
The test-and-repair loop
The useful workflow looks like this:
Inspect -> plan -> approve -> edit -> test -> inspect failure -> revise -> test again
I tested failure recovery with an intentionally broken test result:
The test runner returned:
ERROR: assertion failed in tests/test_average.py
Expected: 2.0
Received: 3.0
Explain the failure, identify the likely cause, and propose the smallest correction. Do not edit files yet.
Then I tested a repository constraint:
The repository check returned:
ERROR: the generated lockfile differs from the committed lockfile.
Do not regenerate dependencies. Explain what should be reviewed first.
The goal is not to make the agent retry everything until the terminal turns green. The goal is to see whether it can distinguish a fixable implementation error from a situation requiring human review.
“The model usually behaves” is not an engineering control. It is something you say immediately before opening an incident ticket.
Screenshot-driven debugging
Muse Glimmer supports image input, which is useful for UI bugs, screenshots, diagrams, and terminal output. From the local OpenCode workflow, I can give the agent a screenshot and ask for evidence-first analysis:
Inspect this screenshot as a debugging artifact. List only visible symptoms, separate observations from hypotheses, and suggest which source files or browser checks should be inspected next.
“The button is clipped” is an observation. “The CSS grid is broken because of a missing min-width” is a hypothesis. That distinction saves time and prevents a screenshot from becoming a license to rewrite the frontend.
Conclusion
Using Muse Glimmer with OpenCode through Ollama is straightforward to start:
ollama launch opencode --model muse-glimmer
The interesting work begins after OpenCode starts. Ask the agent to inspect, plan, edit, test, diagnose, and explain.
Muse Glimmer can be the clever local coworker. Ollama handles the model runtime. OpenCode handles the engineering conversation. You remain the person who decides whether the patch deserves to live.
Resources:
