# ForgeCode: a terminal coding agent for engineers who want provider choice > ForgeCode is a Rust CLI that puts an AI pair programmer in your shell and lets you point it at Claude, GPT, Gemini, Grok, DeepSeek or any OpenRouter model. The interesting part is not the chat; it is the shell plugin and the provider layer. **tailcallhq/forgecode** — AI enabled pair programmer for Claude, GPT, O Series, Grok, Deepseek, Gemini and 300+ models - Repository: https://github.com/tailcallhq/forgecode - Website: https://forgecode.dev - Stars: 7,636 · Forks: 1,462 - Language: Rust - License: Apache-2.0 - Published: 2026-09-09 · Updated: 2026-09-09 · Language: en - Canonical page: https://hysenlabs.com/projects/tailcallhq-forgecode ## The problem ForgeCode targets: model lock-in in the terminal Most terminal coding agents are built around one vendor. You pick the tool, and the tool picks the model. If you want to compare Claude against GPT against a cheaper OpenRouter route on the same task, you usually end up installing two or three separate CLIs with different configuration formats and different approval prompts. ForgeCode is an attempt to separate the agent from the model. The README describes it as "a comprehensive coding agent that integrates AI capabilities with your development environment," and the repository topics list claude-3-7-sonnet, claude-4, grok, qwen, openai and open-router side by side. The audience is narrow and specific: developers who work in a terminal, who already hold API keys for more than one provider, and who want the same interface regardless of which model answers. The project is written in Rust and published under Apache-2.0. The workspace pins rust-version 1.94 and edition 2024 in Cargo.toml, so building from source requires a recent toolchain. The last push to the default branch was on 2026-09-07, and the most recent tagged release in the README is v2.13.21 from 2026-07-31. ## Three entry points: TUI, one-shot CLI and the ZSH colon prefix ForgeCode is not one program with one interaction model. The README splits it into three modes, and the split matters more than any single feature. Interactive mode is a terminal UI. Running forge with no arguments starts a persistent session where you type prompts and the agent replies in a conversational loop. This is where multi-step work happens, and it is the mode the usage examples assume: explaining an authentication flow, scaffolding a dark mode toggle, reviewing a file, or walking through a git conflict. One-shot CLI mode is for scripting. The README documents command-line options as a separate section but the excerpt does not enumerate the flags, so the exact invocation for a non-interactive run is not something I can state from this README. The third mode is the shell plugin, and it is the one that distinguishes ForgeCode from a plain chat wrapper. With the plugin loaded, a colon prefix turns shell input into agent input. The README's table of contents lists the capabilities under that prefix: agents, sending prompts, attaching files, conversation management, git integration, shell command tools, session and configuration, skills, customizing agent behavior, and semantic search over the workspace. There is also a shell-plugin directory in the repository root, which is consistent with the plugin being shipped as part of the repo rather than bolted on. That design is also the sharpest trade-off. A colon prefix that can run shell commands is convenient precisely because it is close to your filesystem. The README's own security claim is that a "restricted shell mode limits file system access and prevents unintended changes," which tells you the unrestricted mode exists and is presumably the default you have to think about. ## Installing ForgeCode and running a first prompt The README gives a single install line. It pipes a script from forgecode.dev into sh, so read the script first if that pattern bothers you. ```bash curl -fsSL https://forgecode.dev/cli | sh ``` On first run the README says Forge guides you through provider setup with an interactive login flow. You can also configure credentials before starting the agent: ```bash # Configure your provider credentials interactively forge provider login # Then start Forge forge ``` After forge provider login completes, running forge with no arguments opens the interactive TUI. The first thing you should see is a prompt where you can type a question about the current directory. The README's own first example is a codebase question rather than a code-generation request: ``` > Can you explain how the authentication system works in this codebase? ``` According to the README, Forge responds by analyzing the project structure, identifying authentication-related files, and explaining the relationships between components. That is a reasonable smoke test because it exercises file discovery without asking the agent to write anything. If the answer cites files that do not exist, the provider or the workspace root is misconfigured, not the model. The README also documents forge conversation resume for picking up an earlier session. The excerpt cuts off mid-sentence there, so treat the exact argument form as something to confirm with forge --help rather than something I can quote in full. ## What the repository layout says about the architecture The workspace is a Cargo workspace with members under crates/*, which is the normal shape for a Rust CLI that has grown beyond a single binary. The dependency list is more informative than the directory names. It includes aws-sdk-bedrockruntime, aws-config and aws-credential-types, so Bedrock is a first-class provider path rather than an afterthought. It includes reqwest, http and aws-smithy-runtime with tls-rustls, which is the HTTP and TLS stack you would expect for talking to several hosted APIs. Several dependencies point at the agent's local behavior rather than its network calls: grep-searcher and grep-regex for searching the workspace, ignore for respecting ignore files, glob, nom for parsing, and dissimilar for diffing. rustyline appears alongside console and nu-ansi-term, which fits an interactive line editor. The presence of posthog-rs and machineid-rs in the workspace dependencies is worth noting for anyone evaluating telemetry: those crates are commonly used for product analytics and stable machine identification. The README does not document what is sent, which is a gap you should close before deploying this in a regulated environment. There is a separate package.json at the root for forge-code-evals, a private TypeScript package whose scripts run benchmarks/cli.ts and several bounty synchronization scripts under .github/scripts/bounty. That is evaluation and repository automation, not the shipped agent. Do not confuse the two when reading the dependency list: the npm dependencies are for the eval harness, and the Rust crates are for the tool you install. ## Where ForgeCode is the wrong tool The README is explicit that ForgeCode lives in the terminal and the shell. There is no editor extension mentioned in the README, and the repository topics do not include an IDE integration. If your team's workflow is built around inline diffs in an editor panel, ForgeCode does not meet you there; you would be adding a second surface rather than replacing one. Configuration is a second boundary. Provider configuration, forge.yaml, environment variables, and MCP configuration are all documented as separate sections in the README, and the README marks environment variables as deprecated in favor of the credential flow. That is a migration you inherit. Anyone with a CI pipeline that exports provider keys as environment variables should expect to revisit it. The third limitation is the one the README states least clearly. A shell plugin that can attach files, run shell command tools and manage git is powerful, and the security section reduces to a single sentence about restricted shell mode. The README does not say whether restricted mode is the default, what it blocks, or how to verify it is active. Until you confirm that in forge.yaml and the plugin configuration, treat the agent as having the same filesystem reach as your shell. For a solo developer on a scratch branch that is fine. For a shared machine with production credentials in the environment, it is not. ## ForgeCode against a single-vendor agent like Claude Code The natural comparison is a vendor-tied terminal agent such as Claude Code, which the repository topics themselves reference with the phrase "open-source-claude-code." The difference is not the interface, since both are terminal-first conversational agents. The difference is where the model decision lives. With a single-vendor agent, the model is part of the product. Prompts, tool-calling behavior and context handling are tuned for one family, and you get whatever that vendor ships next. With ForgeCode, the provider is a configuration concern: the README lists OpenAI, Anthropic and other LLM providers as interchangeable, and the topics add OpenRouter, Qwen and Grok. You can move a task to a cheaper model when the expensive one is not earning its cost, or keep a local or regional provider for code that cannot leave a jurisdiction. That flexibility has a price. A multi-provider agent has to normalize tool-calling formats, context limits and streaming behavior across APIs that do not agree on any of them. The README's own framing, "zero configuration," refers to the credential flow, not to model behavior: switching providers will change how well the agent handles a given repository, and you will be the one measuring that. A single-vendor tool gives you one behavior to learn. ForgeCode gives you a control surface and the work of using it. ## Maintenance, licensing and what the CLA means for contributors ForgeCode is not archived, and the last push was on 2026-09-07, which is recent enough that the project is being worked on. Release cadence is tight: v2.13.21 on 2026-07-31, v2.13.20 on 2026-07-30, and v2.13.19 on 2026-07-24. Three releases in eight days suggests a patch-oriented rhythm, and renovate.json in the repository root suggests dependency updates are automated. The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you preserve notices and state changes. That is the standard permissive position and it does not require you to open your own code. Two repository-level details are worth flagging without offering legal advice: the README carries a CLA assistant badge, which means contributions are gated behind a contributor licence agreement, and the README links a Discord server and a support section. A CLA is common for projects that want to relicense or offer commercial terms later. If your organization's policy treats CLAs as a signal, read the agreement rather than the badge. Upgrade cost is the part the README cannot settle. The README does not document rollback, there is no migration guide in the excerpt, and the release notes are not included. With a version stream this dense, pinning a known-good version and reading the diff between tags is the only defensible upgrade path, and I cannot tell you from this README whether the project supports that. ## Conclusion Adopt ForgeCode if you already live in a terminal, want to switch between model providers without changing tools, and can accept a shell plugin that runs commands on your behalf. Do not adopt it if you need a GUI, an IDE panel, or a vendor with a published support contract; the repository is a community project with a CLA and no documented SLA. Before committing, verify that your provider credentials work through forge provider login, check whether the restricted shell mode is on by default in your configuration, and read forge.yaml to see what the agent is allowed to touch. ## FAQ ### How do I install ForgeCode? The README gives a single command, curl -fsSL https://forgecode.dev/cli | sh, which downloads and runs the installer script. After that, run forge provider login to configure credentials, then forge to start the interactive terminal UI. ### What is ForgeCode? ForgeCode is an AI-enabled pair programmer that runs in the terminal. The README describes it as a comprehensive coding agent that integrates AI capabilities with your development environment, and it supports Claude, GPT, Gemini, Grok, DeepSeek and other providers through a single interface. ### Is ForgeCode free? The source is published under Apache-2.0, so the tool itself carries no licence fee and can be used commercially. You still pay whichever model provider you configure through forge provider login, since the agent calls their APIs with your credentials. ### Is ForgeCode open source? Yes. The repository is public, the licence is Apache-2.0, and the README lists open-source as one of the stated reasons to use it. Contributions go through a CLA, according to the CLA assistant badge in the README. ### How do I use ForgeCode? Run forge with no arguments for the interactive TUI, or load the shell plugin and use the colon prefix to send prompts, attach files and manage conversations from your shell. The README also documents a one-shot CLI mode, but does not enumerate its flags in the excerpt. ### Is ForgeCode a good coding agent? That depends on the provider you configure, since ForgeCode normalizes tool-calling across many models rather than tuning for one. The README's own examples cover code understanding, refactoring, debugging and git conflict resolution, which is the scope to judge it against. ## Sources - [License: Apache-2.0](https://github.com/tailcallhq/forgecode/blob/main/LICENSE) - [Project website](https://forgecode.dev) - [README](https://github.com/tailcallhq/forgecode/blob/main/README.md) - [Releases](https://github.com/tailcallhq/forgecode/releases) - [tailcallhq/forgecode on GitHub](https://github.com/tailcallhq/forgecode) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tailcallhq-forgecode