free-coding-models: A TUI for Picking Among 228 Free Coding Models

The question FCM answers, and the people asking it

There are enough free and free-limited coding endpoints now that picking one is a research task. The README puts the catalog at 24 providers and 228 live models, generated from a file called sources.js. The problem is not finding a list. It is deciding which entry on that list is fast and stable at the moment you sit down to work, because average latency hides the model that occasionally takes six seconds to answer. The README states the point plainly: a model that randomly spikes to 6 seconds is not reliable. FCM is aimed at developers who already collect free API keys, who switch between coding assistants, and who are willing to trade a little setup time for a measured answer instead of a guess. It is also aimed at people running agents: the project ships an OpenCode plugin and a Pi extension for hot-swapping models mid-session, plus a local router daemon for setups that want one endpoint with failover.

What actually happens between launch and a ranked table

The mechanism is probing. On first run FCM prompts for API keys, skipping any you leave blank, then pings every model in the catalog in parallel. Rows turn green as replies arrive. From those probes it computes a Stability Score from 0 to 100 that combines p95 latency, jitter, spike rate and uptime, which is a more honest summary than a mean. A probe cache is shared across surfaces and described as persistent for 24 hours, so the TUI, the web dashboard and the router are not each re-measuring the same endpoints from scratch. There is a second, heavier measurement path: AI Speed Test benchmarks run real completions and report AI Latency plus tokens per second. The catalog itself is not hand-maintained prose. The provider table in docs/providers.md is generated from sources.js by a script, node scripts/generate-provider-table.mjs, which is a reasonable way to stop documentation counts from drifting away from the code. Tier labels (S+ at 70 percent or above on SWE-bench Verified, down to C) come from a fixed external benchmark, not from FCM's own probes, so treat the tier as a capability hint and the stability score as the live signal.

Install, key entry, and the flags that do real work

Installation is a global npm package requiring Node.js 18 or later, with no native build step and, per the README, no need for sudo. The two commands given are npm install -g free-coding-models followed by free-coding-models. Running free-coding-models --help prints every flag. The README names three providers as starting points with their signup pages: Groq, Cerebras (described as the lowest latency in the catalog) and NVIDIA NIM (described as the biggest no-credit-card quota). Additional keys can be added later from inside the app with P. Keys are read from environment variables, and the provider table lists names such as DASHSCOPE_API_KEY, OLLAMA_API_KEY, OPENROUTER_API_KEY, CLOUDFLARE_API_TOKEN, KILO_API_KEY, NVIDIA_API_KEY, POLLINATIONS_API_KEY and OVH_AI_ENDPOINTS_ACCESS_TOKEN. The launch flags are where the tool earns its place: free-coding-models --goose --tier S pre-targets Goose and filters to S-tier models, free-coding-models --crush --origin groq restricts to one provider, and free-coding-models --fiable prints the single most reliable model and exits, which is the form you would use in a script. Inside the TUI, Enter writes the selected model into the target tool's config and launches it, Z cycles the target tool, and single letters drive sorting (R for rank, S for SWE, V for verdict, B for stability) and filtering (T for tier, D for provider, E for visibility).

The quota problem FCM creates for itself

Probing costs requests, and on free tiers requests are the scarce resource. The README acknowledges this directly: health probes consume provider quota, FCM auto-pauses a provider on a 429 response, backs off exponentially per failing model, and shows a footer chip while a provider rests. That is a sensible design, but it means the tool's measurement activity competes with the coding session it is trying to enable. A user who leaves FCM open and re-probes aggressively can spend the day's allowance before writing any code. The mitigation offered is that leaving a key empty still allows anonymous liveness probes for most providers, which gives you a rough signal without an account but presumably a thinner one. The 24-hour probe cache is the other mitigation: it limits how often the same endpoint is measured. Neither removes the tension. If your provider's free tier is small, the honest move is to probe once, pick, and stop probing.

Where the tool stops being the right choice

FCM assumes your coding tool reads a local config file and that rewriting that file is acceptable. That assumption fails in several common setups. If you work inside a managed environment where config files are provisioned centrally, or inside a hosted IDE whose model selection lives server-side, the install step has nothing to write to. If you need a hard throughput guarantee, a catalog of free endpoints is the wrong substrate regardless of how well it is ranked: the tiers describe model capability on SWE-bench Verified, not the rate limits or concurrency you will get. And if your work is latency-insensitive batch processing, the entire stability apparatus is overhead, because a model that spikes occasionally still finishes the job. There is also a maintenance surface worth naming. The catalog is generated from sources.js and the provider table is generated from it, which keeps the two consistent, but free provider catalogs change without notice. A model can disappear from a provider between releases, and FCM's own release cadence suggests active upkeep: v0.5.89, v0.5.90 and v0.5.91 landed within four days in September 2026. Upgrading is cheap (npm install -g again), but each upgrade is a chance for the catalog to have shifted under you.

How it differs from OpenRouter and from raw provider SDKs

OpenRouter is the obvious comparison and the difference is structural. OpenRouter is a hosted gateway: you send requests to one endpoint, it routes them, and your code depends on that service being up and on its own model list. FCM does not sit in the request path at all in its default mode. It measures endpoints, then edits the config of a separate tool so that tool talks to the provider directly. Your inference traffic never passes through FCM, which means FCM being down does not break your editor. The trade-off is that you get no server-side failover in that mode, which is exactly why the project also ships the Smart Model Router, a local OpenAI-compatible daemon started with free-coding-models --daemon-bg that adds auto-failover. That is the middle position: local process, OpenAI-compatible surface, failover logic you control. Compared with just reading provider docs and hardcoding a model name, FCM's contribution is the measurement loop and the config write, not access to the models themselves.

Licence and upkeep before you build on it

The repository's license field reads NOASSERTION, which means the hosting platform could not classify the licence from the files present. That is not the same as having no licence, and it is not the same as a permissive one. If you intend to vendor FCM, fork it, or ship it inside a product, read the LICENSE file in the repository yourself and get your own answer; nothing in the material supplied here settles the question. On upkeep, the visible cost is low for users and real for the maintainer: the npm package updates with a single global install, and the generated provider table means documentation does not need separate editing. What you are depending on is that sources.js keeps tracking providers whose free offerings change on their own schedule.

Editorial conclusion

Adopt FCM if you already hold API keys for several free providers and want a repeatable way to pick one per task, or if you want a single local endpoint with failover via the Smart Model Router. Do not adopt it if you need guaranteed throughput, if you cannot accept that health probes consume the same free quota your coding session needs, or if you want a hosted gateway rather than a CLI that rewrites local config files. Before committing, run free-coding-models --help to confirm the flags your version exposes, run free-coding-models --fiable to see whether a single model clears your reliability bar, and check docs/providers.md for the free-tier limits of the providers you actually hold keys for, since the license field on the repository is NOASSERTION and you should read the LICENSE file yourself rather than assume terms.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. vava-nessa/free-coding-models on GitHub