Build a phone-based agent with Termux, 9Router and Workers AI

A phone can run an agent script without a rented server sitting online beside it. Termux provides a place to run the code; Cloudflare Workers AI handles model inference; and 9Router can sit between the script and the model provider if its current interface fits your setup. That is a low-cost architecture to test, not a fully local AI system: prompts and model work leave the phone for a cloud service.

The distinction matters. This setup can avoid a monthly virtual-server bill, but it does not guarantee zero cost, unlimited inference or uninterrupted execution. Cloud service terms and free-tier limits can change. Android can also pause background work. Treat the phone as a useful personal runner for scheduled or intermittent automation, not a server with an uptime promise.

1. Choose a narrow job

Start with a task that does not need constant availability: summarize a file you place on the phone, classify a short note, or draft a response for you to review. Keep the first version read-only. Do not give it permission to send messages, delete records or make purchases.

Write down what starts the job, what data it can read, what the model should return and what happens when inference fails. A bounded input and a predictable output make it easier to tell whether the problem is in the script, the router or the model response.

2. Put the runner on Android

Use Termux as the shell environment for the agent script and its runtime dependencies. Set up the script as you would a small command-line program: keep its inputs explicit, log errors, and make a test run with a harmless sample before connecting it to real data. Avoid assuming a desktop development environment or a persistent server process.

Android power management is the first operational trade-off. A process that works in a foreground test may not keep running after the phone locks, the app is closed or the device reclaims resources. Test the exact conditions you expect to use. If the job must run at a precise time or remain available while the phone is offline, a handset is the wrong execution host.

3. Add inference through Workers AI

Configure the script to send only the model request it needs to Workers AI. Keep credentials out of source files and logs; store them outside the script and restrict access to them. Send a small, non-sensitive test prompt first, then check the returned data against the format your agent expects.

This keeps the agent process on the handset, but inference is remote. Consider what the prompt contains before forwarding it. Do not send private notes, account details or other sensitive material unless your data-handling requirements permit that service and you understand the applicable terms.

Workers AI's free tier can make experiments easier to start, but “free” is not a capacity plan. Check current limits and conditions rather than building around an assumed quota. Add a clear failure path for rejected requests, network loss and unexpected responses. For an action-taking agent, a failed or malformed model response should stop the run, not trigger a guess.

4. Use 9Router only if it solves a real problem

A router may be useful when you want the agent to address a consistent interface while you evaluate different providers or model choices. Before wiring it in, verify that the version you plan to use supports the provider and request format in this stack. Do not assume that a router automatically makes every model interchangeable: response shapes, tool calling and other capabilities can differ.

For a first test, compare a direct request with the routed request using the same prompt and expected output. Record whether the response parses, how failures surface and what extra configuration the router adds. If you only need one provider and the direct path is reliable, removing the extra hop may be the better engineering choice. A previous field test of 9Router and LiteLLM in agent workflows offers useful context for weighing routing behavior against deployment overhead.

5. Make the loop observable and safe

Log the task start, outcome, duration and error category, but keep secrets and full sensitive prompts out of the log. Add a maximum number of attempts so a network problem cannot create an uncontrolled retry loop. During early tests, have the script print proposed actions for a person to review instead of executing them.

Then test the failure cases deliberately: disconnect the network, provide an invalid input and simulate a response the script cannot parse. The agent should stop cleanly and explain what failed. Only after that behavior is predictable should you consider connecting tools that can change data.

Where this stack fits

This arrangement is useful for a developer who wants to experiment from a phone, run occasional personal automations and avoid maintaining a separate cloud server. It is not a private local-model setup, and it is not a dependable always-on service. Cloud inference creates an external dependency; Android adds lifecycle constraints; and a router adds another component to debug.

ZES publishes tutorials on agent systems, including local AI execution on Android and the trade-offs between self-hosted tools and SaaS. Those topics are directly relevant here: the practical design choice is not “cloud or no cloud,” but which parts run on the device, which data leaves it, and what failure modes the workflow can tolerate.