The pattern shows up every quarter: a team demos a voice feature that answers instantly on conference-room Wi-Fi. Two days later, the same build spins for forty seconds in a parking garage while its retry queue re-sends the same prompt. The model access was free, so the demo cost nothing at all — and the team learned nothing from it.
My position is simple: free model tokens are only useful when you spend them through a server you control, from the device your users actually carry. A chat window on a laptop proves a model can write; it proves nothing about your app. The moment you route those free calls through a disposable server, they become a real integration harness.
Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open source project that currently offers free model access and a free server option, which is exactly the combination this workflow needs. Specific numbers change; the free token allowance was 10 million tokens at the time of writing, so verify the project's current terms before you build on them.
Why the chat window is the wrong test bed
A chat UI hides everything your mobile app will do wrong, because it was never designed to fail the way a phone fails. It hides latency because the human waits without measuring, and it hides retries because the chat client retries silently. It hides payload size because nobody inspects what was sent. And it hides the phone's lifecycle entirely: the browser tab stays alive while your app gets backgrounded, suspended, and killed.
The current AI discourse is full of opinions about what models can do; almost none of it is about what your phone does when the network dies. Your users don't chat with your model; they trigger it from a screen that can lose the network at any moment. So the thing under test is not the model — it's the path from the phone to the model, and every failure mode along that path. Free tokens let you test that path as often as you want, but only if you can see the traffic.
The workflow: a logging proxy between your phone and the model
The idea is boring on purpose, because boring infrastructure is what survives a real test session. You put a tiny server between your mobile app and the free model endpoint, and that server logs every request and response. The free server option from MonkeyCode (or any free tier you trust) is enough, because the proxy does almost nothing.
Deploy this minimal Node.js proxy, set UPSTREAM_URL to the model endpoint, and point your app's base URL at the proxy:
// proxy.mjs — log every AI call your phone makes
import http from "node:http";
import https from "node:https";
const UPSTREAM = process.env.UPSTREAM_URL; // assumes an HTTPS endpoint
const PORT = process.env.PORT || 3000;
http.createServer((req, res) => {
const chunks = [];
req.on("data", (c) => chunks.push(c));
req.on("end", () => {
const body = Buffer.concat(chunks).toString("utf-8");
const started = Date.now();
const upstream = new URL(UPSTREAM);
const outReq = https.request({
hostname: upstream.hostname,
path: upstream.pathname + upstream.search,
method: "POST",
headers: { "content-type": "application/json" },
}, (outRes) => {
const outChunks = [];
outRes.on("data", (c) => outChunks.push(c));
outRes.on("end", () => {
const outBody = Buffer.concat(outChunks).toString("utf-8");
console.log(JSON.stringify({
ts: new Date().toISOString(),
status: outRes.statusCode,
latencyMs: Date.now() - started,
requestBytes: body.length,
responseBytes: outBody.length,
requestPreview: body.slice(0, 200),
responsePreview: outBody.slice(0, 200),
}));
res.writeHead(outRes.statusCode, { "content-type": "application/json" });
res.end(outBody);
});
});
outReq.on("error", (err) => {
console.log(JSON.stringify({ ts: new Date().toISOString(), error: err.message }));
res.writeHead(502, { "content-type": "application/json" });
res.end(JSON.stringify({ error: "upstream failed" }));
});
outReq.end(body);
});
}).listen(PORT, () => console.log(`probe listening on ${PORT}`));
Run it with UPSTREAM_URL=https://... node proxy.mjs, and keep the stdout somewhere you can read after each test. This is a probe, not production infrastructure — it has no auth, no queue, and no rate limiting, which is fine for a controlled test.
The lifecycle test plan
Now the actual work: on a real device, not a simulator, with the app in a known state, run each transition and then read the proxy log. Treat every row below as a hypothesis until your own log confirms it, and record the device, OS version, and network condition before each run.
| Transition | Action | What the log should show |
|---|---|---|
| Network switch | Start a request, then toggle Wi-Fi off mid-flight | One request with a latency spike, or a timeout with no response |
| Airplane mode | Enable airplane mode at 50% of the request | The request never arrives, or arrives truncated |
| Backgrounding | Press Home while the spinner is up | The request completes or cancels; look for duplicate retries after resume |
| Force kill | Kill the app during streaming, then relaunch | A partial response, then a fresh request with the same prompt |
| Permission loss | Deny cellular data for the app, then retry | Client-side failure; the proxy sees nothing, which is a valid result |
| Battery saver | Enable low-power mode, then repeat one request | Higher latency, possible timeout, same payload |
The most common finding in these logs is the retry storm, and it shows up in the first ten minutes. The app times out, the retry queue re-sends the full prompt, and the proxy shows three identical requests within ten seconds. On a paid endpoint that is wasted money; on a free allowance it is wasted evidence. You can no longer tell which attempt the user actually saw.
The second common finding is payload bloat, and the proxy's requestBytes field exposes it in the very first row. Many mobile clients resend the entire chat history on every turn, so the byte count grows with every message. A free allowance hides the dollar cost, but the byte count does not lie about what you are shipping.
What this approach cannot tell you
Be honest about the limits of this setup before you draw conclusions from it. A free server and a free model cannot tell you production throughput, because neither has production capacity. They cannot tell you privacy behavior, because a shared free tier is not a compliance boundary. And they cannot tell you model quality under real load, because your test traffic is not real load.
Who should not use this: teams handling regulated health or financial data, because sending real user content through a free third-party server is a policy risk. Also skip this if you need a guaranteed SLA, and skip it if you will not read the logs. The proxy is only useful if the output changes what you ship.
The point of the exercise
Free model access is a gift with a trap attached: it makes demos cheap and learning expensive. A chat window turns your allowance into screenshots, while a server you control turns it into measurements you can argue about. If you try this workflow, keep the logs from one lifecycle test and compare them with a teammate's run on a different device. The phone and OS will disagree, and that disagreement is the actual finding. The free tokens are the excuse; the log is the evidence.
