During Meta's Global AI Developer Hackathon, I spent roughly four intensive days building RAME Code, a free, Apache-2.0 open-source AI coding agent for Visual Studio Code.
It runs Meta Muse Glimmer 30B locally, through compatible inference servers such as LM Studio, Ollama and llama.cpp.
There are already plenty of AI coding agents. I wanted to explore a more specific question:
What if the model never gets the final word — not on what runs, not on what's remembered, and not on whether a task is actually finished?
RAME Code v0.2.0 is available now. It's experimental, has known limitations, and I'm looking for developers willing to test it with their own local models.
Here's how it works, what I've learned, and what still needs improvement.
RAME Code separates three responsibilities:
The last part is particularly important.
When a task finishes, RAME can display a record labelled:
"Host record — verified by RAME Code, not written by the model"
The idea is simple: a model saying "I've completed the task" is not sufficient evidence that the requested changes actually happened.
RAME Code uses two elements when validating an approval:
The digest ties an approval to the proposed operation. The identifier distinguishes individual approval requests, including repeated proposals of an otherwise identical action.
If the proposed action changes, the previous approval cannot authorize the modified action. Pending approvals are also invalidated when relevant execution conditions change.
This is an example of something I believe should be enforced by software rather than relying exclusively on instructions to the model.
Before modifying an existing file, the agent must read its contents.
A proposed patch includes the expected SHA-256 hash of the file. Before applying the change, RAME calculates the current hash again.
If another application, developer or process modified that file in the meantime, the patch is rejected. RAME also includes rollback handling for multi-file patches. If a write or post-write verification fails, it attempts to restore the original files.
This is not a substitute for Git, filesystem snapshots or a fully isolated execution environment.
Some sensitive paths are excluded from the agent's file tools, including Git internals, common credential locations and private key files.
Longer coding tasks can be organized into Missions.
A Mission contains a plan, bounded execution steps and checkpoints managed by the extension.
If VS Code reloads during execution: This matters because an interrupted operation should not simply be repeated when its previous outcome is unknown.
I've also been testing interruption and permission-denial scenarios to improve the recovery behavior in the next release.
RAME Code includes a system for storing project decisions.
For example, a project might contain an approved decision such as:
shipping.free_threshold_eur = 60
The model can propose a new decision, but it cannot independently turn that proposal into authorized project knowledge.
Only the user can approve changes to project decisions.
The system maintains a version history, and proposals refer to the version they expect to modify. This helps reject outdated updates.
Decisions can also be associated with project files and verification results, allowing RAME to identify certain relationships that become stale when a decision changes.
There are still important challenges to solve, including detecting contradictions between different approved decisions and marking existing decisions as disputed while corrections are pending.
These are areas I'm actively researching.
The coding agent can run using a local model through compatible inference servers.
RAME also supports optional capabilities that communicate with external services, but these are separate from local inference.
For example: Local inference does not mean that every optional operation is offline. I think making that distinction explicit is important.
One of the first practical problems I encountered involved LM Studio.
With just-in-time model , LM Studio can initialize a model using a default context window of 4,096 tokens.
For some agent tasks, the tools and project context alone exceeded that limit, resulting in an HTTP 400 error. The immediate workaround was to configure a larger default context window in LM Studio.
I'm preparing improvements so that RAME can explain these failures more clearly and help users correct the configuration.
It's a good reminder that local models behave differently depending on hardware, inference software, context limits and model settings.
RAME Code v0.2.0 was developed quickly, and there are several things I want to improve.
No proper diff in approval cards yet.
Currently, a file modification card shows the proposed new content rather than a dedicated before-and-after diff. Large content may be truncated.
A proper diff viewer is one of my highest priorities.
No one-click undo for completed changes.
RAME includes recovery handling for certain failed patches, but it does not yet provide a convenient way to undo an already approved and successfully applied change.
For now, Git or VS Code's local history remains important. No operating-system sandbox.
Allowlisted tools execute with the permissions of the host environment. The current permission system should not be treated as a complete security boundary against untrusted code.
Local model compatibility needs broader testing.
I've primarily tested RAME on my own Windows and Linux environments, including local and Remote SSH setups.
Different hardware configurations, operating systems and inference servers need more coverage.
Large projects need more evaluation.
Long-running tasks, context management and reliability on larger codebases remain important areas for improvement.
If you work with local LLMs, I'd really appreciate your feedback. Three tests would be especially useful:
Please use a disposable test project, not an important production repository.
I'm particularly interested in unexpected behavior, usability problems, failed tool calls and differences between local model configurations.
RAME Code was created during Meta's Global AI Developer Hackathon 2026.
If you'd like to see the original hackathon announcement, it's available here:
[https://x.com/caimaricaldes/status/2118144184733282470](https://x.com/caimaricaldes/status/2118144184733282470)
I'm an independent developer from Mallorca, Spain, and this project is still at an early stage.
I would genuinely appreciate constructive criticism, especially from people building or using local AI coding agents.
What would you improve first: the approval interface, recovery from interrupted tasks, model compatibility or project memory?