Arknights Toolbox: planning upgrades and base skills in the browser

A companion tool for a game with a spreadsheet problem

Arknights Toolbox is a web application for the mobile game Arknights, and the project states that all servers are supported and that the toolbox data updates automatically when the game data is unpacked. The stated purpose is to be simple, good looking and friendly to mobile devices, and to follow Material Design.

The problem it solves is arithmetic and bookkeeping. Arknights is a game where an operator is levelled with a material called dog food and a currency called Lungmen Dollars, a skill is upgraded to a chosen level, a module is attached, and a base skill has to be picked from a long list. Each of those decisions needs a count of items, and the counts get large enough that a player ends up maintaining a spreadsheet. The toolbox moves that arithmetic into the browser.

The delivery model is worth noting before anything else, because it shapes the whole experience. There is a finished deployment at arkntools.app, with an alternative address at arknbak.lolicon.app, and the project has been turned into a progressive web app, so it can be added to the home screen on each platform and used offline. The licence is MIT and the primary language is Vue.

The topics on the repository name calculator, planner and toolbox, which is a fair summary: this is a set of calculators with a shared data set, not a companion client that talks to the game. Nothing here modifies the game, and nothing here requires the game to be running.

Four calculators covering recruitment, promotion, levelling and base skills

The feature list is organised as four tools, and each one attacks a different part of the game loop.

Public recruit calculation is the first. It supports screenshot recognition, so you can photograph or capture the tags a recruit banner is offering and get an answer rather than guessing from memory, and it links straight to the wiki. The private information that this tool reasons about is what a banner might contain, which is why a screenshot is the natural input.

Elite material calculation is the second and the most involved. You search for an operator, choose the promotion stage, the skill and the module, and the tool assembles the required materials. It can import your warehouse material counts from Senkongdao, it can read a warehouse screenshot, and it can plan which stages to farm, using drop data provided by Penguin Logistics. It also supports signing into a Yituliu account for cloud sync, so the inventory figures are not retyped on every device.

Operator upgrade calculation is the third. It computes the dog food and Lungmen Dollars needed to bring an operator to a chosen level, and converts that into the number of resource stages that have to be run, which is the form the answer is actually useful in. It supports merging several upgrade requirements into a single calculation, so upgrading four operators at once does not mean adding up four separate answers by hand.

Base skill filtering is the fourth. You narrow the list by facility or by skill type, search by text, and the results are sorted by effect, with a shortcut to the wiki for the full description. The value here is comparison: with a long list of skills per facility, the question is usually which few apply, not what any single one does.

Screenshot recognition, and where the OCR actually runs

Screenshot input appears in two features, the recruit banner and the warehouse inventory, and the dependency list shows what that costs.

The package.json lists @arkntools/paddlejs-ocr, a Paddle.js based optical character recognition build, and @arkntools/depot-recognition, a recognition package for the depot, which is the game's term for its storage. The credits section names OCR Space as the OCR source, and the credits also point to OpenArknightsFBS for the data schema, so the recognised text is parsed against a known structure rather than read as free-form prose.

The other interesting dependency is @arkntools/userscript-extension, which is a bridge to a userscript, and the feature list mentions signing in to a Yituliu account for cloud sync. That is the mechanism behind the cross-device part of the toolbox: inventory figures live with the account rather than in the browser storage of one device.

Storage is handled with a stack of libraries rather than one. localforage, localforage-getitems, localforage-setitems and localforage-removeitems handle bulk reads and writes, idb-keyval is another key-value store, browser-image-resizer shrinks screenshots before they are processed, and encoding-japanese handles character encoding, which matters for the Japanese and Korean servers. dayjs handles dates, js-base64 and js-md5 handle encoding and hashing, and natural-orderby sorts version-like strings the way a person would expect rather than alphabetically.

A linear programming solver, javascript-lp-solver, is in the list, and the natural place for it is the farming plan: given a target material and the stages that drop it, work out which combination of runs reaches the target with the fewest or cheapest runs. The documentation does not say so explicitly, so treat that as the likely purpose rather than a documented one.

A Vue 2 app with pinia, vue-i18n and a service worker

The stack is worth reading closely, because some of it constrains what a maintainer can do.

The framework is Vue 2.7.16, with vue-router 3.6.5 for routing and pinia 2.3.1 for state. Vue 2.7 is the final release of the second major version, and the dependencies around it, vue2-datepicker and vue2-teleport, are clearly written for the same generation. The interface components come from mdui, and vue-gtag handles analytics, vue-i18n 8 handles translations, and @vueuse/core and vue-observe-visibility supply utility composables and visibility tracking. vue-easy-dnd handles drag and drop, which is what makes the operator selection and skill filtering feel direct.

Offline support is implemented with register-service-worker, and the .env file and netlify.toml at the repository root, together with a GitHub workflow for pages deployment, indicate the built output is published as static files. That combination, static output plus a service worker, is what makes the add to home screen behaviour work with no application server involved.

