fx-lan

August 23, 2026 · View on GitHub

fx-lan lets you run Vercel’s fx agent against your own OpenAI-compatible API. An OpenAI-compatible API is any HTTP server that implements /v1/models and /v1/chat/completions. LiteLLM, llama.cpp, vLLM, OpenRouter, and many local proxies all count.

fx-lan is a single compiled binary. It starts a localhost Gateway: a small HTTP server on this machine that speaks the protocol the fx agent expects. It translates each request into an OpenAI chat-completions call, then launches the official fx CLI for you.

fx CLI  →  127.0.0.1 (fx-lan Gateway)  →  OPENAI_BASE_URL/v1

What you need

Vercel’s fx agent, installed as the fx CLI (install: curl -fsSL https://fx.sh/setup.sh | bash)
An OpenAI-compatible API with /v1/models and /v1/chat/completions
To build from source: Go 1.22 or newer. A prebuilt fx-lan binary does not need Go.

Install

make builds fx-lan for the computer that runs it. macOS, Linux, and Windows are detected automatically. The output is bin/fx-lan, or bin/fx-lan.exe on Windows. There are no runtime libraries to install.

git clone https://github.com/agent2x0r/fx-lan.git
cd fx-lan
make

make is the same as make build. If make is not installed:

go build -o bin/fx-lan ./cmd/fx-lan

On Windows, use -o bin/fx-lan.exe. make only adds a few flags that keep the file smaller.

ln -sfn "$(pwd)/bin/fx-lan" ~/.local/bin/fx-lan

To run it from the repo without putting it on PATH, use bin/fx-lan.

Go can cross-compile other operating systems from one host, including fx-lan.exe, without a virtual machine:

make dist
make release

make dist writes the raw binaries into dist/. make release wraps each one in a package with the docs and an installer:

macOS: .tar.gz and a .dmg (the disk image is created with hdiutil when the release is built on macOS)
Linux: .tar.gz
Windows: .zip containing fx-lan.exe

On macOS or Linux, unpack the archive and run ./install.sh. On macOS the .dmg also has install.command for a double-click install. On Windows, unpack the .zip and run install.bat.

The installer copies fx-lan to a user-local bin directory (~/.local/bin on Unix, %LOCALAPPDATA%\fx-lan on Windows) and says so if PATH still needs a line. A virtual machine is only needed to run a binary for an OS you are not on. Compiling and packaging do not require one.

Config

Set these in your environment, or put them in ~/.config/fx-lan/env. That file is local to your machine and should not be committed.

export OPENAI_BASE_URL="http://127.0.0.1:4000/v1"
export OPENAI_API_KEY="sk-..."          # any non-empty string if the server ignores auth
export FX_MODEL="my-model"              # optional default
# export FX_ENABLE_THINKING=0           # optional; send enable_thinking false (useful for Qwen)

OPENAI_BASE_URL is the root of your OpenAI-compatible API. It usually ends in /v1.
OPENAI_API_KEY is the bearer token that API expects. If the server does not check auth, any non-empty string is enough.
FX_MODEL is an optional default model id for the fx agent when one is not chosen another way.
FX_ENABLE_THINKING is optional. Set it to 0 to send enable_thinking: false in the upstream request, which some Qwen-style servers need.

AI_GATEWAY_API_KEY is accepted as an alias for OPENAI_API_KEY. LITELLM_BASE is accepted as an alias for OPENAI_BASE_URL. On macOS, if no key is set in the environment, fx-lan will look for a Keychain item named FX_AI_GATEWAY_API_KEY.

Use

fx-lan is a wrapper around the fx CLI. With no arguments it opens the fx agent’s interactive session. Extra arguments are forwarded to fx unchanged, so the rest of that CLI works the same way.

fx-lan                  # interactive session
fx-lan models
fx-lan ask "hello"

fx-lan --serve [--port N] runs only the localhost Gateway and prints the bound port. That is useful if you want to point something at the translator without launching the fx CLI.

How it works

The fx agent sends model traffic to a Gateway, meaning an HTTP service that lists models and runs generation. fx-lan provides that Gateway on 127.0.0.1.

When you run fx-lan, it starts that server, points the fx agent at it with FX_GATEWAY_BASE_URL and FX_GATEWAY_CHAT_URL, and then runs the fx CLI.

The server has two jobs:

GET /coding-agent/v1/models is the fx agent’s model catalog. fx-lan answers it by calling your /v1/models endpoint.
POST /v3/ai/language-model is the fx agent’s generation endpoint (AI SDK language-model spec v4). fx-lan turns the body into a streaming /v1/chat/completions request, including tool calls, and converts the OpenAI SSE stream (server-sent events) back into the events the fx agent expects.

The conversion code is in internal/protocol. The binary uses the Go standard library only: no third-party modules.

This setup depends on the fx agent accepting a Gateway URL on 127.0.0.1. If that option goes away, fx-lan would need another way to sit in front of the model.

Why Go, not Zig

fx-lan is written in Go because the standard library already does HTTPS, JSON, and launching the fx CLI. That matters when OPENAI_BASE_URL is a remote API such as OpenRouter, not only a server on localhost.

Compared side by side:

Size: Zig wins. A Go binary lands around 6MB. A Zig build would likely be 0.5–2MB.
Network code: Go wins. HTTPS and streaming SSE are in the standard library.
Build: Both compile to one file. make (or go build) uses the OS and CPU of the machine that runs it.
Maintenance: Go wins for this Gateway. Zig would mean owning more of the HTTP and TLS stack, and that stack is less proven in front of Vercel’s fx agent.

The extra megabytes in the Go binary are almost all HTTP and TLS, not the protocol translator. The larger file keeps the network part boring and the interesting code small.

Development

go test ./...
make

The release number is 0.1.0 in internal/version/version.go. CHANGELOG.md and git tags (v0.1.0) use the same string. See docs/RELEASING.md for tagging and make release.