OpenBidKit Yibiao: an open source AI bid-writing toolkit for Chinese tender documents

What OpenBidKit Yibiao solves, and for whom

Writing a Chinese technical bid is mostly assembly work under deadline. A tender document arrives with scoring criteria, mandatory response items and a required structure. Someone copies last year's proposal, rewrites the sections that changed, and hunts for the clauses that disqualify a bid if unanswered. The README states the project exists because paid AI bid tools charge per document and free ones produce poor output. The stated goal is an out-of-the-box bid writer that a small company can run without a per-document fee.

The audience is narrow and specific. It is a bid manager or a technical writer at a Chinese company that submits tenders, working on Windows, who is comfortable installing a desktop application and pointing it at a model endpoint. The README's feature list is written for that person: 招标文件解析 with 18 parse items, multi-lot and multi-stage bidding, existing-proposal expansion, a local knowledge base, duplicate checking across several bids, and a 废标项检查 workspace for disqualifying items. The project is not a general document generator, and the README makes no attempt to sell it as one.

How the Electron client, Pi Agent and SQLite fit together

The architecture section of the README describes four layers. Electron Main and Preload expose local capabilities, and the Renderer reaches them through window.yibiao. The interface is Vite, React and TypeScript with global CSS and Radix UI. Configuration lives in local files while business state goes into SQLite, and long-running tasks execute in the Main process with recovery support. AI requests are centralised in an AI Service, and agent work runs in a separate Pi Agent Runtime and Session.

That split explains a behaviour the README highlights: parsing and generation tasks continue writing to disk, so switching pages does not lose progress. It also explains the local-first claim. Configuration, cache and generated results stay on the machine, which matters when the input is a confidential tender. Document parsing runs either locally or through a MinerU configuration, and Open XML plus local image rendering handle the Word side. A Cloudflare Worker serves announcements, resources, plugins, model information, licence checks and statistics, so the desktop client is not fully offline by default: that Worker is a network dependency the README lists without describing what happens when it is unreachable.

The token arithmetic in the README is the clearest statement of scale. It reports a test with gpt-5.6-terra producing a 110,000-character proposal at 2,187,250 tokens for about 1.03 yuan, excluding illustrations. Treat that as the project's own figure, not a benchmark you can transfer: your cost depends on your model, your pricing and how much of the proposal is expanded from existing material.

Installing OpenBidKit Yibiao and generating a first proposal

For normal use, the README points to GitHub Releases and says to download the latest version and run the installer or executable. There is also a hosted experience at yibiao.pro, and a third-party web version linked from the README, but the desktop client is the primary artifact.

To build from source, the desktop code sits in client/ and the README recommends Node.js 22. Debugging Open XML features or building a local package additionally requires the .NET 10 SDK. The install and dev commands are given in PowerShell:

cd client
npm ci
npm run dev

After npm ci finishes, npm run dev starts the Vite and Electron development session. The README notes that the Pi Agent SDK and the command tools it needs ship with the project, so there is nothing extra to install for agent tasks.

Packaging uses the same directory. These three scripts are the ones the README lists, and the output lands in client/release/:

cd client
npm run build
npm run dist:win
npm run dist:mac

The README describes npm run build as the TypeScript check and Vite build, npm run dist:win as the Windows x64 installer and ZIP, and npm run dist:mac as the macOS Intel and Apple Silicon DMG and ZIP.

For a first real use, the workflow implied by the feature list is: open a workspace, import the tender document, let the parser extract the 18 items, configure a text model and an image model, then generate the technical proposal section by section. The README also lists an export format setting with preset templates. It does not document a first-run wizard, so expect to configure the model endpoint before anything generates.

Where the documentation stops short

The README is a feature inventory, not an operations manual. Several claims are listed as single lines with no procedure behind them. Duplicate checking across multiple bids, the 废标项检查 workspace and the typo and logical-fallacy checks are named under completed features, and the README describes the risk-check area as a reserved entry point focused on repeated expressions and response completeness. How a check is scored, what it flags, and whether a human reviews every hit is not stated. For a tool whose output goes into a legally binding submission, that gap is the biggest one.

