OneBox (万宝盒): an Android AI agent that drives 90+ on-device tools

The problem OneBox targets: tool sprawl on a phone

Android utility apps tend to be single-purpose. Cropping an image, converting a format, scanning a document, logging a bill and writing a to-do list usually means five apps and five mental models. OneBox's answer is to put the tools in one app and put an agent in front of them, so the user states an outcome instead of picking a tool. The README's own examples are deliberately mundane: turning images into a PDF, logging a bill screenshot into a ledger, making a to-do list, looking up stock prices online.

The intended user is someone who already keeps a folder of utility apps and wants a single entry point, plus a person who wants to try an on-device agent without paying for a subscription. The project is explicit that it is free to use with your own key: the README says you can drop in any OpenAI-compatible API key, including free tiers, and get the full assistant and agent at zero cost. That framing matters, because it tells you where the cost actually sits. OneBox does not sell inference. You bring the endpoint.

How the agent reaches 90+ tools without leaving the sandbox

The mechanism described in the README is tool-calling inside the app process. The agent is given a catalog of in-app tools (PDF processing, image editing, file management, bookkeeping and others) and can invoke them, chaining multi-step tasks across several tools. The README states that execution is local, with per-tool timeouts and iteration limits. Those two controls are the interesting part: an agent that can call tools in a loop needs a ceiling on both how long a single call may run and how many rounds it may take, otherwise a misread instruction becomes an unbounded loop.

The permission story is stated as a boundary rather than a feature. Everything the agent does stays inside the app's own Android sandbox and its declared permission set. The README says it never touches contacts, SMS or call logs, that local tools run entirely on-device, and that only the conversation with the chosen model goes online. That is a narrower claim than it may first appear: the agent is powerful over OneBox's own tools and powerless over the rest of the phone.

