# HoYo.Gacha and the offline tracker for miHoYo pull history

> HoYo.Gacha is an unofficial desktop tool for Genshin Impact, Honkai: Star Rail and Zenless Zone Zero that imports your pull history and stores it in a local database, working without a proxy server by reading the Chromium disk cache for the gacha URL. The interesting part is the data exchange formats, since it reads and writes the UIGF and SRGF standards, and the interesting constraint is that the local database file must travel with the app.

**lgou2w/HoYo.Gacha** — ✨ 一个非官方的工具，用于管理和分析你的 miHoYo 抽卡记录。（原神 | 崩坏：星穹铁道 | 绝区零）An unofficial tool for managing and analyzing your miHoYo gacha records. (Genshin Impact | Honkai: Star Rail | Zenless Zone Zero)

- Repository: https://github.com/lgou2w/HoYo.Gacha
- Website: https://hoyo-gacha-v1.lgou2w.com
- Stars: 565 · Forks: 25
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/lgou2w-hoyo-gacha

## What the tool is, and the problem it solves

HoYo.Gacha is an unofficial tool for managing and analyzing your miHoYo gacha records, covering Genshin Impact, Honkai: Star Rail and Zenless Zone Zero. The word unofficial is doing real work in that sentence, and the README keeps it in front: the assets section describes the project as a fan-made tool, with game content and assets copyright miHoYo and all rights reserved.

The problem it solves is narrow and real. Each of the three games keeps its pull history inside the game client, and the record of what you pulled, when you pulled it, on which account, is the data players actually care about for planning and for the community's statistical records. HoYo.Gacha collects that history into a local database you can query, import and export, and it supports multiple accounts for each game and fetching the gacha URL.

The audience is a player with more than one account or more than one game, who wants their history somewhere they control rather than only inside a client that could be reinstalled.

The stack is visible in the repository topics and the file tree. It is a Tauri application, with a React frontend under app/, a Rust side under crates/ and tauri/, and a Cargo.toml declaring a workspace with resolver 3, edition 2024 and a rust-version of 1.88. The frontend uses Vite, TypeScript and Fluent UI React components, the package is managed with pnpm at a pinned version, and the licence is MIT OR Apache-2.0.

The hosted site is at hoyo-gacha-v1.lgou2w.com, which carries the v1 marker, matching the application identifier change described later in the README.

## No local proxy: the Chromium disk cache route

The most interesting technical claim in the README is stated twice, once in Chinese and once in English, and it is the reason the tool is worth a look: no need for any local proxy server, just read the Chromium disk cache file and request the API endpoint.

Most tools in this space ask you to run a local proxy so they can watch the game client's API traffic as it happens. That approach works, but it is intrusive: it has to be running before you open the game, and it intercepts traffic. This one takes a different route. The gacha URL carries the authentication information for the pull history endpoint, and the browser that ran the game client has that URL in its disk cache. So the tool reads the cache file, extracts the URL, and calls the endpoint itself.

The repository has a docs/ directory and the README links to a DiskCache document inside it, so the format handling is documented rather than left as folklore.

This has an obvious consequence. The tool is not entirely independent of the browser: it needs the game's web client to have run at least once, in a Chromium-based browser, so that the cache entry exists. On a system where the game runs through a different browser or through the native client, the cache may never contain what the tool is looking for.

The second consequence is about trust. Reading a browser cache file and then calling an API endpoint with the credentials found in it is a considerably more sensitive operation than calling an API with credentials you pasted in. The README addresses this directly in the licence note, stating that the software will not ask you for any account password information about a miHoYo account, nor will it collect any user data, and that the generated data including usage data, gacha data and UID information are all stored locally by the user. That is a claim about the tool's behaviour, and it is a claim the user can partly check, since the tool is open source and the database file sits on disk in plain sight.

## UIGF, SRGF and CSV: the exchange formats

The data exchange file formats are the part of the feature list that matters most for anyone with more than one tool, because they are the difference between a locked-in archive and portable data.