Model behaviour is another open edge. The README says any OpenAI-like API works, plus local models through ollama or lm studio, and that a Pi Agent handles agent tasks. It does not say which models were validated, what context length a full proposal needs, or how the agent behaves when a model returns malformed tool output. The cost figure uses gpt-5.6-terra, which tells you the project tested at least one hosted model, not that your endpoint will behave the same.

Platform support is asymmetric. npm run dist:win targets Windows x64 and npm run dist:mac produces DMG and ZIP files, but the feature table frames the local workspace as suitable for Windows bid file processing, and the .NET 10 SDK requirement appears in the Open XML debugging path. If your team is on Linux, nothing in the README indicates a packaged build.

Finally, the README links releases to a different repository path than the one this article covers, and describes a third-party web version. Confirm you are downloading the artifact that matches the client you intend to run.

OpenBidKit Yibiao against a general chat assistant

The obvious alternative is not another bid tool. It is pasting the tender into a general chat assistant and asking for sections one at a time. That approach is free at the margin and needs no install, and for a two-page response it is genuinely faster.

The difference is state. A chat window forgets the tender the moment the conversation grows, and it has no structured place to hold the 18 parsed items, the company knowledge base, or a global fact set that the README lists as a feature for keeping the whole proposal consistent. OpenBidKit keeps that state in SQLite and in local files, which is why it can run a consistency check across the finished document and resume a parse after you navigate away. It also produces Word output through Open XML and preset export templates rather than text you paste into a document yourself.

You pay for that structure in setup time and in the licence. A chat assistant has no AGPL obligations and no Node.js 22 requirement. If your proposals are short, repetitive and already templated, the structured pipeline is overhead. If they run to tens of thousands of characters with a scoring table that must be answered item by item, the state management is the reason to use it.

Licence and the cost of staying current

OpenBidKit Yibiao is licensed AGPL-3.0. The practical consequence for a company is that if you modify the client and let users interact with it over a network, the AGPL's source-disclosure condition can reach your modified version. Running the unmodified desktop client internally is a different situation from forking it into a hosted service. This is a description of the licence text, not legal advice; if you plan to embed the client in a product, have your own counsel read the terms. The repository also carries a NOTICE file, which is worth reading alongside the LICENSE.

Maintenance looks current on the evidence available. The last push was on 2026-08-28, and three releases landed within two days of it (v2.25.20, v2.25.21 and v2.25.22), which suggests a fast patch cadence rather than a stable one. A version number that advances three times in two days means you should expect to update often, and the README does not document a migration path for local SQLite state or for configuration files between versions. Back up the workspace before upgrading. The Cloudflare Worker dependency also means part of the product, including licence checks, is controlled by the project rather than by you.

Who should take OpenBidKit Yibiao seriously

The case for adopting it is strongest for a small Chinese bid team that already has a body of past proposals, writes on Windows, and wants the generation to happen against its own models. The local knowledge base and the existing-proposal expansion feature are the parts that compound: the more history you feed in, the less the model has to invent. The AGPL-3.0 licence is workable for internal use, and the absence of per-document pricing removes the cost objection the README opens with.

The case against is equally clear. If you need a hosted, multi-user tool with an audit trail, this is a desktop client with local state. If your bids are short, a chat assistant plus your existing template is less work. If you need Linux packages, the README does not offer them. And if you need documented behaviour for the risk checks before you trust them on a live submission, that documentation does not exist yet.

What to verify first, concretely: run one real tender through the parser and confirm the 18 items match your scoring table; check that your model endpoint handles the token volume the README's cost example implies; and open the export templates to confirm the output matches your buyer's required format. Those three checks will tell you more than the feature list does.

Editorial conclusion

Adopt OpenBidKit Yibiao if you already write Chinese technical proposals by hand, you are willing to run an Electron app on Windows, and you want the generation pipeline and the company knowledge base to stay on your own machine under an AGPL-3.0 licence. Do not adopt it if you need a hosted multi-user product, if your proposals are short enough that a chat window is faster, or if you cannot accept the licence terms for a closed internal fork. Before committing, verify three things on a real tender: that the 18-item parse extracts your scoring table correctly, that your chosen model endpoint accepts the volume of tokens a full proposal implies, and that the export template matches the format your buyer requires.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes