BypassAIGC: a self-hosted paper rewriting service with an admin backend

Distributed as one executable, not as a Python environment

The repository root is thin: `README.md`, `LICENSE`, a `package/` directory, and two dot-directories for tooling (`.github/` and `.roo/`) plus `.spec-workflow/`. Everything that runs is inside `package/`, and the README's opening claim is that you need no development environment at all. You download a release archive for your platform, extract it somewhere, and run it.

The archive names are concrete and follow one pattern per platform, with the version embedded in the filename:

cd package
chmod +x build.sh
./build.sh

The Windows path uses `build.ps1` instead. Both scripts are described as optional, for people who want to produce the executables themselves; GitHub Actions produces them automatically when you push a tag beginning with `v`:

git tag v1.0.0
git push origin v1.0.0

So the release process is a tag push, and version 2.6.0 published on 2026-08-28 came out of that path. The last push was on 2026-08-28, which means the code and the newest release are in step.

Two LLM passes, three separate model slots

The pipeline is described as two stages, with the first stage handling polishing and the second handling originality enhancement. That split shows up in the configuration file as three model slots rather than two, because a third exists for a different content type: emotional or personal essay writing.

Each slot carries its own model name, key and base URL, and the README recommends the same model for all three:

POLISH_MODEL=gemini-2.5-pro
POLISH_API_KEY=KEY
POLISH_BASE_URL=http://IP:PORT/v1
ENHANCE_MODEL=gemini-2.5-pro
ENHANCE_API_KEY=KEY
ENHANCE_BASE_URL=http://IP:PORT/v1

Because the keys and base URLs are per stage, you can point polishing at one provider and enhancement at another, or use different models for different content types. All base URLs are documented as OpenAI compatible, which is what makes a local proxy or gateway usable in place of a hosted endpoint.

The one substantive design note in the configuration is `HISTORY_COMPRESSION_THRESHOLD`, which summarizes earlier turns once a conversation crosses a character count so a long paper does not blow through the context window. The README documents a default of 5000 in the settings table while the sample file shows 2000, a small inconsistency worth knowing if you rely on the table. Default and sample disagree on `MAX_CONCURRENT_USERS` as well: 7 in the sample file, 5 in the table.

FastAPI and React behind a login, with an admin screen for everything

The project structure block in the README names the stack directly: a `backend/` built on FastAPI with `app/routes/`, `app/services/`, `app/models/` and `app/utils/`, and a `frontend/` built on React with `src/pages/` and `src/components/`. Three local endpoints follow from that split, all on port 8000: the user interface at `localhost:8000`, the admin panel at `localhost:8000/admin`, and API documentation at `localhost:8000/docs`.

The fact that `/docs` is exposed by default is worth noting on its own. On a shared host that is a free map of the API, and it ships enabled rather than behind a flag.

The admin panel is the more interesting half, because it turns what would be a single user script into something you can run for a group. Its listed modules are a data panel with user statistics and session analysis, user management for generating key cards and capping usage counts, live session monitoring, a database management screen that can view, edit and delete records, and a system configuration tab where models, concurrency and usage limits are changed. That last tab is why the README claims configuration changes need no restart, which is the opposite of what the frequently asked questions section says, where the answer to a not-working-after-edit question is to restart the program. Both can be true, since editing a running system changes runtime values while editing `.env` changes file values, but the documentation does not draw that line.

Card keys, a Redis queue and a SQLite file next to the binary

Access is metered with a key card system. New users get `DEFAULT_USAGE_LIMIT` runs, set to 1 in both the sample file and the settings table, and an administrator generates and manages the cards. That makes the tool closer to a small hosted product than to a personal script, and it is the reason the project needs a database and a queue at all.

Storage is deliberately simple: `DATABASE_URL` defaults to `sqlite:///./ai_polish.db`, and the same line can be switched to a PostgreSQL URL by hand. The README states that the database file and the `.env` file both sit next to the executable, which makes backup and migration a copy operation. Concurrency is handled separately, with `REDIS_URL` used for a queue that caps how many polish jobs run at once and lets an administrator change that cap live. In other words a single machine deployment needs SQLite plus Redis plus the binary, three moving parts where one would do for a personal use case.

Paragraph handling is the other detail that shows the code was written around real documents. The system recognises headings and skips short paragraphs, with `SEGMENT_SKIP_THRESHOLD` set to 15 characters, so that a table caption or a heading is not sent through a rewriting pass and mangled.

Streaming is off by default because Gemini blocks it

The one bug documented at length in the README is worth repeating because it explains a configuration default. Gemini rejects streaming requests with a `Your request was blocked` error, so `USE_STREAMING` defaults to `false` and the comment in the sample file says streaming stays off to avoid that failure. The fix path documented for a user who hits the error is to log in to the admin panel, open the system configuration tab, confirm the streaming switch is disabled, save, and rerun the job.

The version 2.6.0 release note is a single fix rather than a feature: the pipeline was changed to use a user's default custom prompt, so that the prompt a person sets in the admin panel is the one the polish and enhance stages actually send. That is the kind of change that only matters to people already running the tool, and it is a reminder that the admin configuration is genuinely part of the product surface rather than a debug page.

Version numbering is plain, moving 2.5.2, 2.5.3 and then 2.6.0 with release names that carry no changelog text. The `CHANGELOG.md` file is not present in this repository, so the release list is the only record of what changed, and two of the three listed releases have an empty body.

What the screenshots claim, and what the licence forbids

The README's evidence for the tool working is a set of before and after screenshots and one image labelled with the name of a well known AI detector, showing a score for a rewritten passage. There is no written methodology, no detector list, no explanation of which text was submitted or with what settings, and no repeatability. For a tool whose entire reason to exist is a detector score, that is the weakest part of the documentation, and the honest reading is that the screenshots show one example rather than a measured effect.

The licensing is unusually restrictive for a project of this kind. No standard license identifier is attached to the project, and the README states that commercial use is forbidden without permission, then names Creative Commons CC BY-NC-SA 4.0. Those two statements are close to consistent, since the NC clause covers commercial use, but the double declaration makes the terms harder to read than they need to be. The README also asks three specific things before a production deployment: change the default administrator password in `.env`, generate a strong `SECRET_KEY` of at least 32 random bytes, and fill in a valid `OPENAI_API_KEY`.

Those requests matter more than usual here, because the sample configuration ships `ADMIN_PASSWORD=admin123` and `DEFAULT_USAGE_LIMIT=1`, and because the tool authenticates with JWT using HS256 and a 60 minute token lifetime. A deployment that keeps the shipped password on a reachable host has an open admin panel over everyone's written work. The English documentation is also a translation of a Chinese original throughout, which is fine for reading but means troubleshooting conversations happen in Chinese.

Editorial conclusion

BypassAIGC is a small self-hosted web service rather than a library, and the interesting engineering is in the operational layer: a queue, a concurrency cap, a key card system, a live configuration screen and history compression to keep long papers inside a context window. What the README does not settle is whether rewriting changes an AI detector score, since the only evidence offered is a screenshot of one detector, and that is the claim you should treat with the most care given what the tool is for. If you want to read the code, `package/README.md` is the build entry point; if you want to run it, change `ADMIN_PASSWORD` and `SECRET_KEY` in the generated `.env` before the first launch, because the defaults in that file are printed in the documentation itself.

Frequently asked questions

Official sources

1. chi111i/BypassAIGC on GitHub
2. Issues
3. README
4. Releases