The README lists three. UIGF, the unified interchange gacha record standard, is supported across v2.0, v2.1, v2.2, v2.3, v2.4, v3.0, v4.0, v4.1 and v4.2. SRGF, the Star Rail gacha record standard, is supported at v1.0. And CSV, comma separated values, is supported for export only.

The breadth of UIGF versions is worth noting. Nine versions is a lot of format surface, and it means the tool can read files produced by other tools over a long period rather than only the current spec. If you have exported records from a different tracker, there is a reasonable chance this will read them.

The asymmetry on CSV is deliberate and sensible. CSV has no schema, so writing it out is easy and reading it back reliably is not, and the tool chooses not to pretend otherwise.

Both standards are hosted on uigf.org, which is where the format definitions live, and the README links them directly rather than restating the schemas. That is the right call for an implementation: the standard is the reference, and the tool is one implementation of it.

The practical takeaway is that you are not locked into this application's file format. You can export in a community standard, move to another tracker, and come back.

## The v1 rewrite, the database file, and the migration path

The README documents an important change, and the fact that it is written as a list of before-and-after values makes it easy to miss.

The application identifier changed from com.lgou2w.hoyo.gacha to com.lgou2w.hoyo.gacha.v1, and the database file changed from HoYo.Gacha.db to HoYo.Gacha.v1.db. Both renames exist to make the new generation of the app distinguishable from the old one at the operating system level, so the two versions can coexist rather than silently clobbering each other.

That coexistence is why there is a migration path, and the README describes it step by step. Open the new version of the tool, click the gear-shaped Settings button in the lower left corner, find the Database Migration bar at the top, click the Migrate button on the right, select and open the old version database HoYo.Gacha.db file, and wait for the migration to complete automatically.

The database file itself deserves attention because the README gives it a prominent warning. The program automatically creates a file named HoYo.Gacha.v1.db in the run directory, and that file contains all your local accounts and all gacha records data. The instruction is to make sure not to miss this database file when moving the program or migrating the operating system.

That is a real operational constraint. A database that lives in the run directory rather than in a user data directory is convenient for portable use, since the whole folder can be moved to another machine, but it means the data is only as durable as the folder. Copy the executable without the .db file and you have an app with an empty database and no obvious warning.

The update policy has also loosened. Starting with version 1.2.0, application updates are no longer mandatory, though the README still asks users to download and update to the latest version promptly for a better user experience and security fixes. The latest tagged releases are 1.2.8 from 2026-05-04, 1.2.9 from 2026-05-20 and 1.2.10 from 2026-07-27.

## Building it from source: two toolchains in one repository

The package.json shows a project that has to satisfy two build systems at once, and the script names make the split obvious.

The app side is Vite and TypeScript. The dev script starts cross-env NODE_ENV=development vite, the build script runs cross-env NODE_ENV=production tsc and then vite build, and the test script is vitest run with the --passWithNoTests flag. The lint script runs eslint with --max-warnings 0 and --report-unused-disable-directives, which is a strict configuration where a warning fails the run.

The Rust side is Tauri. The dev script runs tauri dev with the prod-develop feature and the RUST_BACKTRACE and RUST_LOG environment variables set, the build script is tauri build, the test script is cargo test, and the lint script is cargo check.

The top-level scripts compose the two with a namespaced convention, so a full development run is one command:

```json
    "dev": "concurrently --raw --kill-others \"pnpm:app:dev\" \"pnpm:tauri:dev\"",
    "build": "pnpm app:build && pnpm tauri:build",
```

The concurrently invocation with --raw and --kill-others is the interesting detail: it runs the frontend and the Rust host at the same time and kills both when either exits, which is what you want for a Tauri app where the Vite dev server and the shell are one process from the developer's point of view.

