fx Coding Agent
A small native coding agent for terminal workflows and embedded applications.
Per-dimension scores and reasoning
Workflows default to contents:read, pin some actions to commits, and validate downloaded artifact provenance, status, size, and commit relationships. The license, third-party notice path, and sound credit make source attribution strong. These are mostly build-infrastructure controls, however, and do not establish least privilege for the agent runtime. The README links to permission documentation but does not show tool-call confirmation rules, filesystem or command scopes, provider data flows, or OAuth/API-key storage and deletion. The agent can modify code and supports MCP, skills, and subagents, yet the supplied files do not explain control of external effects or recovery. Confirmation, transparency, sensitive-data handling, and external-effects scores are therefore thin, and rollback is absent. No red-line behavior is evidenced.
README installation, build, Zig-version, and test instructions are broadly consistent with the workflows. CI covers multiple architectures, startup performance, memory, native/WASM bridges, and artifact identity checks. Some dependencies and tools are precisely versioned, while other actions use moving major tags and installation relies on remote downloads, so availability is not fully controlled. PGSO tests show useful rejection messages for missing parameters, stale output, wrong runtime versions, and incomplete evidence, and the driver records failure stages and errors. Those tests concern an auxiliary optimization pipeline rather than the core interactive agent, preventing full marks for failure messaging.
The README clearly addresses interactive-shell, scripted ask, ACP, JavaScript/WASM embedding, browser, and framework scenarios. It supports gateways, subscription accounts, local models, and OpenAI-compatible endpoints, providing thorough audience and scenario coverage. Commands, environment variables, configuration precedence, and gateway-only routing conditions make triggers precise. Experimental labels establish some boundaries, but the supplied material does not comprehensively enumerate unsupported operations, model differences, or MCP/subagent limits. CI supports Linux, macOS, multiple architectures, Node, and Bun, while Windows, terminal prerequisites, and a complete compatibility matrix are not shown.
The README has clear sections for installation, onboarding, providers, themes, embedding, source builds, security, and licensing. Commands and configuration names appear stable and numerous copyable examples are present. Installation is concise, but the piped curl installer lacks documented verification, uninstall, or version-pinning instructions in the supplied material, and no FAQ is included. Experimental status is disclosed, though concrete known issues are sparse. The full Apache-2.0 text, copyright notice, and third-party attribution path justify full license marks. A release badge exists, but no changelog or compatibility policy is supplied. Vercel Labs labeling, a security contact, and a contribution-guide reference indicate an update path, while the publisher remains unverified and no named maintainers or support commitment are shown.
The product offers interactive, one-shot, and embedded output surfaces and explicitly preserves terminal scrollback. Benchmark workflows gate latency, memory, capacity, and binary-size behavior, showing attention to usability and operating cost. A small native, model-agnostic agent with several host surfaces offers plausible marginal value. However, the supplied evidence contains no benchmark results, task-quality evaluation, monetary cost figures, or substantial output examples, and the product is explicitly experimental. Output usability, marginal value, and cost-benefit are therefore adequate but not thoroughly demonstrated.
Major claims map to concrete commands, configuration examples, build steps, and workflow checks. README, license, tests, and CI corroborate the Zig requirement, ReleaseSafe builds, runtime surfaces, and attribution. Workflows retain JSON reports, logs, samples, and commit-identity artifacts, supporting traceability. Still, the supplied evidence omits the core agent implementation, linked manual contents, release results, and actual benchmark data, so promotional claims such as “tiny,” “any model,” and a complete manual are only partly checkable. Facts, examples, and experimental warnings are generally separated, but measured findings versus inference are not systematically labeled.
- The product is explicitly experimental. Before using it on a real repository, separately verify approval behavior, command scope, file-mutation policy, and failure recovery.
- Login uses OAuth or API keys, but the supplied material does not describe credential storage, encryption, log redaction, revocation, or deletion.
- The one-line curl-pipe installer depends on a remote script; review and pin the installer or release artifact and verify integrity before deployment.
- Model requests may pass through Vercel AI Gateway, OpenAI, xAI, OpenRouter, or another custom endpoint. Confirm retention and privacy boundaries for the selected provider.
- The core agent source, permission-manual content, and actual benchmark results are not supplied, so this review does not establish runtime safety, task correctness, or claimed performance.
What does this agent do, and when should you use it?
fx is an experimental coding-agent CLI written in Zig and distributed as a small native binary under Apache-2.0. It offers an interactive shell and the one-shot `fx ask` command, with inline output that preserves terminal scrollback. Its model layer can use Vercel AI Gateway, ChatGPT or Grok subscriptions, plus OpenAI Chat Completions-compatible services such as Ollama and OpenRouter. Beyond the standalone CLI, the repository exposes `fx acp`, the WebAssembly-based `createFxAgent()` and `createFxTerminal()` APIs, and the npm package `libfx`. An embedding application can supply transport, session storage, configuration, permission handling, and terminal I/O, making fx relevant to teams building their own agent host, although both the overall project and its WebAssembly SDK are explicitly experimental.
From a project directory, users can launch fx, submit coding requests in its interactive shell, and inspect available interactive commands with /help; scripts can instead invoke fx ask "explain the changes in this repository" for a single request. fx sends the request through the selected model connection—Vercel AI Gateway, a ChatGPT subscription authenticated by fx login codex, a Grok subscription, or a named OpenAI Chat Completions-compatible endpoint—and renders the result inline in the terminal. Custom connections live in ~/.fx/settings.json, while fx provider, FX_PROVIDER, and FX_MODEL select the provider and model. For embedding, fx acp connects the native agent to editors and other Agent Client Protocol clients; createFxAgent() embeds the core through fx-core.wasm, and createFxTerminal() embeds the interactive terminal through fx-term.wasm. Skills, MCP servers, and subagents are supported as extensions, but MCP is not documented as a prerequisite for basic operation.
- A developer who wants to issue coding requests from a project directory through a Unix-shell-like interface while retaining normal terminal scrollback.
- An engineering team that needs a one-shot
fx askcommand in scripts or automation to request an explanation of repository changes. - A team already operating Ollama, OpenRouter, or another OpenAI-compatible endpoint that wants to reuse its existing model connection.
- A developer building an editor or ACP client who wants to connect to the native agent through
fx acp. - A product team embedding an agent core or interactive terminal into a Node.js, browser, Next.js, or Nuxt application with
libfx.
What are this agent's strengths and limitations?
- One agent exposes an interactive shell, scriptable
fx ask, ACP connectivity, and WebAssembly embedding instead of limiting users to one interface. - Model selection spans Vercel AI Gateway, ChatGPT, Grok, and custom OpenAI-compatible endpoints, with Ollama and OpenRouter explicitly named.
- The Zig implementation builds as either a native binary or WebAssembly, and an embedding host can provide its own transport, storage, permissions, and terminal I/O.
- Inline rendering preserves terminal scrollback and offers a shell-oriented workflow rather than a full-screen terminal IDE.
- The project explicitly labels itself experimental and warns users to proceed at their own risk, so production stability should not be assumed.
- The WebAssembly SDK is also experimental, creating interface and behavior-change risk for applications built on
libfx. - Source builds require Zig 0.16.0 or newer, adding a toolchain requirement for teams that do not already use Zig.
- Remote-model paths require the relevant subscription, OAuth login, or API key; pricing, quotas, network-failure behavior, and offline guarantees are not documented in the supplied material.
- Custom connections are specifically described for OpenAI Chat Completions-compatible endpoints; direct support for other API protocols is not evidenced.
How do you install or deploy this agent?
Install the prebuilt distribution with:
curl -fsSL https://fx.sh/setup.sh | bashTo build from source, install Zig 0.16.0 or newer, then run:
git clone https://github.com/vercel-labs/fx.git
cd fx
zig build -Doptimize=ReleaseSafe
./zig-out/bin/fxRun the test suite with zig build test. The supplied material does not enumerate the operating systems, CPU architectures, or other system dependencies supported by the setup script.
How do you use this agent?
First configure one authentication or connection path: run fx login for Vercel AI Gateway, fx login codex for a ChatGPT subscription through OpenAI Codex OAuth, fx login grok for a Grok subscription, or fx setup to enter an AI Gateway API key.
Start an interactive session from a project:
cd your_project
fxRun /help inside the shell to browse interactive commands. For a one-shot request, use:
fx ask "explain the changes in this repository"For a custom OpenAI Chat Completions-compatible service, add a named connection to ~/.fx/settings.json, then select it:
fx provider localA provider and model can also be scoped to one invocation:
FX_PROVIDER=openrouter FX_MODEL=openai/gpt-4.1 fx ask "review this change"FAQ
Does fx itself cost money to use?
Is it locked to one model provider?
FX_PROVIDER and FX_MODEL.What permissions does it require?
Can it be embedded in an existing application?
libfx npm package exposes createFxAgent() and createFxTerminal(), and ACP provides another integration surface. The WebAssembly SDK is currently experimental.