study-dost-ai: three explanations per question, one RDP host behind them

Three explanations arrive in every response, not as a choice

The premise is one sentence: textbooks explain things one way, but every student's brain learns differently. The answer is that a single request returns three renderings at once, a methodical step-by-step walkthrough, a real-world analogy, and a sketchable visual cue, with the claim that whichever one lands is one click away. A fourth mode, ELI10, is reserved for the case where nothing lands. Generated practice is split into Easy for concept reinforcement, Medium for applied thinking, and Hard labelled JEE/NEET/HSC level. What the write-up does not document is how the three styles are produced. The visible file list puts the LLM client and the response parser together in `backend/utils.py`, a single module, which points to one round trip returning all three rather than three requests a reader picks between. On that reading the trio is fixed by the prompt template in `backend/prompts.py` rather than selected by the student, and the width of every answer is paid for on every question.

The request path has five hops and two parties outside the project

The architecture diagram names the whole route: student to frontend over HTTPS, frontend to Cloudflare Tunnel by API call, tunnel proxying to a FastAPI backend on an RDP server, backend to Featherless.ai running DeepSeek-V3, then the response back along the same line. The split is deliberate and each half carries a stated reason. HTML, CSS and JavaScript go to InfinityFree, Netlify, GitHub Pages or any static host, for CDN delivery with no build step. FastAPI and Python go to an RDP box, a VPS or a cloud VM, because that side is where the API keys are hidden. Two details of the diagram deserve attention. The model is fixed by name, DeepSeek-V3 served through Featherless.ai, so a relay sits between the backend and the model provider, and that relay is the only hop in the chain whose behaviour none of the project's own configuration controls. The backend host is a Windows RDP machine, the cheapest way to get a Python process running anywhere, which also makes it the least redundant link in the diagram.

Key rotation is the only redundancy, and 99.9% is asserted

The feature table advertises API failover through multi-key rotation and attaches a number to it: 99.9% uptime. No test data, no incident history and no measurement method travel with that figure, and nothing in the top-level file listing suggests a metrics or monitoring component. The scope of the failover is also narrower than the number implies. Rotating keys covers one failure mode, a provider refusing one credential, and says nothing about the RDP host going away, the Cloudflare Tunnel dropping, or Featherless.ai returning errors. Every element of the chain is a single instance except the credential set. Version pinning is missing too: the repository publishes no GitHub releases, so there is no tag to hold onto, and the last push on the default branch main is dated 2026-05-27. The top level holds exactly four entries, `.gitignore`, `README.md`, `backend/` and `frontend/`.

Any static host, against a CORS lock

The deployment story is the strongest part of the design, and it is genuinely split. Put the frontend on any static host, run the backend on RDP, a VPS or a cloud VM, and join the two with a Cloudflare Tunnel for free HTTPS, no port forwarding and DDoS protection. The trouble sits in the seam. `frontend/config.js` is described as backend URL configuration, `backend/main.py` as API endpoints plus CORS, and the feature table says the CORS setup is locked to your domain. Those three facts together put the origin allowlist inside a Python file on the machine that holds the keys, not in the frontend being moved. Serving the frontend from GitHub Pages and leaving the backend where it is only works if your origin happens to be the one that Python file expects. The advice to deploy anywhere is conditional, and the condition is never stated, in a section that is cut off before it starts.

localStorage carries the shell, the history and the streak

Offline-capable is the label, and the mechanism sits in the same cell: localStorage for instant load. Read precisely, the app shell, the saved sessions and the favourites come back without a network round trip, while every real explanation still needs the backend, the tunnel and the model. The gamification layer sits in the same bucket: XP and levels, daily streaks, achievement badges, confetti rewards, a pet mascot, five themes including Midnight and Cosmic, and an auto-saved history. The visible part of the file tree shows no database, no account system and no authentication code, so on what a reader can see, a student's streak, their saved explanations and their theme choice live in one browser storage entry on whatever device they happened to use. Voice input and text-to-speech, the speech recognition and spoken explanation pair, put the device microphone into the same picture.

The file tree stops mid-directory and the contents list points past it

The write-up runs to a twelve-entry table of contents covering features, live demo, architecture, quick start, deployment, configuration, tech stack, security, roadmap, contributing, license and contact, but the file itself is cut off partway through the architecture section. Everything after that point is absent: no quick start, no configuration keys, no tech stack list, no security notes, no roadmap, no contributing guide, no license text, no contact block. The tree inside it is cut off too, closing after three backend files. What is visible names `frontend/index.html`, `styles.css`, `app.js`, `config.js` and a nested `README.md`, then `backend/main.py`, `utils.py` and `prompts.py`, where the block ends without its closing fence. No requirements file, no example environment file, no Dockerfile and no test directory appear anywhere in the four top-level entries, so the Python dependency set is not pinned in anything a reader can see, and how the API key reaches the running process is not shown either.

A country selector covering three curricula and two exam boards

The curriculum switch is the one place where the project makes a coverage claim rather than a mechanics claim: NCTB, SSC, HSC and Creative Questions for Bangladesh, NCERT, CBSE, JEE and NEET for India, and international standards for everyone else. The overlap shows in the difficulty tier as well, where Hard practice is labelled JEE/NEET/HSC level, so a single rung of the ladder names exam boards from two different national systems. Whether selecting a country changes the questions the model generates, or only the label attached to them, is not documented. `backend/prompts.py` is named as the home for prompt content, which is where the answer would live, and that file's contents are not part of what a reader can see. For anyone outside those two systems, the third option is the honest default and the study targets behind it are left undescribed.

Editorial conclusion

Judge this as a deployment case study rather than a product. The split between a static frontend and a FastAPI backend behind a Cloudflare Tunnel is sound for one author running one cheap box, and everything worth reading sits in that split: the CORS allowlist living in the Python file that holds the keys, localStorage as the only storage on record, and a 99.9% uptime figure that covers key rotation only. Anyone planning to run it should first establish what the cut-off configuration section would have said about the API key, and settle the license, which no file and no declared field states.

Frequently asked questions

Official sources

1. Issues
2. README
3. samiahraf/study-dost-ai on GitHub