I turned part of LAMA into a public npm package

A few days ago, LAMA was mostly a machine.

An M1 Pro running Ollama. A Qwen model loaded into memory. Another Mac calling it across my local network.

Once that worked, the next problem appeared pretty quickly: how should an application actually talk to it?

Calling an Ollama endpoint isn't difficult. But a real application needs more than a fetch.

It needs configuration validation. Timeouts. Cancellation. Useful errors. Token counts. Latency measurements. A distinction between "the server is unreachable" and "the model returned nothing."

And if I built another application, I was going to need all of that again.

So I pulled that layer out of LAMA.

I called it Forge.

The layer in the middle

The architecture is intentionally boring:

Application → Forge → local AI runtime → model

Forge doesn't try to be the model.

It isn't an agent framework, a memory system or a prompt library either.

It's the reusable boundary in the middle.

An application gives Forge a host, a model and a prompt. Forge handles the conversation with the local runtime and gives the application back a predictable result, or a predictable failure.

Right now the supported runtime is Ollama.

That narrow scope is deliberate.

I'd rather understand one small piece properly than immediately turn it into a framework.

Then it became a real package

Until now, Forge was infrastructure for my own local AI experiments.

This week it crossed a line that matters to me: someone else can install it.

npm install forge-local-ai-kit

It works as a TypeScript library, but it also installs a forge command.

With Ollama running and a model already available:

export OLLAMA_HOST="http://localhost:11434"
export FORGE_MODEL="qwen3:8b"

npx forge ask "Explain why local AI is interesting."

Forge is ESM-only, requires Node.js 22 or newer, and has zero production dependencies.

The package doesn't install Ollama, download models or decide how an application should use AI. Those boundaries belong somewhere else.

Forge just makes the connection reliable.

The milestone isn't really npm

Publishing a package is not particularly exotic.

What matters to me is what changed in the architecture.

LAMA started as:

Mac → Ollama → Qwen

Then another machine became a client.

Then applications needed a stable way to reach the model.

Now one of those pieces has become independent enough to live outside LAMA itself.

That's the part I like.

Something that began because my machine needed it is now small enough, documented enough and isolated enough that another developer can use it without knowing anything about my setup.

That feels like a much better test of an abstraction than drawing another box on an architecture diagram.

Local should still mean local

Forge doesn't send prompts anywhere except the host you configure.

There is no analytics service, telemetry pipeline or hosted Forge backend sitting in the middle.

If Ollama is running on the same computer, the request stays there.

If it's running on another machine on your LAN, it travels there.

That's it.

The application still decides what the model is for. Forge only provides the road to get there.

What's next

I'm still building LAMA from the bottom up.

Forge is one piece of that system, not the system itself.

There are plenty of interesting layers still ahead: interfaces, model selection, files, memory, tools and eventually agents.

But I don't want to jump straight to the flashy parts.

One of the things I'm enjoying about building local AI this way is being forced to understand where every boundary actually belongs.

First the machine became a server.

Now the connection to that server became a package.

Small step.

Pretty satisfying milestone.

Forge on GitHub: https://github.com/rikilamadrid/forge

Forge on npm: https://www.npmjs.com/package/forge-local-ai-kit

Forge is open source under the MIT license.

🔥 Running locally. Built by Lamadrid.