ChatALL: One Prompt, Many Bots, and the Debugging Cost of Web Scraping

The problem ChatALL targets: one prompt, many answers, no tab juggling

The README opens with the premise that LLM behaviour is random and that different bots excel at different tasks, so trying them one by one is the wrong workflow. ChatALL's answer is a single desktop client that sends the same prompt to several bots concurrently and lays the answers side by side. The README names three intended audiences: people hunting for the best answer, researchers comparing model strengths by field, and developers debugging prompts who want to find the best-performing base model. That third group is the most concrete. If you are iterating on a system prompt and want to know whether Claude, Gemini or ChatGPT handles it better, ChatALL removes the copy-paste loop between browser tabs. The Chinese name 齐叨 appears alongside the English one, and the project ships README translations in ten languages, which tells you the maintainers expect a broad, non-English-speaking user base. What ChatALL is not, based on the material, is an evaluation framework. There is no scoring, no dataset runner, no statistical comparison. It is a comparison surface for a human sitting in front of it.

Two integration paths: official APIs and browser-driven web access

The supported-bots table is the most informative part of the repository. Every entry carries a Web Access column, an API column, and a notes field. ChatGPT, Claude and Gemini support both paths. Many others are web-only: Character.AI, Copilot, HuggingChat, Kimi, Perplexity, Phind, Pi, Poe, YouChat and others are marked Yes for web access and No API. Several Chinese services (Baidu ERNIE, Groq Cloud, xAI Grok, Cohere models) are API-only. A handful are marked Coming soon on the API side, including iFLYTEK SPARK, Poe, SkyWork and Tongyi Qianwen. That split is the architectural core of the project. API bots are straightforward HTTP clients. Web-access bots have to be driven through something closer to a browser session, which is why the application is packaged as an Electron desktop app rather than a server: it needs a real browser context, and in some cases a logged-in one, to talk to services that expose no public endpoint. The notes column also flags friction: ChatGLM2 and Vicuna are marked No Login required, while ChatGPT's row mentions Web Browsing and Azure OpenAI service included. Because the app is Electron and Vue-based, the same codebase targets Windows, macOS and Linux, which the topics list confirms.

Getting it running: download, install, ask

The README's installation instructions are deliberately short. It says to download, install and ask, and points at the GitHub releases page for binaries. There is no documented build-from-source sequence in the supplied material, so a contributor workflow is not something I can describe from what is here. What the material does show is a Codespaces badge, which suggests the repository is expected to open in a browser-based development container. The three most recent releases are v1.85.110 (May 2025), v1.84.109 (March 2025) and v1.83.108 (October 2024). The numbering is unusual: the tag and the version string are different, so v1.85.110 carries the version 1.85.110. The gap between the October 2024 and March 2025 releases is roughly five months, and the gap to May 2025 is about two months, so the release cadence is irregular rather than fixed. For a tool whose web-access bots depend on third-party page structure, that cadence matters more than it would for a pure API client. If a vendor changes its front end, the fix has to wait for the next release. The practical setup step the README implies but does not spell out is logging in: web-access bots that are not marked No Login required will need a session, and the desktop packaging exists partly to make that possible.

Where the design breaks: scrapers, logins and vendor drift

The largest limitation is structural, not a bug. Any bot listed as Web Access with No API is being driven through a surface that its vendor never promised to keep stable. Login flows, bot-detection challenges and DOM changes can all break a web-access integration, and the project cannot fix that until it ships a release. The release history suggests users should expect windows where specific bots simply do not answer. There is a second, subtler cost: concurrency means every prompt you send is sent to every selected bot, so a casual question burns quota or rate limit across a dozen services at once. For API-backed bots such as Groq Cloud or xAI Grok, that is a real billable action per prompt, not a free comparison. The table's Coming soon entries are also worth reading literally. iFLYTEK SPARK, Poe, SkyWork and Tongyi Qianwen are listed as web-accessible with API support promised later, which means the API path for those services is not something you can plan around today. Finally, the README gives no statement about data handling. If you paste proprietary code into a comparison prompt, it goes to every selected bot, including web sessions you may not control. The project does not appear to offer a redaction or local-only mode in the material provided.

How it differs from single-vendor clients and from prompt-playground tools

The obvious alternative is the vendor's own client: ChatGPT's web app, Claude's web app, Gemini's web app. Those are more reliable for their own model because the vendor maintains the integration, but they give you one answer at a time and no side-by-side view, which is exactly the loop ChatALL is trying to remove. A second alternative is a hosted prompt playground that exposes many models behind one API, such as the model-comparison features offered by API aggregators. The difference in approach is fundamental. A playground routes everything through a single HTTP API and one billing relationship, so results are reproducible and scriptable, but it only covers models that the aggregator has contracted to serve. ChatALL covers a wider set of bots precisely because it is willing to drive web UIs directly, including services like Character.AI, Pi and Phind that have no public API at all. That breadth is bought with fragility. If your goal is a repeatable benchmark that runs in CI, an API aggregator is the better shape. If your goal is to see what a dozen consumer chatbots actually say to the same question today, ChatALL is doing something an API-only tool cannot do.

Maintenance, licence and the cost of keeping scrapers alive

ChatALL is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved and any modified files carry prominent change notices. It also includes a patent grant. I am not a lawyer and this is not legal advice; if you plan to redistribute a modified build, read the licence text and the NOTICE requirements yourself. The maintenance cost is the more interesting question. Because the project is desktop-distributed, upgrading means downloading a new release rather than pulling a container image, and the irregular cadence shown by the three recent releases means you cannot predict when a broken bot will be repaired. There is no documented plugin interface in the supplied material, so adding a bot you care about appears to mean contributing to the main repository rather than dropping in an extension. For a team, that turns every vendor page change into a dependency on upstream. For an individual, it means the tool is good on the day you install it and may degrade quietly over the following months. The release tags also suggest the project is maintained but not on a schedule, which is a reasonable trade for a free Apache-2.0 desktop utility and a poor one for anything with an SLA.

Who should install it, and what to check before trusting a bot

ChatALL fits the person the README describes: someone who wants to compare answers from several models in one window and is willing to re-download the app when a bot breaks. It also fits the developer debugging a prompt who wants a quick read on which base model handles it best. It does not fit a production pipeline. There is no batch mode, no scoring, no scheduling and no stability guarantee in the material, so using it as an evaluation harness would mean building all of that yourself around a desktop GUI. Before you rely on any specific bot, open the supported-bots table and check three things: whether the row says Web Access, API or both; whether the notes column flags a login requirement, since ChatGLM2 and Vicuna are the only rows marked No Login required; and whether the API column says Coming soon, which means that path is not available yet. Then confirm the release you downloaded matches the version whose table you read, because the bot list changes between releases. That check takes a minute and prevents the most common disappointment with this class of tool: assuming a bot is supported when it is only supported through a page that has since changed.

Editorial conclusion

Adopt ChatALL if you are an individual engineer or researcher comparing model outputs interactively, and you accept that web-access bots can stop working after a vendor UI change. Do not adopt it as a production gateway or an unattended evaluation harness; the README shows no batch API, no scoring layer and no CI integration. Before relying on any single bot, check whether it is listed as Web Access or API in the supported-bots table, read the notes column, and confirm the release you download matches the version whose bot list you reviewed.

Official sources

1. ai-shifu/ChatALL on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases