Included among the curated providers whose free tiers are tracked (Cloudflare Workers AI), with each row carrying its source URL and human-verified date rather than being presented as live data.
Ships a human-verified curated entry for Cloudflare Workers AI's free tier, so agents can look up its free-model lineup, limits, and catches (with source URL and verification date) alongside the other providers.
Provides a curated, dated snapshot of Google Gemini's free tier — models, rate limits, and caveats such as training use — queryable via the free_providers tool.
Provides a curated, source-cited snapshot of the NVIDIA NIM free tier, letting agents check which NVIDIA-hosted models are free and their limits before wiring them into a project.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@llm-freewatch which free models can I use right now that support tool calling?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Know which free LLM APIs still work today — before your agent finds out the hard way.
Free LLM tiers churn constantly: models appear and vanish, limits change without notice, and whole programs get retired (GitHub Models shut down on 2026-07-30 and old blog posts still recommend it). If your coding agent, side project, or demo is wired to a hard-coded "free" model id, it breaks silently.
llm-freewatch is a zero-dependency Python tool that keeps an eye on the free
landscape for you:
Live radar — fetches the live OpenRouter catalog and lists models that are actually free right now (prompt and completion price both $0), with context length and tool-calling support.
Change diffs — every scan is diffed against the previous one, so you see which free models were added or removed since yesterday.
Fallback chains — prints an ordered chain of free, tool-calling models (JSON, or a ready-to-use LiteLLM config) to walk when one model returns 429/404.
Real probes — optionally runs one genuine tool-call against a model with your
own key and classifies the result ok / hard / transient. A 429 is reported
as transient — not a verdict, never as "the model is broken".
Curated providers — for providers without a public catalog API (Groq, Google Gemini, NVIDIA NIM, Mistral, Cloudflare Workers AI, Cohere), ships a curated table where every row carries its source URL and human-verified date, including the catches (card rules, training use, trial-only). Curated rows are never disguised as live data.
MCP server — runs over stdio, so Claude Code / Codex / Cursor agents can ask mid-task: "which free models can I use right now?" instead of guessing.
Agent skill — ships a SKILL.md (see skill/) that teaches agents when and
how to check the free lineup before hard-coding a model.
Zero third-party dependencies. Python 3.10+ standard library only.
git clone <this repo>
cd llm-freewatch
python3 -m llm_freewatch scan --tools # what is free + tool-capable right now
python3 -m llm_freewatch providers # curated free tiers, limits and catches
python3 -m llm_freewatch chain # ordered fallback chain (JSON)
python3 -m llm_freewatch chain --format litellm > litellm_config.yamlExample output (live, 2026-10-22):
MODEL CONTEXT TOOLS
thinkingmachines/inkling:free 1,048,576 yes
nvidia/nemotron-3-ultra-550b-a55b:free 1,000,000 yes
google/gemma-4-31b-it:free 262,144 yes
...
18 free models.The current snapshot is regenerated daily in docs/FREE_MODELS.md.
Related MCP server: FreeLLM-MCP
export OPENROUTER_API_KEY=... # your own key; read from env only, never stored
python3 -m llm_freewatch probe nvidia/nemotron-3-super-120b-a12b:free
# {"model": "...", "verdict": "ok", "http": 200, "latency_ms": 812}{
"mcpServers": {
"llm-freewatch": {
"command": "python3",
"args": ["-m", "llm_freewatch", "mcp"],
"cwd": "/path/to/llm-freewatch"
}
}
}Tools: list_free_models, free_model_changes, free_providers.
This project grew out of running a personal coding agent on free models: the free lineup rotated often enough that a daily radar + diff became the difference between "agent works" and "agent silently fails". The same churn is documented publicly — free-tier roundups in October 2026 all warn that the limits and lineups they list will be wrong soon. A list goes stale; a watcher doesn't.
Only the OpenRouter catalog is fetched live today. Other providers are curated
snapshots with sources and dates, and they will drift — PRs updating a row must
update its verified date and source.
"Free" means the provider lists $0 pricing. Free tiers have rate limits (for OpenRouter free models, typically 20 RPM and 50 requests/day on a free account) and providers may log or train on free-tier prompts. Check each provider's terms.
A probe ok means one tool call worked once. It is a smoke test, not a benchmark.
python3 -m pytest tests/ -q # or run the test modules with any runnerMIT
中文说明见 README.zh-CN.md。
Diff the live free catalog against the last local scan: which free models appeared or disappeared. Free lineups rotate; check before hard-coding a model id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden alone. It usefully discloses that the diff is against a *last local scan* — a stateful dependency that an agent must know about — but never says what happens when no prior scan exists or whether the comparison is cached/stale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the core operation stated first and the rationale second. Nothing is padded or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the description covers what it does and the shape of the result (appeared/disappeared). The main missing piece is the failure mode when a local scan baseline is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the description correctly implies a parameterless call. Baseline 4 applies since there is nothing for the schema to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ("diff") against a specific resource (live free catalog vs. last local scan) and states the output shape: models that appeared or disappeared. It is clearly distinguishable from list_free_models and free_providers by implication, though neither sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Check before hard-coding a model id" gives one concrete trigger, and "free lineups rotate" explains why. However, there is no explicit routing versus list_free_models (full list) or free_providers, and no when-not-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated, human-verified free tiers for providers without a public catalog API (Groq, Gemini, NVIDIA NIM, Mistral, Cloudflare, Cohere), with limits, card rules and catches, each with source and verified date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reasonably well: it discloses provenance ('human-verified', 'each with source and verified date') and the shape of the payload (limits, card rules and catches). It stops short of stating freshness guarantees or that results are a static curated snapshot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence, front-loaded with the core noun phrase and then the provider list and payload contents. Every clause carries information, though the provider parenthetical is long and could be trimmed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating the returned content (limits, card rules, catches, source, verified date). For a zero-parameter read tool this is essentially complete; only the response container format is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('Curated, human-verified free tiers for providers') and enumerates exactly which providers (Groq, Gemini, NVIDIA NIM, Mistral, Cloudflare, Cohere) and which fields are returned. Clear enough to distinguish from a generic model list, though it never names the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The qualifier 'without a public catalog API' implicitly tells the agent when to reach for this instead of a catalog-backed tool, but no alternative is named and there is no explicit 'use X instead when Y' routing. Usage is inferable, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently free models from the live OpenRouter catalog. Optionally require tool calling and a minimum context length.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tools_only | No | ||
| min_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden, yet it only says the data comes from a 'live' catalog. It never states whether results are ordered, how the limit caps the output, or what shape a result entry has (no output schema exists). For a read-only listing tool these gaps are moderate rather than fatal, but they are real.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the purpose front-loaded and zero filler. It is tight, though it sits close to the border of being too terse given how much it leaves undocumented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema coverage, the description would need to do much more. It omits the limit parameter entirely, gives no units for min_context, and says nothing about the return value, which is significant for a tool whose entire output contract is undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all three parameters depend on the description. It loosely covers tools_only ('require tool calling') and min_context ('minimum context length'), but gives no units for min_context and never mentions the limit parameter or its default of 20, leaving a third of the surface unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('List ... models from the live OpenRouter catalog'), and the resource is clearly distinct from the siblings free_providers and free_model_changes. It stops short of naming those siblings, so an agent must infer the separation from the nouns alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can guess that this is the tool for 'what free models are available right now', but the description never states a case for choosing it over free_providers or free_model_changes, nor any prerequisites or exclusions. The 'optionally require tool calling' phrasing reads as a filter hint rather than guidance on when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0free_model_changesfree_providerslist_free_modelsScored across 3 tools
Each tool targets a distinct concern: live catalog listing, a delta against the previous scan, and curated static provider info. The only mild overlap is between list_free_models and free_model_changes, since the diff presumably builds on the same catalog, but descriptions make the boundary clear.
list_free_models follows a verb_noun pattern while free_model_changes and free_providers are bare noun phrases, so the convention is mixed. Names remain short and readable, and the shared 'free' prefix gives topical coherence.
Three tools is lean but each covers a genuinely different access mode (live query, historical diff, curated reference). The scope is narrow enough that this isn't bloated, though it sits at the thin end of the range.
The surface has a notable gap: free_model_changes diffs against 'the last local scan' but there is no tool to perform or update a scan/baseline, so the diff can be a dead end. There is also no lookup for a single model's details or pricing limits beyond raw listing.
Live registry of AI model specs, context windows, and per-token pricing.
Read-only lookups of public AI agent pricing, free plans and source links. No API key.
Live data on AI agents, APIs and models: prices, free tiers, limits, outages, real-world usage.
Agent-operated. Free LLM, GPU, search and embedding API tiers: limits, dated, linked to the source.
