Download & install (end users)

Go to Releases and download: - macOS: OpenLess_<version>_aarch64.dmg (Apple Silicon) or OpenLess_<version>_x64.dmg (Intel) — open, drag to /Applications, then run this once in Terminal to bypass Gatekeeper "damaged" warning (the build is ad-hoc signed, not Apple-notarized):

  xattr -cr /Applications/OpenLess.app
  

  brew tap appergb/openless https://github.com/appergb/openless
  brew install --cask openless
  xattr -cr /Applications/OpenLess.app

  # Upgrade to the latest version
  brew update && brew upgrade openless
  

On first launch, grant the permissions the app requests:

macOS: 1. Grant Microphone access. 2. Grant Accessibility access. 3. Quit and reopen the app — Accessibility only takes effect after a restart. 4. Open Settings → fill in Volcengine ASR + Ark credentials.

Windows: 1. Grant Microphone access when prompted. 2. Open Settings → Permissions to verify the global hotkey listener is active. 3. Fill in Volcengine ASR + Ark credentials in Settings.

Full end-user walkthrough: USAGE.md.

Build from source (developers)

The active codebase is in openless-all/app/ (Tauri 2 + Rust + React/TS). The macOS build links a vendored C ASR engine (Open-Less/qwen-asr, forked from antirez/qwen-asr) pulled in as a git submodule under src-tauri/vendor/qwen-asr/, so initialize submodules on first clone.

```bash

macOS release build (signs, installs, resets TCC)

./scripts/build-mac.sh INSTALL=0 ./scripts/build-mac.sh # build only, skip install

Rust type-check without full compile

cargo check --manifest-path src-tauri/Cargo.toml

A concrete example

Hold the hotkey, say to OpenLess:

uh… so… I want ChatGPT to write me a SQL query, from the orders table get last month's orders, group by customer, sort by amount desc, top ten

Release the hotkey. A second later your input box reads:

Please write a SQL query that:

- Pulls orders from last month from the `orders` table.
- Groups by customer.
- Sorts by total amount, descending.
- Returns the top 10 rows only.

No edits needed. Hit Enter and ask GPT. That's the whole pitch: write prompts with your mouth, faster and cleaner than typing them.

Use cases

• Writing prompts for ChatGPT / Claude / Cursor / Gemini: dictate a request, OpenLess turns it into a structured, detailed prompt.
• Drafting emails, specs, long Slack/WeChat messages: removes filler, fixes punctuation, organizes paragraphs.
• Code comments, commit messages, PR descriptions: dump what's in your head straight to the cursor.
• Any "I don't want to type but I have to produce written text" situation.

First clone only — pull in vendored submodules

git submodule update --init --recursive

cd "openless-all/app" npm ci

Contributing workflow

OpenLess uses a two-channel branching model.

• beta — the Beta channel. Default branch and integration buffer; all in-progress development lands here. Beta builds may exist but are not pushed to regular users — they only reach people who explicitly opt into the Beta channel.
• main — the Stable channel (正式版). Always-releasable. The build everyone gets by default.

your fork / topic branch
        │  (test locally on your target platform first)
        ▼
   PR → beta  ← AI review (one pass, advisory only)
        │     ← maintainer lightweight glance (scope, cross-module impact)
        ▼
       merged into beta
        │  (periodically, after a two-platform smoke build)
        ▼
       merged into main  →  tag `v<version>-tauri`  →  release CI → Stable users

Rules of thumb:

• Open PRs against beta, never against main. GitHub already defaults the base branch to beta for new PRs.
• Verify the change on your target platform before opening the PR — build green is necessary, manual verification is required.
• AI review runs once per PR and is advisory. Don't loop on it. Apply your judgment.
• Keep AI rework rounds tight (1–2). If a fix resists, ask a human or restart with fresh context — multi-round AI back-and-forth tends to do more harm than good here.
• Beta work must not leak to Stable. main only receives merges from beta, performed by maintainers after a successful two-platform smoke build. No direct pushes to main.
• Stable releases are cut from main by pushing a v<version>-tauri tag — see the maintainer release checklist below.

Beta release distribution (manual-download opt-in): the in-app updater always reads the Stable manifest, so regular users never get Beta builds via auto-update. Users who want to try Beta open Settings → About, flip "Join Beta channel", and download the latest Beta installer manually from the link the app fetches from GitHub. Tag convention: v<version>-beta-tauri produces the Beta release (marked GitHub pre-release; manifest written as latest-{tgt}-{arch}-beta.json); v<version>-tauri produces the Stable release. The two manifest files never overlap, so Stable users' updater feed cannot pick up Beta releases.

Comparison