The build itself runs through the Vue CLI, and the scripts in package.json are short:

  "scripts": {
    "serve": "vue-cli-service serve",
    "serve:dist": "serve dist",
    "build": "vue-cli-service build",
    "zip": "node scripts/zip.mjs",
    "lint": "cross-env NODE_ENV=production vue-cli-service lint"
  },

The zip script is not obvious and is worth noting: the project packages its own output with node scripts/zip.mjs, which is a distribution step rather than a test or a build artefact. There is a separate build variant, build:gt-node-16, which sets NODE_OPTIONS to the OpenSSL legacy provider, which is the usual workaround for the old webpack hashing algorithm on newer Node versions. The repository also has a plugins/ directory, a tools/ directory, a public/ directory with the application assets including the icons, and a .yarnrc with a yarn.lock, so the package manager is yarn.

Where the numbers come from, and why that matters

Every number this toolbox produces is only as good as the data behind it, and the credits section is unusually specific about the sources.

The drop data for the farming planner comes from Penguin Logistics statistics, a community site that aggregates drop rates. The material value data and the cloud sync come from the Yituliu site, and the strategy for optimal material acquisition is credited to a post on an NGA forum. The game data schema comes from OpenArknightsFBS. The origin of the project itself is credited to a person called Huige Mao, and two earlier data and image repositories are listed with strikethrough, which reads as a change of source rather than a removal of credit.

The data updates automatically when the game data is unpacked, which is the mechanism that keeps the toolbox current without the maintainer hand-entering every new operator. That is the right design for a game whose content arrives on a schedule, and it is also why the project can be useful without a large maintenance commitment.

What the sources mean for trust is worth stating plainly. Community drop statistics are an average over reported runs, which is a different thing from a guaranteed rate, and a planner built on them is telling you the most efficient route according to aggregate data rather than a guaranteed outcome. A new operator released after the last data update may also be missing until the next sync. Neither of these makes the tool wrong, but both change how you should read its output.

The credits also make the legal position explicit. The organisation avatar and the application icons were drawn and licensed by an artist and may not be used outside the project without permission, and the game resources used by the project, including images and text or translations of it, belong to Hypergryph and its affiliates and are used only to present the game data better. The project is MIT licensed as code, and that licence covers the code and not the game assets, which is the usual arrangement for a fan tool and worth understanding before you redistribute anything.

Where Arknights Toolbox is the wrong tool

The first limitation is that it is a browser tool, not a native client. Everything runs in a page, with data in local storage and the cloud sync optional, which means a group of players sharing a spreadsheet has no shared state unless they all sign in to a Yituliu account. There is no desktop build, and the project description is a website and a PWA, so if you want the tool in a window next to the game on a second monitor, this is not that.

The second is the OCR dependency. Screenshot recognition is the feature that makes the tool fast, and it is also the feature most likely to be wrong. A screenshot taken at the wrong resolution, in a language the tool does not expect, or with a UI element the recognition model has not seen, produces a confident wrong answer. The depot recognition depends on a community-maintained model and a schema, and neither is versioned in a way you can check before trusting a result. The repository does not document how to verify an OCR result, and for inventory counts that verification is manual.

The third is the regional split. The tool supports all servers and says the server can be switched in settings, but the underlying data sets are community maintained, and the game content differs between regions. A CN-only operator in a global client, or a different operator set in a regional server, means the tool's data is not equally fresh everywhere, and switching the server changes what you can calculate rather than adding translation.

The fourth is the age of the stack. Vue 2 is in maintenance, and this repository depends on Vue 2.7 with vue-router 3, pinia 2 and vue-i18n 8. A new project starting today would more likely reach for Vue 3 and its router, and the workaround script for the OpenSSL legacy provider in the build is a small sign of the era the toolchain comes from. It is a working setup and there is no reason to change it for a project of this size, but it is not a foundation you would build a new long-lived application on.

The fifth is the documentation. The development section of the readme points to a wiki and says to see it, with a note that it is important. The visible readme itself covers features, credits, licence and translation help rather than the API or the internals, so a contributor reads the wiki and the source.

Editorial conclusion

Arknights Toolbox fits a player who treats operator progression as a planning problem and wants the arithmetic done for them, including the parts that are tedious, such as merging several upgrade requirements into one material count or reading a warehouse screenshot, and the fact that it runs as an installable web app with offline use removes the reason to keep a spreadsheet. It is the wrong choice if you need authoritative drop rates, since the drop data comes from community statistics, and it is the wrong choice if you need a maintained desktop client. Before relying on it, open the deployed site at arkntools.app, switch the server in settings and confirm your data set follows, check the OCR result against your actual inventory once, and read the notes on data sources, since the last push was on 2026-10-11.

Frequently asked questions

Official sources

1. arkntools/arknights-toolbox on GitHub
2. Issues
3. License: MIT
4. Project website
5. README