Shiping: a desktop assistant that reads your screen and answers questions about it
面试助手,考试助手,在「面试」或「在线考试」时,借助AI实时提供解题思路
At a glance
- What is it?
- Shiping, previously the screenshot question answering assistant, is an Electron application that captures a screen region, sends it to a vision model you configure yourself, and streams back an answer, with a second mode that transcribes a conversation and produces a short spoken reply. It runs on your own API key, and the licence the package manifest declares is CC BY-NC 4.0.
- Who is it for?
- Shiping suits someone who wants to ask a vision model about what is on their screen, without pasting screenshots by hand, and who is comfortable bringing their own API key and paying per use. It does not suit a workplace where an unapproved assistant window on the screen is itself a problem, and the conversation mode deserves a hard look before it is used anywhere with an exam proctor or an employer policy.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 7, 2026, and from our analysis. They are not legal advice.
Star history
- ooboqoo/shiping1,174 ★ · +113
| Repository | 2026-10-21 | 2026-11-07 |
|---|---|---|
| ooboqoo/shiping | 1.1k | 1.2k |
113 Stars in the last 17 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
Two modes, and the second one is a different product
Shiping does two things that share a window but not much else. Screenshot mode is the core: a hotkey captures part of the screen, a vision model understands what is on it, and the answer streams in, with the ability to add another screenshot and ask a follow-up so the context stays continuous. Conversation mode is the newer addition, and it works on sound rather than pixels. It listens to what the other person says, and as soon as they finish a sentence it produces a short reply hint, described as an opening line you could say out loud plus a few bullet points. The two have different requirements, and the documentation is explicit about them. Screenshot mode needs a model that can read images, and the settings mark models that cannot. Conversation mode sends text only, so it wants a fast model with thinking turned off, and it needs an additional key for speech recognition from the Aliyun Bailian platform. The two modes pick their own model and prompt, and you can switch between them mid-session, which is the described flow for a video interview where a project discussion becomes a shared coding problem.
The rename from interview-coder-cn happened in October 2026
The project was renamed, and the reason is worth noting because it changes what the repository is called. The original name was a screenshot question answering assistant, in the repository interview-coder-cn, and from October 2026 it is Shiping, in the repository shiping. The functionality did not change, and the documentation states that existing settings are preserved after upgrading. The version history is where this shows up. From v3 there is a conversation mode, and only v3 is maintained, on the main branch. The v2 version, which only had the screenshot solving feature, is kept on a separate v2 branch, is no longer updated, and its installer is at the v2.1.0 release. That is a tidy way to handle a rename without breaking anyone's upgrade path, and it also means the tag and branch names in the repository reflect a project that has reorganised itself at least twice. The release history shows three versions on the same day in October 2026, v3.2.2, v3.3.0 and v3.4.0, which is a fast cadence for a desktop application.
You bring the model, and the settings screen tells you if it can see
There is no subscription and no bundled model. On first launch the application asks for an API Base URL and an API Key, and any platform that speaks the OpenAI API works, with the documentation naming SiliconFlow, DeepSeek, OpenRouter and OpenAI itself, where only the key is needed. You can save several configurations under Settings, AI models, and then assign them separately to the screenshot group and the conversation group. That separation matters, because a vision model and a fast text model are different products and the cost profile is different too. Some platforms and gateways need extra request headers beyond the key, for example the api-key header at Azure or the cf-aig-authorization header at Cloudflare AI Gateway, and those go into an advanced section where you enter one name and value per line. The custom headers are what make the OpenAI-compatible claim work in practice against gateways that are not quite OpenAI compatible. The dependency list confirms the shape of the client, with the ai package and the OpenAI-compatible provider adapter rather than a direct HTTP client of the project's own.
The app itself is Electron with electron-vite and electron-builder
The build tooling is visible in the package manifest and it is a modern Electron setup. The scripts cover the usual loop, and they are worth reading because they show the split between the two type environments an Electron application needs:
"typecheck:node": "tsc -p tsconfig.node.json",
"typecheck:web": "tsc -p tsconfig.web.json",
"typecheck": "npm run typecheck:node && npm run typecheck:web",
"start": "electron-vite preview",
"dev": "electron-vite dev",
"build": "npm run typecheck && electron-vite build",
"postinstall": "electron-builder install-app-deps",
"build:unpack": "npm run build && electron-builder --dir",
"build:win": "npm run build && electron-builder --win",
"build:mac": "electron-vite build && electron-builder --mac"The main process entry is the compiled out/main/index.js, and the build script runs the two typecheck passes before electron-vite build, so a type error stops the build rather than shipping. The packaging is electron-builder, with a build:unpack target that produces a directory rather than an installer, which is the one you want for debugging a packaged app. The interface is React with Radix UI primitives and a Tailwind-style utility setup, and there is a components.json file, which is the shadcn configuration that goes with that set of primitives. The manifest declares the package manager as npm with a fail on error, and the repository also carries an electron.vite.config.ts, an eslint flat config and a Prettier config.
Conversation mode records system audio and rewrites a premature hint
The conversation mode has a detail that shows real use behind it. By default it is automatic: a hint appears the moment the other person stops talking, and if they were not actually finished, that hint is withdrawn and rewritten into the same card once they do stop. Sentences that are too short, like a simple yes or no, do not trigger it. There is also a manual mode where a hint only appears when you press the key, and in both modes you can press for a hint immediately without waiting, and pressing again with nothing new rephrases the previous one. The audio it listens to is the system audio, so in a video interview it hears the other side of the call, and your own voice does not trigger a hint. The pause length and the word count that decide someone has finished are configurable. If you want to review afterwards, a setting saves the transcript and the hints as Markdown files, one per conversation, in a documents folder named after the application. The speech recognition is described as using the Fun-ASR realtime model on Aliyun Bailian, at roughly 0.02 yuan per minute with a free allowance for new users.
The phone mirror is a read-only window with a QR code that acts as a password
One feature is unusual enough to be worth reading carefully. With phone sync enabled, the screenshot answers and the conversation hints are mirrored in real time to a phone browser, so nothing has to be left on the computer screen. There are two transports. On a local network the phone and the computer join the same Wi-Fi and you scan a QR code from the settings page. Over the public internet, for when the phone is on mobile data, you run a relay service on a server of your own, with the deployment described in the relay directory. The security story is handled with some care, and there are real warnings. The computer's address changes when you change networks, so you rescan. The phone cannot reach the computer through a router's guest network, and a proxy or VPN on the phone has to be off. The QR code only shows in the settings page and is not visible during a screen share, but the link it encodes works as a read-only password, so it should not be forwarded, and there is a button to replace it. The address uses http, so the content travels in plain text on a public Wi-Fi, and the relay can be put behind HTTPS.
A firewall rule, and the reason the phone cannot connect
One troubleshooting item in the documentation is concrete enough to be worth understanding, because the symptom it fixes, the computer opens the address and the phone does not, is the classic symptom of a firewall. The advice is to allow the application through the firewall for the current network in the Windows security centre, or to add an inbound rule in an administrator PowerShell that opens TCP port 8790, restricted to the private profile and to the local subnet. The scoping is the right shape: it opens the port for nearby machines on a trusted network rather than to the internet. On macOS the equivalent is to allow incoming connections for the application under the firewall options in the system settings. The whole page of guidance is written from the assumption that this application might be on screen during a screen share, and the same page notes that the window is hidden from a screen share, that the interface is in Chinese, and that the mouse can pass through the window so the page underneath keeps focus.
Where this is the wrong tool, and what the licence permits
Two limitations are worth stating plainly. The first is the licence and the mode split. The package manifest declares the licence as CC BY-NC 4.0, which permits non-commercial use and forbids commercial use, while the licence field on the repository records a custom licence that GitHub cannot classify, so the two do not agree and the manifest is the more precise statement. If you were planning to use this at work, the non-commercial clause alone is a problem. The second limitation is the conversation mode's purpose. The documented scenarios include online exams and online programming tests, and the tool is explicitly built to work during a screen share where the other party cannot see its window. Whether using it during a proctored assessment is acceptable is a question about the rules of the assessment, not about the software, and the same applies to the interview modes, where a real interviewer's evaluation of your skills is the point. The screenshot mode, used on your own code and your own error messages, has no such ambiguity. On that note, the documentation is genuinely useful about cost: bringing your own key means the spending is visible, and the recommendation is to keep the document library under about 30,000 characters per mode, since more data makes answers slower and more expensive, while platforms such as DeepSeek and OpenAI cache repeated prefixes automatically so consecutive questions are cheaper.
Editorial conclusion
Shiping suits someone who wants to ask a vision model about what is on their screen, without pasting screenshots by hand, and who is comfortable bringing their own API key and paying per use. It does not suit a workplace where an unapproved assistant window on the screen is itself a problem, and the conversation mode deserves a hard look before it is used anywhere with an exam proctor or an employer policy. Before installing, check the licence, which the package manifest declares as CC BY-NC 4.0 and which the repository itself records as a custom licence, and decide which mode you actually need, since only the screenshot mode works without a second service.
Frequently asked questions
What is Shiping and what does it do with my screen?
It is a desktop application that captures a region of the screen, sends it to a vision model you configure through your own API key, and streams an answer back. You can add another screenshot and ask a follow-up so the context stays continuous, and the application runs on your own API key with no subscription.
What is the difference between screenshot mode and conversation mode?
Screenshot mode reads the screen and needs a model that can see images. Conversation mode transcribes what the other person says and produces a short reply hint, and it needs a fast text model with thinking off plus an Aliyun Bailian key for speech recognition. Only the screenshot mode works without that second service.
Can I see the answers on my phone instead of my computer?
Yes, with phone sync enabled the answers and hints are mirrored in real time to a phone browser in read-only mode. It works over the local network by scanning a QR code, or over the public internet through a relay service you run yourself, and the QR code link works as a read-only password, so it should not be shared.
Which platforms can I use as the AI backend?
Any platform that speaks the OpenAI API, with the documentation naming SiliconFlow, DeepSeek, OpenRouter and OpenAI itself, where only an API key is needed. Some gateways also need extra request headers, for example the api-key header at Azure, and those go into the advanced custom headers setting, one name and value per line.
Official sources
Was this useful?