Ten launchers put one model catalog behind coding agents
FCC supplies launch commands for 10 coding agents: Claude Code, Codex, Pi, OpenCode, Cline, Hermes, DeepSeek Harness, Grok Build, Muse Code, and Aider. The server gives them one catalog of hosted, subscription, free-tier, and local models. Its Admin UI controls the default model, Claude tier mappings, reasoning level, and ordered fallbacks. The useful trick is preserving a familiar coding client while changing where its inference runs.
Local choices include LM Studio, llama.cpp, and Ollama, each reached through an OpenAI-compatible endpoint. Hosted choices use several credential patterns: one API key for many providers, account connections for OpenAI and GitHub Copilot, application-default credentials for Vertex AI, and both an account ID and token for Cloudflare. FCC gathers those differences in one interface, though each upstream service keeps its own billing and data terms.
Fifty providers still leave price and quota outside FCC
The README lists 50 providers and says free tiers together can supply more than 1.3 billion tokens per month. That is the project's claim, not a capacity figure we measured. The same README gives the necessary warning: each provider controls availability and limits, which may change. FCC can search the catalog and map Claude tiers to different models, but it cannot guarantee that a free endpoint remains available tomorrow.
Fallbacks help with outages and exhausted quotas. After retries, FCC can send the request to the next configured model, and one request may consume usage from several providers before succeeding. Open issue 1025 describes waits longer than 20 minutes before an error or response for one user's Claude Code and Codex setup. That report is anecdotal, yet it shows why buyers should test timeout behavior and error visibility on every provider they plan to use.
What happened when we ran it
Our sandbox installed commit e508efa in 28 seconds, pulling 103 Python packages and occupying 140 MB on disk. The build completed successfully in 6 seconds. We ran the project on August 24, 2026, in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Those results describe that commit and environment.
The test step failed with exit 4 after 11 seconds. pytest read pyproject.toml, rejected the configured -n argument, and stopped at the repository root. The log has no passed or failed test count because collection never began. It also does not say why that option was unavailable, so claiming a missing plugin or a broken test would go beyond the evidence.
pip-audit reported 0 known vulnerabilities in the 103 installed packages. The checkout contained 574 files, roughly 137,344 source lines, and used 6.6 MB before installation. We found 3 CI workflow files and a tests directory, but no Dockerfile. A quick install and successful build make a trial easy; the test runner result leaves the assertions unverified in our stated sandbox.
Python 3.14 and no Dockerfile narrow deployment choices
Current version 6.2.1 requires Python 3.14.0 or newer and uv 0.11.16 or newer. The development guide tells contributors to run through uv instead of a global interpreter. Our older measured commit installed in a Python 3.12 image, but that result does not override the current requirement. A team standardized on an earlier Python must add a separate runtime or choose another gateway.
The supported user path is an installer script for macOS and Linux or a PowerShell script block on Windows. Both are linked for inspection before execution. Linux users keep fcc-server running in a terminal; Windows and macOS receive a desktop launcher. The measured repository had no Dockerfile, and the current contributing guide explicitly rejects Docker integration pull requests. Container packaging is therefore work you own outside the accepted contribution path.
Optional proxy authentication matters before remote use
The client examples point Claude Code and Codex at a local proxy on port 8082, and the README tells users to enable bearer-token authentication if they want to protect it. Treat that switch as required before another machine or user can reach the service. The gateway holds provider credentials and can forward coding-agent requests, so a convenient shared endpoint has a larger consequence than an exposed model picker.
Discord and Telegram extend the same agent beyond the workstation. Their setup asks for bot credentials, allowed channels or a user ID, and an absolute allowed directory. Discord also needs message-history and Manage Messages permissions for clearing prompts. Open issue 801 reports a Windows conflict where changing the main server port does not move the Admin UI from 8082. Verify the bind behavior on the exact build before depending on a locked-down host.
September 9 activity is strong, while releases are absent
GitHub recorded 54,079 stars and a last push on September 9, 2026. Search results showed 254 open issues and 126 open pull requests, matching the repository's combined count of 380. Recent pull requests were also merged on September 9, so this is an actively changing codebase rather than a dormant one. The queue is busy enough that adopters should search it for their provider and client combination.
No GitHub latest release exists, and the tags endpoint returned an empty list even though pyproject.toml identifies version 6.2.1. That weakens traceability for teams that promote immutable upstream tags or need release notes tied to artifacts. The current push and issue traffic support a high community score. They do not substitute for a tagged release process or a passing result from our measured test command.
LiteLLM and OpenCode solve smaller parts of this job
Claude Code Router is the nearest alternative if routing Claude Code across models is the entire requirement. LiteLLM fits an application or team gateway that needs shared provider controls without 10 coding-agent launchers. OpenCode changes the client itself and connects to providers directly. FCC is the better choice when the existing client, browser Code sessions, and optional phone access all matter. Otherwise, selecting the narrower project reduces configuration and the number of compatibility paths you must verify.