Architecture follows a modular Android layout. Jetpack Compose and Material 3 for UI, Decompose for navigation with StackNavigation and retained components, Hilt for DI, KSP for code generation, Room for the AppDatabase and MMKV per module, Retrofit and OkHttp for network, Coil for images. The repository splits into app/ for the shell and packaging, feature/app/ for root navigation and adaptive layout, feature/ai/ for chat, agent and the tool-calling chain, core/* for foundation layers, and libs/* for reusable in-project libraries. Build conventions live in build-logic/convention.

One structural detail is worth flagging because it affects anyone reading the source. Paths under com.t8rin.* are inherited from upstream ImageToolbox and are deliberately left unchanged so the diff against upstream stays reviewable. New code lives under com.wanbaohe.* and com.shifenmiao.*. In practice you will be reading two naming worlds in one repository, and the README names the entry points so you can tell them apart: AppActivity.kt for the app entry, RootComponent.kt for runtime navigation, Screen.kt for routes, ChildProvider.kt and NavigationChild.kt for child wiring, and ScreenSelector.kt plus AdaptiveNavigationLayout.kt for the shell.

Building OneBox from source and running a first agent task

The README's Build section is truncated in the excerpt, but the repository layout tells you what the build expects: a Gradle wrapper at the root (gradlew, gradlew.bat), settings.gradle.kts, build.gradle.kts, gradle.properties, and custom convention plugins under build-logic/convention. Two template files sit at the root, keystore.properties.template and keystore-google.properties.template, which is where signing configuration goes. Copy the template you need before building a release, because a release build without a keystore configuration will not produce a signed artifact.

Signing for a release build uses the template:

cp keystore.properties.template keystore.properties

Fill in the keystore path, alias and passwords in keystore.properties, then run the release assemble task. The README does not document a rollback path for a bad signing configuration, so keep the template file intact and treat keystore.properties as a local, uncommitted file.

Once the app is installed, the first real use is configuration, not conversation. Open settings, add an AI engine with an OpenAI-compatible endpoint and key, and pick the working model. Only then does the assistant respond. A reasonable first task is the README's own example: select a few images and ask for a PDF. That exercises the tool-calling chain, the per-tool timeout and the iteration limit in one short run, so a failure shows up quickly instead of halfway through a long chain.

The DSH client is a separate path. It pairs the phone with a DeepSeek Harness agent running on a computer, using scan-to-pair and end-to-end encryption over LAN or a cloud relay. The computer side needs the onebox-dsh-bridge plugin, added with the command the README gives:

dsh plugin add onebox-dsh-bridge

That is a different trust model from the in-app agent: the work happens on your computer, and the phone is a paired client.

Where OneBox stops: sandbox limits, model dependency and a truncated build doc

The same sandbox boundary that makes the permission story clean also caps what the agent can do. It drives OneBox's tools. It does not drive other apps on the phone, and the README says it never touches contacts, SMS or call logs. If your goal is an agent that books a ride in another app, reads a banking app screen, or automates a third-party workflow, this is the wrong tool by design. The README presents that as a guarantee, not a gap, and for a utility app that is a defensible position.

Second, the agent is only as good as the model behind it. OneBox ships no inference. You supply an OpenAI-compatible endpoint and key, and free tiers in particular come with rate limits and availability that the project does not control. A task that works today can fail tomorrow because the endpoint changed, not because OneBox did. The README's custom-engine support mitigates this by letting you point at a different provider, but it does not remove the dependency.

Third, the build documentation is thin in the excerpt. The Build section is cut off, and there is no documented rollback for signing problems. The repository has a run.md and a docs/ directory, so the material to fill those gaps may exist there, but the README alone does not carry it. Anyone building a release should expect to read the Gradle files and the convention plugins rather than follow a step-by-step guide.

Finally, the platform. This is an Android application written in Kotlin. There is no iOS target and no web client described. The web/ directory is the frontend source of the file-transfer module, an esbuild project, not a browser version of the toolbox.

OneBox versus ImageToolbox: a fork that keeps its diff readable

The most direct comparison is with the project OneBox forked from. The README states that OneBox is built on ImageToolbox by T8RIN, that it started as a fork of that image engine, and that the image-processing core deliberately stays close to upstream so the diff stays reviewable. Upstream Apache-2.0 notices are preserved in the files they came from.

That is a real difference in approach, and it cuts both ways. If you want image processing specifically, ImageToolbox is the upstream and OneBox inherits its core, so the image features are not the reason to switch. What OneBox adds is the agent runtime, the 90+ tool screens and the app shell, and the repository structure says so plainly: feature/ai/ holds the chat, agent and tool-calling chain, while the com.t8rin.* paths remain untouched. The trade-off is that the codebase carries two naming conventions and two lineages. A contributor fixing an image bug has to know whether the file is upstream or new work. The README's decision to keep the upstream paths unchanged makes that answer mechanical, which is a reasonable price for a fork that intends to keep pulling from its parent.

If you want an agent that acts across the operating system rather than inside one app, neither project is the right comparison; you are looking at a different category of tool, and the sandbox guarantee that makes OneBox predictable is exactly what such a tool would have to give up.

Licence, releases and what a fork costs to keep current

OneBox is Apache-2.0. That permits commercial use, modification and redistribution, and it requires that copyright and licence notices be preserved, which the README says is done for the upstream files. If you plan to redistribute a modified build, the obligation to keep those notices travels with the files, including the inherited com.t8rin.* paths. This is not legal advice; read the LICENSE file in the repository before shipping anything.

The release cadence is visible in the tags: 1.4.0 on 2026-09-17, 1.3.9 on 2026-08-30, and 1.3.8 on 2026-08-29. The last push to the default branch was on 2026-09-17. The repository is not archived, and at that push date it is current rather than dormant.

Upgrade cost for a user is the normal Android path: the app is on Google Play, the README lists F-Droid as in review, and there are Chinese store listings under the name 万宝盒. For a self-builder, the cost sits in the fork relationship. Keeping the image core close to upstream means upstream changes are easier to merge, but it also means the convention plugins, the Decompose navigation wiring and the Hilt modules are the parts most likely to need attention when the Android toolchain moves, since those are the project's own work with no upstream to absorb the churn.

Editorial conclusion

Adopt OneBox if you want an Android toolbox whose agent runs inside the app sandbox and you are willing to supply your own OpenAI-compatible key. Skip it if you need an iOS client, a hosted service, or an agent that reaches third-party apps on the phone, because the README puts every action inside OneBox's own permission set. Before building, open build-logic/convention and keystore.properties.template and confirm the signing path works for your machine; before trusting the agent with real files, run one short multi-step task and check the per-tool timeout and iteration limits in feature/ai/.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wangzhishou/OneBox on GitHub