The Cargo workspace is small and structured. It declares resolver 3, members crates/* and tauri, and shared workspace dependencies including reqwest, sqlx at 0.8.6, serde, serde_json, snafu for error handling, sha1, rfd for native file dialogs, and tauri at 2.11.5 with plugins for the clipboard manager and the process API.

The engines field requires Node ^22 or >=24 with pnpm >=10, and the package manager is pinned to pnpm 11.17.0 with an integrity hash, so the frontend toolchain is reproducible across contributors.

## Windows requirements, signing and where the limits are

The download section is specific about the target platform. The requirements are Windows 10 x64 v1809, build 17763 or later, and the WebView2 Runtime at 121 or later. There is no Linux or macOS release mentioned, and the WebView2 dependency is a consequence of the Tauri choice: on Windows, a Tauri application renders through the Edge WebView2 runtime, which is present on a modern Windows install but is still a separate versioned dependency.

The binaries are published on the repository's Releases page, and code signing on Windows is handled by SignPath.io, with the certificate provided by the SignPath Foundation, according to the sponsorship section. Netlify provides the document and home page hosting. So the release artefact is signed, which matters more than it might seem for a desktop application that reads a browser cache file: an unsigned or unverifiably signed binary asking for filesystem access is a much harder thing to trust.

The limitations come down to four things.

First, the platform. Windows only, with a minimum version floor and a WebView2 requirement, so anyone on macOS or Linux is out, which is a large share of the people who play these games.

Second, the dependency on the browser cache. The tool needs a Chromium disk cache to contain the gacha URL, which means the web client has to have been used on that machine, and the cache format is a browser implementation detail rather than a documented game API.

Third, the unofficial status. The endpoint it calls and the format of the response are not contractual, so a game update can break it, and there is no upstream to file that bug with.

Fourth, the licence terms. The README states MIT OR Apache-2.0, but adds a note that it is for personal study and communication use only and asks that it not be used for any commercial or illegal purposes, which is a restriction on top of the standard licence grant. For personal use that is not a problem, and for anyone considering building on the code it is the clause to read first.

## Conclusion

HoYo.Gacha is a good fit for a player who wants their pull history in one place across the three miHoYo games, with a local database and import and export in the community exchange standards rather than a screenshot folder. It is a poor fit if you need the tool to work without ever touching the game client, because the documented path to obtaining the gacha URL goes through the Chromium disk cache, and a poor fit on anything other than Windows, since the release requirements name Windows 10 x64 v1809 and the WebView2 Runtime. Before adopting, back up HoYo.Gacha.v1.db, because the README says that file holds all your local accounts and all gacha records and warns specifically against losing it when moving the program or migrating operating systems.

## FAQ

### Which games does HoYo.Gacha support?

It supports Genshin Impact, Honkai: Star Rail and Zenless Zone Zero, with support for multiple accounts per game and fetching the gacha URL. The project describes itself as an unofficial fan-made tool whose game content and assets remain copyright miHoYo.

### Does HoYo.Gacha need a local proxy server?

No. The README states that no local proxy server is needed, and that the tool works by reading the Chromium disk cache file and requesting the API endpoint. The disk cache handling is documented in the repository's docs/DiskCache.md.

### Which data exchange formats does HoYo.Gacha support?

It imports and exports UIGF, the unified interchange gacha record standard, in versions v2.0 through v4.2, and SRGF, the Star Rail gacha record standard, at v1.0. CSV is supported for export only.

### What are the system requirements for HoYo.Gacha?

Windows 10 x64 v1809, build 17763 or later, and the WebView2 Runtime at 121 or later. The latest build is downloaded from the repository's Releases page.

### How do I migrate my data from the previous version of HoYo.Gacha?

Open the new version, click the gear-shaped Settings button in the lower left corner, find the Database Migration bar, click Migrate, select the old HoYo.Gacha.db file and wait for the migration to complete automatically.

### Where is my gacha data stored in HoYo.Gacha?

In a file named HoYo.Gacha.v1.db created in the run directory, which holds all your local accounts and all gacha records. The README warns not to miss this file when moving the program or migrating operating systems.

## Sources

- [lgou2w/HoYo.Gacha on GitHub](https://github.com/lgou2w/HoYo.Gacha)
- [License: Apache-2.0](https://github.com/lgou2w/HoYo.Gacha/blob/main/LICENSE)
- [Project website](https://hoyo-gacha-v1.lgou2w.com)
- [README](https://github.com/lgou2w/HoYo.Gacha/blob/main/README.md)
- [Releases](https://github.com/lgou2w/HoYo.Gacha/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lgou2w-hoyo-gacha