cheating-daddy: an always-on-top assistant that answers questions you cannot

Interview is the first profile listed, and nobody on the call consented

The application is described as a real time assistant providing contextual help during video calls, interviews, presentations and meetings, using screen capture and audio analysis, and the profile list in the features makes the intent unambiguous: interview, sales call, business meeting, presentation and negotiation. The repository description calls itself a free and open source app that lets you gain an unfair advantage, which is unusually candid about the purpose. Two consequences follow from that purpose, and neither is a matter of taste. The person on the other side of the call is not a participant in the arrangement, so anything said into that call is handled by a system they have no visibility of and did not agree to. And in an interview that is not yours to lose, the person deciding is being shown a picture of a conversation that is not the one happening. Both of those are reasons to keep this on a machine you experiment with, not on the machine you take meetings on.

The first thing in the readme is a sponsorship pitch

The file opens before it says anything about the application. The opening section recommends a hosted desktop recording API, with a link carrying referral parameters, describing it as recording video conferencing platforms and in person meetings, followed by a line stating that this project is sponsored by that service. Only after that does the project's own description appear. The sponsorship is legitimate and disclosed, and a reader benefits from knowing who is funding the work, but the ordering means the first thing a visitor sees is an advertisement with the project's identity attached to it. Below the pitch there are two notices in the same style. One says to use the latest versions of the two desktop operating systems because older ones have limited support. The other is a testing caveat: during testing it will not answer if you ask it something directly, and the interviewer has to be simulated asking the question, which it will then answer.

Three runtime dependencies and a websocket

The dependency list is short enough to read in one glance, and it explains the shape of the program. There is a package for the model provider, a package that handles Windows startup registration for installed applications, and a websocket library. The model named in the features is a flash tier multimodal model from the same provider, and the setup instructions ask for an API key from the provider's own developer studio. Everything else in the project is first party code, which for an application that reads a screen, plays audio and manages a floating window is a small amount of work, and it is the reason this is a reasonable thing to read rather than a large one.

The lint script is an echo and there are no tests

The scripts section of the manifest has four real entries, all delegating to the Electron packaging toolchain for starting, packaging, making distributables and publishing. The fifth is a lint script whose entire body prints a message saying no linting is configured. That is at least honest, since a placeholder is better than a command that silently passes, but it means there is no static checking of any kind in this repository. There is also no test dependency of any sort. The development dependencies are entirely the packaging toolchain and the Electron runtime: makers for the Linux, macOS, Windows and AppImage formats, a plugin for unpacking native modules automatically, a plugin and a package for rewiring the packaged binary, and Electron itself. A project with a WebSocket connection to a cloud model, a screen capture loop and an audio pipeline has no automated verification of any of it.

Linux is listed as a supported platform and then told not to be used

The features list includes a cross platform entry naming three desktop systems, with a parenthetical immediately after saying the third one is sort of supported and should not be used because it is only there for testing at the moment. The requirements section then lists an Electron compatible operating system and names all three of the same platforms with no such caveat. So the two places a reader would check disagree, and the more prominent of the two is the dismissive one. The audio capture section shows one difference. The first desktop system captures system audio through a separate third party project, SystemAudioDump, the second uses loopback capture, and the third is limited to microphone input. Without system audio the application cannot hear the other side of the call, which is most of what makes the application work, so on the third platform it is capturing only your own half of the conversation. That is a functional gap.

The overlay is transparent to clicks as well as to the eye

Two of the features concern how the window relates to the rest of the desktop rather than what the application does. One is an always on top window that can be positioned anywhere, which is what lets it sit outside the area the video call occupies. The other is a click through mode described as making the window transparent to clicks when needed, so the pointer passes through it to whatever is underneath. Movement, dismissal and sending a message are all bound to keyboard combinations, and the repository root also includes a file of platform entitlements, which on that desktop operating system is how an application asks for permissions beyond the ordinary ones. Together these are the features that determine whether anyone in the room would know. An assistant that is visible on screen and audible in the call is at least honest about itself.

The keywords repeat themselves and the release train stalled

Two small things in the manifest are worth a sentence each. The keyword list contains five entries and two of them are identical, the same phrase about an assistant for interviews appearing twice, which suggests the list was edited by hand rather than generated. And the release history shows two tags on the same day in February, one shortly after the other, then a third release in late July with nothing between them, which is the pattern of a burst of work followed by a quiet stretch. The last push to the default branch, on 2026-10-21, came after the newest release, although the manifest version, 0.8.0, matches it. The licence is the GNU General Public License at version three, and there is an agent instruction file, AGENTS.md, at the root. None of that is remarkable for a project of this size, but the combination of no tests, no linting and a three dependency runtime says the same thing: this is a working demonstration that was built to run on the author's machine rather than to be maintained as a product.

Editorial conclusion

Read this application as a demonstration of what a live multimodal model plus a desktop overlay can assemble in a small amount of code, which is a legitimate reason to study it, because the dependency list is three packages and the interesting part is the wiring rather than the models. Beyond that framing, it is not suited to real use. It sits on top of a call and answers as though it were you, so the person on the other side of that call is being misled by someone who has not consented to it, and the outcome depends entirely on rules you may not have read. If your interest is assistive technology during long meetings, the same capture and overlay techniques apply to transcription and summarising your own meetings, which is what you should build instead.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. sohzm/cheating-daddy on GitHub