I built a local AI coding agent for VS Code in 4 days — here's how it works

Antoni Caimari Caldés — Fri, 06 Nov 2026 19:16:42 +0000

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.

The model proposes, the user authorizes, the host verifies

RAME Code separates three responsibilities:

The model reads project context and proposes actions, such as modifying files, executing permitted tools or searching the web.
The user reviews and approves actions that require authorization.
The host — the VS Code extension itself — validates permissions, executes approved actions and independently records their results.

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.

Approvals are bound to specific actions

RAME Code uses two elements when validating an approval:

A fresh action identifier, which prevents an old approval from being reused.
A digest calculated from the proposed action, including its relevant parameters and context.

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.

Preventing accidental overwrites

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.

Missions: tasks that survive a VS Code reload

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:

The Mission is marked as interrupted.
Previously started actions with unrecorded outcomes can be marked as uncertain.
Execution does not automatically continue.
The user explicitly decides whether to resume.
New actions still require the appropriate permissions.

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.

Versioned project memory with human approval

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.

Local-first AI

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:

Web searches require authorization before sending queries.
Optional cloud model escalation is disabled by default.
Requests to external services are subject to their corresponding controls.

Local inference does not mean that every optional operation is offline. I think making that distinction explicit is important.

What I learned from real testing

One of the first practical problems I encountered involved LM Studio.

With just-in-time model loading, 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.

Known limitations

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.

I'm looking for beta testers

If you work with local LLMs, I'd really appreciate your feedback.

Three tests would be especially useful:

Try your preferred local model. Does RAME connect correctly through your inference server? What hardware and context settings are you using?
Try a multi-file modification. Is the approval process clear? What information would you need before trusting a proposed change?
Interrupt and resume a Mission. Does the recovery process behave as you expect?

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.

Project links

Website, installation and demo: https://ramecode.com
Source code (Apache-2.0): https://github.com/caimari/rame-code
Bug reports and suggestions: https://github.com/caimari/rame-code/issues

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

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?

DEV Community: Antoni Caimari Caldés