Open-source tool revives AI Keys in bulk: Scan four platforms at once

An Open-Source Tool Born Out of the “Key Pool”

In mid-May, a small utility called api-key-checker quietly became popular on Linux.do. Its author, purainity, got straight to the point in the post, describing the reality faced by many heavy AI users: they’ve accumulated dozens or hundreds of API Keys from various sources—some from registration bonuses, some shared by others, some scavenged from GitHub “wild hunts”—but there’s no unified way to figure out whether these Keys still work, how much balance remains, or which models they can call.

The project currently covers four major platforms: OpenRouter, SiliconFlow, and DeepSeek for balance checks, and Gemini for basic testing, deep testing, and model method availability validation. The code was completely written by AI. The author admits in the post that although it sounds easy, “writing detailed and specific prompts and continually interacting with it to make changes is actually quite exhausting”—a complaint that rings true to anyone who’s tried vibe coding.

Why Such Tools Suddenly Became Common This Year

If you only look at api-key-checker, you might think it’s a niche toy. But zoom out a bit, and you’ll notice that similar tools have been surfacing intensively on GitHub in the past six months: weiruchenai1’s api-key-tester offers batch testing via a web interface for OpenAI, Claude, and Gemini; qixing-jk’s all-api-hub goes even further—it’s a browser extension that aggregates the balances, check-ins, key exports, and model validation for relays like one-api, new-api, and Veloera into a single dashboard.

It’s not a coincidence. The logic behind this is that the supply side of AI APIs has changed in several ways over the past year:

• Free credits became a marketing tool: SiliconFlow, OpenRouter, and Gemini all issued large bonuses or free tiers at different times, which fostered a culture of key circulation and sharing within the community.
• Relay gateways have exploded: The spread of self-hosted gateways like one-api and new-api has turned “a developer holding a dozen upstream channels” from an exception into the norm.
• Model routing failure rates are high: It’s common for a Key to work fine with model A but fail with a 404 on model B, especially with Gemini, whose policies change frequently under Google.

Manually testing them one by one with curl and jq gets frustrating by the tenth Key—you’ll want to smash your keyboard. So tools naturally emerged to help.

How Each Platform Is Tested

Looking at api-key-checker’s design, you can tell the author has truly “been there.”

OpenRouter / SiliconFlow / DeepSeek are all relatively straightforward, since they officially provide balance inquiry APIs. The script simply hits endpoints like /user or /balance and parses the returned JSON for the remaining credits. This kind of check is a “cold test”—it doesn’t consume tokens or trigger rate limits, so you can run it in bulk safely. OpenRouter even returns metadata like whether the Key is BYOK and whether it’s rate-limited.

Gemini, however, is much trickier. The way Google Cloud’s API Keys are designed isn’t meant for convenient verification—they don’t have a unified balance endpoint because Gemini uses GCP’s billing system, where quotas are tied to projects. So the author created three testing tiers:

• Basic testing: Calls lightweight endpoints like models.list to verify that the Key is valid and not revoked.
• Deep testing: Makes a small actual generateContent call to see if it can genuinely produce tokens—this is necessary because many Keys pass basic testing but fail with PERMISSION_DENIED when calling models, rendering those Keys useless.
• Model method availability testing: Tests each model and method individually—for example, gemini-2.5-pro might support generateContent, but gemini-2.5-pro-vision might not, or certain projects might disable streamGenerateContent. This is especially helpful when debugging Gemini-based apps.

This layered design actually exposes a long-standing problem with Gemini’s API: a single Key’s usability varies across models and methods—it can’t be simplified to a binary “valid or invalid” judgment. The early “wild hunt” culture (scanning GitHub for leaked AIzaSy keys) required tools like this because the found Keys were of mixed quality—each had to be tested carefully to know if it was worth adding to a Key pool.

Positioning Differences Among Similar Tools

Comparing api-key-checker with the other mentioned tools reveals that each targets a different niche.

