api-check: probing OpenAI API proxies from the browser

What a proxy tester needs to answer

The problem starts with third party API proxies. If you pay for access to a service through a reseller or a self hosted gateway such as oneapi or newapi, you need to know whether the models you paid for are actually there, whether they answer consistently, and how quickly. api-check is built for that. It tests the availability and consistency of multiple models, checks the API account usage quota, retrieves and displays the list of available models, and extracts API information with a convenient copy function. The audience is not application developers looking for an HTTP client; it is operators and buyers who want to compare what a proxy actually serves against what its model list advertises, before they point a production application at it.

Every request leaves from your own browser

The distinguishing design decision is stated plainly in the README: all operations are performed on the front end, which removes concerns about network timeouts on a shared server and keeps the tested payloads out of a third party backend. The tool is built as a Vue application with Vite, and the repository holds the client under src/ with the server entry point in server.js and an api/ directory for the optional storage endpoints. The practical consequence is that whatever you paste into the tool, including your endpoint URL and keys, is sent from your browser directly to the endpoint you are testing. The tradeoff is that browser cross origin rules and the endpoint's own CORS policy decide what you can reach, so a proxy that refuses cross origin requests may not be testable from a page you host yourself, while the hosted instance at check.crond.dev has its own origin.

Running it yourself with one Docker command

The Docker path is the quickest way to get a private copy, and the image is published to GitHub Container Registry and rebuilt on every push to the main branch:

docker run -d -p 13000:13000 \
  -e PASSWORD=you_password \
  -v your_path:/app/data \
  --name api-check ghcr.io/october-coder/api-check:latest

Port 13000 is mapped from the container, the PASSWORD variable protects the backend endpoints that the cloud storage feature needs, and the volume mount keeps the data directory on the host. The README lists three tag styles: latest for the newest main branch build, version tags such as v2.1.0, and sha-xxxxxxx tags tied to a commit. Pinning to a version tag or a commit tag is the sensible choice if you care which build you are testing against, since the latest tag moves on every push.

Three deployment targets and one password variable

Deployment is the one place where the pure front-end claim is qualified, because the cloud storage feature needs a small backend. Three paths are documented. Vercel deployment is a one click clone from the repository, and the README asks you to fill in the backend password on the environment variables page; a detailed tutorial for the backend service sits in docs/vercel.md. Docker deployment is the command above. Cloudflare deployment has its own tutorial in docs/cloudflare.md, and the project recommends binding a custom domain in that case, as it also does for Vercel, where the assigned domain may be unreliable in some regions. The backend URL differs by target, which is a detail worth copying correctly: for Docker and Vercel it should be https://your_website/api, while for Cloudflare it is https://your_website. Local storage, in contrast, needs no backend at all.

Preset parameters for a single test run

The tool takes a small set of preset parameters, and the README documents each of them with a description and an example. The url field is the API endpoint address, the models field is an array of model names indicating which models are available, timeout is the request timeout in seconds, and concurrency is the number of concurrent requests. The closeAnnouncement setting disables the announcement display, with true to disable and false or undefined to display it, and the README marks it as convenient for proxy sites, which is a hint about the intended audience. Preset parameters exist so that a configuration can be saved and reloaded rather than typed each time, and the v2.0.0 update added one click binding to new-api and a settings panel for managing the stored configurations.

The verification features test more than liveness

Beyond the basic availability and quota checks, the tool has a set of advanced verification features that probe behaviour rather than reachability. Official proxy verification checks the authenticity of the API and shows system fingerprints, temperature verification checks the randomness and stability of the model, and function call verification tests whether the model can call functions. The release history shows this area growing: v1.3.0 added official API verification and filtering queries, v1.4.0 added temperature verification, function verification and optimized test prompts, and v1.5.0 optimized o1 model testing. The most recent release, v2.1.0, added quick chat testing integrated with a modified NextChat, a closeChat setting for proxy usage, a paste button, and custom conversation verification for quick prompt testing, plus an experimental features module contributed from another project that covers batch testing of GPT refresh tokens, Claude session keys and Gemini API keys.

Where the data goes: local storage, cloud storage and the password

Configuration handling is split in two. Local storage keeps frequently used configurations in the browser for quick loading, which is the private option and needs no server. Cloud storage saves configurations to the cloud server for multi-device synchronization, so you can reach them from anywhere, and it is the feature that requires the backend and its PASSWORD. The README is explicit that the pure front-end approach is what removes the data security concern, and the presence of the optional backend is what makes cloud storage possible. The rest is presentation: dark and light mode with automatic adaptation to system settings, internationalization in Chinese and English, and mobile adaptation work that arrived in v1.5.0 alongside the dark theme.

How the image is built and where the project stands

The Dockerfile is a three stage Alpine build on node:24-alpine. The base stage installs CA certificates and sets the npm registry, which CI can override with a build argument, the builder stage installs dependencies, runs the build and then reinstalls production dependencies only, and the final stage copies server.js, dist, api and node_modules from the builder, creates a non root user with uid 1001 and gives it ownership of /app:

ENV PORT=13000
EXPOSE 13000
USER appuser
CMD ["node", "server.js"]

The project scripts in package.json cover the same ground, with dev, build and preview for the Vite front end, start for the Express server, and docker:install for a production install inside the image. The licence field on the repository says Apache-2.0. On maintenance, the last push to the main branch was on 2026-06-13, but the newest release tag, v2.1.0, dates from 2024-11-14, with 1.4.6 and 1.4.5 before it, so the repository is receiving changes while the published version lags well behind.

Editorial conclusion

Adopt api-check when you buy access to an OpenAI compatible proxy through a reseller or a self hosted gateway and need to see which models actually answer, how consistent they are and how fast, before you point a production application at it. Do not adopt it as a general API client, and do not expect it to reach an endpoint that refuses cross origin requests from a page you host yourself. Verify first that the endpoint allows requests from your origin, that the model list you test against is the list the proxy advertises, and that the tag you deploy is the one you intend to trust, since the latest Docker tag follows the main branch while v2.1.0 and the sha tags pin a specific build.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. october-coder/api-check on GitHub
3. Project website
4. README
5. Releases