| Project | Form | Main Use Case | Supported Platforms | | --- | --- | --- | --- | | api-key-checker | Bash script | Pure detection, automated batch runs | OpenRouter / SiliconFlow / DeepSeek / Gemini | | api-key-tester | Web app (Docker-capable) | GUI, multi-user sharing | OpenAI / Claude / Gemini, etc. | | all-api-hub | Browser extension | Relay asset management, check-ins, exports | All sites compatible with the New API standard |

The advantage of api-key-checker lies in its lightweight nature—it’s just some shell scripts combined with curl and jq, with no frontend, no database, and no bulky npm dependencies. It fits easily into CI pipelines, daily cron jobs, or existing Bash toolchains.

Its disadvantage is equally clear: user interaction can’t compare with graphical tools—non-technical users will likely steer clear. But since the target audience is the Linux.do community of terminal enthusiasts, this trade-off makes perfect sense.

# Typical usage (see README)
./check_openrouter.sh keys.txt
./check_gemini.sh --mode=deep keys.txt

A few commands can run through a list of Keys, with results grouped by statuses like usable, invalid, or limited balance.

Some Important Details

When using such tools, keep a few things in mind:

First, batch testing consumes quota, especially in the deep testing tier, where each Key triggers a real inference request. If you’re scanning shared free Keys, that cost isn’t yours—but if you’re testing your own paid Keys, lower the testing frequency, or you might waste credits just to check your balance.

Second, Gemini test results have a short shelf life. Google has been changing Gemini’s API frequently this year—free-tier credits were slashed early in the year, and regional restrictions, model deprecations, and quota policies shift monthly. A Key tested as valid today might become invalid tomorrow due to policy changes, so these tools are best viewed as providing “current state snapshots,” not as static asset management instruments.

Third, know the legal and ethical boundaries. Scanning GitHub for inadvertently leaked Keys may seem entertaining to the community, but technically, those Keys belong to someone else. The tool itself isn’t the problem—how you use it is.

What Comes After Tooling

From api-key-checker to api-key-tester to all-api-hub, we can see a clear evolution: from single-point testing to batch checks, then to asset dashboards. Developers’ approach to managing AI APIs is evolving—from ad-hoc curl commands in IDEs to requiring specialized toolchains for engineering-level management.

Behind this trend lies a bigger shift—multi-model hybrid invocation has become the default. A decent AI app backend might use GPT-4o as a fallback, Claude for long text, Gemini for multimodal inputs, DeepSeek or Qwen for cost-sensitive tasks, plus one or two local open-source models as fallbacks. Each added provider doubles the complexity of accounts, Keys, billing, and rate limits.

That’s partly why aggregator API services have risen rapidly in the past year. Platforms like OpenAI Hub essentially streamline this “multi-Key, multi-platform” complexity into a unified interface—a single Key can access GPT, Claude, Gemini, DeepSeek, with domestic connectivity, unified billing, and OpenAI-style compatibility. For teams that don’t want to maintain a Key pool, write detection scripts, or chase after constantly changing provider policies, that’s far more convenient.

But for developers who love tinkering and optimizing costs, small and elegant tools like api-key-checker still have their place. That’s the beauty of open source—you can either outsource the dirty work to aggregation platforms or build your own custom toolchain; both paths are valid.

Final Thoughts

Seeing projects like this—built purely to scratch the author’s own itch—is often more satisfying than watching big companies’ official releases. Purainity explained it honestly in the post: it started with manually checking Keys, then when the number grew, they had AI write scripts, and eventually decided to organize the scripts and make them open source. No funding, no roadmap, no product manager deciding features—just a developer solving a pain point in their own workflow.

The density of such “micro-projects” in the AI tools ecosystem has clearly increased this year. The good side is richer community supply; the bad side is uneven quality and maintenance cycles. When choosing tools, look for a few signals: does the author actually use it? Are issues answered quickly? Is the code actively updated? These are far more reliable indicators than star counts.

References

• Linux.do: Introduction post for multi-platform AI API Key batch detection scripts – Original explanation by author purainity about project motivation and technical details
• GitHub: weiruchenai1/api-key-tester – Similar batch testing tool in web form, supporting OpenAI, Claude, Gemini
• GitHub: qixing-jk/all-api-hub – Browser extension for relay aggregation and key management, featuring dashboards and key exports