DEV Community: Roronoa

Keep Agent Transcripts Out of the App Switcher on Your First PR

Roronoa — Wed, 09 Sep 2026 15:26:00 +0000

You sit down with a Pixel 8 on Android 15, a debug Flutter build in the foreground, and a first-hour onboarding ticket. The ticket says you should send one chat turn, then read the README while the app sits in recents. You type a dummy question about a visa interview, press Home, and the recents card still shows the last bubble. That Home press is the lifecycle transition you should treat as a data store, not as a pause.

Juniors usually keep the activity resumed while they click through the happy path on a loaner phone. Seniors often review the same diff on a laptop and never background the process at all. App switcher thumbnails, iOS snapshot images, and Android recents tasks are operating-system mechanisms you did not opt into. An agent transcript is worse than a settings screen because tool results can include names, amounts, and health details.

This article is a proposed first-hour workflow, not a claimed lab run with invented timings. You should record the device, OS, framework, network, and permission state before you open a pull request. You should also plan the first rollback if a secure-flag change breaks QA screenshots.

What the OS actually keeps after you press Home

When you leave the chat, the system may freeze a bitmap for the recents tray. On Android that bitmap is the task thumbnail. On iOS it is the snapshot taken around willResignActive. Neither surface is your product database, but both can display the last assistant bubble to anyone who borrows the phone.

You should distinguish three stores that juniors often mix together during onboarding:

In-memory chat state that should survive a short backgrounding and restore cleanly.
Durable logs or caches that must not contain raw tool payloads after a rollback.
OS snapshots that you do not control unless you blank them on purpose.

Source-based platform docs describe FLAG_SECURE and snapshot overlays. Hands-on testing is the only way to see whether your Flutter, React Native, or native shell actually applied them. Do not treat a simulator screenshot as proof that the recents card is blank.

Proposed first-hour experiment

Label this as a proposed test on hardware you control. Do not copy these steps into a launch checklist until you have watched the switcher yourself.

Environment to record

Write these fields in the PR description before you ask for review:

Device and OS, for example Pixel 8 / Android 15 or iPhone 14 / iOS 18.
Framework and versions, for example Flutter 3.24 plus the exact plugin that sets window flags.
Network state: Wi-Fi to a stub endpoint, or airplane mode if the client already caches the last turn.
Permission state: microphone and photos denied unless this flow truly needs them.
Power condition: unplugged, battery saver off, so the OS is not already hiding surfaces.
Application state: one completed agent turn in the foreground, then Home, then recents.

Exact steps

Install a debug build that still talks to a stub model, not to production keys on a shared device.
Send one fixture prompt that contains a fake passport number and a fake medical leave date.
Wait until the last bubble is fully painted, then press Home within two seconds.
Open the app switcher and look at the card with your eyes, not through adb screencap alone.
Return to the app and confirm the conversation is still there, because blanking the snapshot must not wipe state.
Force-stop the app, relaunch, and check whether the same fixture text reappears in recents before first paint.
Capture whether the session recovered, restarted empty, or silently disappeared from disk.

Expected observations

With a secure flag or overlay in place, the recents card should be blank, letterboxed, or covered by a branded shield. The in-app transcript should still restore after you foreground the activity. Without the flag, the last bubble remains readable on the card, which is a ship blocker for any agent that handles HR, health, or finance text.

If the overlay stays up after resume, you have a different bug: you hid the product from the user, not from the operating system. That failure belongs in the first rollback plan, not in a follow-up sprint.

Artifact: a decision table you can paste into the PR

Use this table as the original artifact for the first pull request. Fill the right-hand columns on the device, and do not invent milliseconds.

Lifecycle condition	Secure surface on?	Recents / snapshot	In-app recovery after return
Foreground chat after one turn	n/a	live UI, not a card	n/a
Home, then app switcher	no	last bubbles readable	chat still in memory
Home, then app switcher	yes	blank or shield overlay	chat still in memory
Recents after force-stop	yes	no leftover fixture text	session restarts or restores from encrypted store
Debug flavor for QA	optional	screenshots allowed	same chat code path
Release flavor	required for agent chat	screenshots blocked	same chat code path

Ask the reviewer to reject the PR if the “yes” row still shows readable tool output. Readable output means the OS mechanism still holds sensitive data.

Code you can apply in the first hour

Keep the flag next to the chat route, not on the whole application, so login and help screens remain capturable for support. The snippets below are starting points you still have to verify on device.

Android (Kotlin), proposed for the agent Activity only:

class AgentChatActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        window.setFlags(
            WindowManager.LayoutParams.FLAG_SECURE,
            WindowManager.LayoutParams.FLAG_SECURE
        )
        setContentView(R.layout.activity_agent_chat)
    }
}

Confirm the window flag from a shell, proposed check:

adb shell dumpsys window | grep -E "mSecure|FLAG_SECURE"

That grep does not prove the recents bitmap is blank. You still owe the visual switcher check from the table.

iOS (Swift), proposed overlay around resign-active:

final class SnapshotShield {
    private var cover: UIView?

    func install(on window: UIWindow?) {
        NotificationCenter.default.addObserver(
            forName: UIApplication.willResignActiveNotification,
            object: nil,
            queue: .main
        ) { [weak self] _ in
            guard let window else { return }
            let view = UIView(frame: window.bounds)
            view.backgroundColor = .systemBackground
            window.addSubview(view)
            self?.cover = view
        }

        NotificationCenter.default.addObserver(
            forName: UIApplication.didBecomeActiveNotification,
            object: nil,
            queue: .main
        ) { [weak self] _ in
            self?.cover?.removeFromSuperview()
            self?.cover = nil
        }
    }
}

Flutter, proposed only on the chat route:

import 'package:flutter_windowmanager/flutter_windowmanager.dart';

Future<void> protectAgentRoute() async {
  await FlutterWindowManager.addFlags(
    FlutterWindowManager.FLAG_SECURE,
  );
}

Future<void> unprotectOtherRoutes() async {
  await FlutterWindowManager.clearFlags(
    FlutterWindowManager.FLAG_SECURE,
  );
}

Clear the flag when you pop the chat route. Otherwise QA cannot capture a bug on a non-sensitive screen, and they will ask you to revert the whole change.

React Native, proposed native call from the chat screen:

import { NativeModules, Platform } from 'react-native';

export function setAgentChatSecure(enabled: boolean) {
  if (Platform.OS === 'android') {
    NativeModules.SecureWindow?.setSecure(enabled);
  }
}

The native module should toggle FLAG_SECURE and nothing else. Do not hide the webview debugger behind the same switch on day one.

First PR, then the first rollback

Your first PR should contain the route-scoped flag, the decision table with device fields filled, and a debug flavor that leaves screenshots on. It should not contain a global secure flag, a production API key, or a claim that “recents is fine on my laptop.”

Your first rollback should be equally boring. If QA cannot reproduce a layout bug because the flavor still sets FLAG_SECURE, revert only the debug flavor, not the release shield. If the iOS overlay fails to remove on didBecomeActive, revert the overlay and keep the Android flag, then file a follow-up with the exact OS version.

A useful rollback command for the junior who already pushed is a revert commit, not a force-push on a shared onboarding branch:

git revert HEAD --no-edit
git push origin HEAD

After the revert, rerun steps 3 through 6 on the same device. Write down whether the recents card returned to showing the last bubble. That sentence is the recovery outcome reviewers need.

Where a free stub belongs in this hour

You still need fixture transcripts that look like PII without putting production secrets on a shared phone. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode offers free model access and a free server option you can point the debug flavor at, so the loaner device never holds a customer key while you watch the app switcher.

Keep that stub on the debug product flavor only. The release flavor should keep talking to whatever endpoint the repo already documents. The stub exists so you can generate a visa-shaped sentence and a medical-leave-shaped sentence, then prove the snapshot does not keep them.

Limitations, and who should skip this

This workflow does not encrypt the chat database, does not stop a determined screen recording while the app is foregrounded, and does not replace a threat model. FLAG_SECURE can also block legitimate assistive screenshots and some OEM screen-sharing tools. If your product is a public demo with no personal data, a shield overlay is noise.

Skip this approach when you do not own the native shell, when the chat is only on desktop, or when legal already forbids storing the transcript on device at all. In those cases you need a different first-hour ticket: do not render the raw tool payload in the first place.

Do not treat this article as a benchmark. There are no milliwatt numbers here, and there is no claim that every Android skin honors FLAG_SECURE the same way. Some launchers recapture the task after you return, which is why the force-stop row in the table matters.

What to send back if you run it

If you run the same Home-press on your hardware, reply with the device, OS, framework versions, and the three-step transition you used. Say whether the recents card recovered blank, restarted into an empty chat, or still showed the last tool result. Comparable environment evidence is more useful than another screenshot from a simulator that never builds a recents bitmap.

When the first-hour ticket is closed, the next junior should be able to rerun the table without asking where the stub lives. If you want that stub off the shared phone, the free model access and free server option mentioned above is enough to host dummy completions for the debug flavor.

Benchmark a Mobile Agent Across Airplane Mode and Your First Config Rollback

Roronoa — Mon, 07 Sep 2026 12:24:53 +0000

You sit down with a Pixel 8a on Android 15 and a signed staging build already on the home screen. A half-finished agent turn still paints the chat, with a tool-call spinner frozen after two seconds. You enable Airplane Mode before the HTTP response arrives, then lock the device for thirty seconds. That lifecycle jump is the first thing you should reproduce, because generated agent code usually assumes the radio never drops.

This is a proposed test, not a measured result from a private lab that you should copy blindly. You should run the steps on your own phone, then write down whether the turn recovered, restarted, or silently disappeared. Juniors joining a mobile AI repo in 2026 will meet agent scaffolding on day one, and that scaffolding is cheap to generate. The expensive part is proving the agent fails closed when cellular vanishes during an in-flight tool call.

What you prove in the first hour

You are not proving that the model sounds clever during a hallway demo for stakeholders. You are proving three boring properties that reviewers can re-run without a staging VPN. Write them on the ticket before you touch a prompt file or a tool mapping.

The in-flight tool call has a generationId and a configHash, not just a spinner.
Airplane Mode plus a lock screen cannot create a later surprise retry with a stale schema.
A config rollback cannot resurrect queued work that was produced by the previous agent bundle.

If your repo already ships an on-device runtime, keep that path in the loop during hour one. The remote model is only an oracle for JSON shape, error codes, and fail-closed messaging. Do not treat the oracle as the shipping product for your first pull request.

Record the environment before you flip the radio

Capture versions and radio state before Airplane Mode, or your notes will be useless by next week. Use this list as the header of the pull request so reviewers can repeat the jump. Skip any row and the experiment stops being comparable across phones.

Device and OS: Pixel 8a on Android 15, or your iPhone and the exact iOS build.
Application state: signed in, chat visible, tool call in flight, screen on, then locked.
Framework pins: React Native, NetInfo, HTTP client, and the on-device or edge runtime.
Network and power: Wi-Fi versus LTE, Battery Saver off, no VPN, no private DNS surprises.
Permissions: location or microphone only if that tool truly needs them; otherwise leave them denied.
Expected observation: a user-visible paused state, no duplicate side effect, no missing transcript.

If you cannot name the runtime that executes the tool, you are not ready to change the prompt. Spend the rest of hour one grepping for AsyncStorage, WorkManager, URLSession, and any retry interceptor. Those four hits usually hide the silent duplicate that will show up after rollback.

Proposed experiment: one device, one transition

Follow these steps on a physical device rather than a simulator with fake radios. Emulators lie about radio loss and about process death after you lock the screen. Keep the chat on screen so the lifecycle starts from an in-flight tool call, not from a cold start.

Install the staging build and open a new chat with a disposable account.
Send a prompt that forces a network tool, such as a store lookup, not a local rewrite.
When the spinner appears, enable Airplane Mode within one second, then lock the phone.
Wait thirty seconds without peeking. Unlock and screenshot the transcript, banner, and logs.
Disable Airplane Mode, wait for the radio, and watch for a silent retry you did not request.
Force-stop the app, relaunch, and check whether a queued tool call fires on its own.
Record one outcome: recovered with the same generationId, restarted as a new turn, or disappeared.

You should expect a visible paused or failed-closed state, not a second store lookup after the radio returns. A disappeared spinner with a later duplicate side effect is a failing result, even when the prose looks fine. Attach logcat or Console.app lines that show the same generationId across the lock, because screenshots alone will not survive review.

The state machine your first PR should ship

Keep the first pull request small enough to roll back in one commit on the same afternoon. Model the turn as a state machine, then persist (generationId, configHash, state) before any HTTP write. If you cannot persist that tuple, you cannot prove rollback safety later.

Proposed states:

idle — no work, nothing queued
tool_pending — request on the wire
queued_offline — only if the tool is idempotent and the user opted into retry
cancelled — fail closed and show a pause chip
rolled_back — config hash no longer matches, so you drop the queue

Default to cancelled when Airplane Mode fires during tool_pending. queued_offline is an explicit product choice, not a courtesy of your HTTP client. Juniors get this backward because interceptors retry by default and generated glue copies that habit.

Proposed React Native sketch

// Proposed example, not production code. Pin versions in the PR header.
import NetInfo from '@react-native-community/netinfo';
import { AppState } from 'react-native';
import AsyncStorage from '@react-native-async-storage/async-storage';

type AgentState =
  | 'idle'
  | 'tool_pending'
  | 'queued_offline'
  | 'cancelled'
  | 'rolled_back';

type TurnRecord = {
  generationId: string;
  configHash: string;
  state: AgentState;
  createdAt: number;
};

const TURN_KEY = 'agent.turn.v1';

export async function persistTurn(record: TurnRecord): Promise<void> {
  await AsyncStorage.setItem(TURN_KEY, JSON.stringify(record));
}

export async function failClosedIfStale(
  currentHash: string
): Promise<TurnRecord | null> {
  const raw = await AsyncStorage.getItem(TURN_KEY);
  if (!raw) return null;
  const turn = JSON.parse(raw) as TurnRecord;
  if (turn.configHash !== currentHash) {
    const rolled: TurnRecord = { ...turn, state: 'rolled_back' };
    await persistTurn(rolled);
    return rolled;
  }
  return turn;
}

export function watchRadio(onDrop: () => void): () => void {
  const unsubNet = NetInfo.addEventListener((state) => {
    if (!state.isConnected || state.isInternetReachable === false) {
      onDrop();
    }
  });
  const unsubApp = AppState.addEventListener('change', (next) => {
    if (next !== 'active') {
      onDrop();
    }
  });
  return () => {
    unsubNet();
    unsubApp.remove();
  };
}

Wire onDrop so it moves tool_pending to cancelled and paints a pause chip the user can read. Do not call fetch again from the NetInfo listener when the radio returns a few seconds later. That listener is how silent duplicates are born, and reviewers should reject any PR that retries from connectivity callbacks.

Contract-test the tool JSON before production credentials exist

Your first hour should also freeze the tool schema beside the client, not inside a chat screenshot. Save one golden request and one golden response, then assert names, required fields, and error shape. Leave prose quality out of this test, because wording will drift while the contract must not.

A practical comparison oracle without production credentials is MonkeyCode's free model access on its free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Point the oracle at the same JSON schema your on-device or edge path must emit, and keep user transcripts off that box. Stand the oracle up for hour one, then delete the instance once the contract test stays green.

// Proposed Jest contract. Replace ORACLE_URL with your comparison endpoint.
type ToolCall = { name: string; args: Record<string, unknown> };

export function assertToolShape(call: ToolCall): void {
  const allowed = new Set(['lookupStore', 'cancelTurn']);
  if (!allowed.has(call.name)) {
    throw new Error(`unexpected tool ${call.name}`);
  }
  if (call.name === 'lookupStore' && typeof call.args.query !== 'string') {
    throw new Error('lookupStore.query must be a string');
  }
}

test('oracle tool call matches the mobile contract', async () => {
  const res = await fetch(process.env.ORACLE_URL!, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({
      prompt: 'find a store',
      schemaVersion: 'store-lookup-v1',
    }),
  });
  const body = await res.json();
  assertToolShape(body.toolCall);
});

If the oracle and the phone disagree on tool names, fail the PR before anyone debates latency. Schema drift is cheaper to catch in Jest than in a store listing that double-books a reservation. Hash the golden files in CI so a prompt edit cannot land without a contract bump.

First rollback without resurrecting queued work

Rollback is the third hour-one drill, and most teams skip it until a bad prompt ships. You revert the agent config or the prompt bundle, reinstall the previous binary, then launch into the same chat. The question is not whether the old copy builds. The question is whether yesterday's queue still fires.

# Proposed checks after you reinstall the rolled-back build.
adb shell dumpsys package com.example.staging | grep versionName
adb exec-out run-as com.example.staging cat files/agent.turn.v1
adb logcat -d | grep generationId

On iOS, dump the same record from the app container and look for configHash after the restore. If the hash from the newer config is still sitting in storage, the next foreground will try a tool the old binary does not understand. Your PR should treat hash mismatch as rolled_back and show a one-line system message, not a reconstructed answer that pretends the turn finished.

Decision table for the review

Condition	Tool in flight	Stored hash	Required next state	User-visible result
Airplane Mode during `tool_pending`	yes	matches	`cancelled`	pause chip, no retry
Radio returns, user did not ask	no	matches	`idle`	no new tool call
Config rollback, queue present	maybe	mismatch	`rolled_back`	drop queue, system line
Idempotent tool, user opted in	yes	matches	`queued_offline`	explicit resume affordance

If a cell is missing from your ticket, the reviewer should bounce the PR without debating model quality. Generated agent glue loves the empty cell called just retry, and that cell is how a junior's first rollback creates a duplicate side effect. Fill the table in the description, then paste the screenshots that match each row you claim to handle.

Native and Flutter notes for the same tuple

The same tuple belongs in DataStore on Android, or in a small Room row if you already have one. On iOS, put generationId and configHash in the application support directory, not in a defaults file that backup may scoop up. Flutter teams can store the record with shared_preferences only if you remember that plugin is not a queue and not a lock.

WorkManager and BGTaskScheduler are for opted-in idempotent tools, not for resurrecting cancelled agent turns after Airplane Mode. If a native retry worker already exists, your first PR should make it read state before it touches the network. Otherwise the cross-platform client will fail closed while the platform worker quietly completes the stale call.

Limitations, and who should not use this

This article is a proposed onboarding workflow, not a claim about any phone's battery curve or token throughput. The write-up does not attach lab numbers, and you should not copy anyone else's milliseconds into your review. NetInfo isInternetReachable can lag behind the modem, and iOS will freeze listeners in ways Android will not.

Do not send production traffic, paid user chats, precise location, audio, or account tokens to a comparison endpoint. Teams with a locked staging mesh already have an oracle, so do not add a second one for novelty. Voice interruption, Doze completions, and backup of prompt caches are separate drills, and this workflow does not replace them.

Skip fail-closed cancellation if your product legally must complete a payment tool once the user confirms. In that case you need an idempotency key on the server of record, which is a different review with different failure language. Juniors should still persist generationId, but the next state is queued_offline with an explicit resume, never a hidden interceptor retry.

Ask your device, then tell us what happened

Run the Airplane Mode lock on your own build this week and keep the notes next to the PR. Comment with the device, OS, framework pins, and the exact transition you used. Say whether the turn recovered, restarted, or silently disappeared after rollback, because that single word is the evidence the next junior needs.

Keep In-Flight Completions Out of Doze on Your First Morning

Roronoa — Sun, 06 Sep 2026 20:37:25 +0000

You unlock a staging Pixel on morning one and the chat bubble is still spinning after a twenty-minute commute. The phone is on Android 15, the React Native build is signed in, and the stream that looked healthy at the office never returns. That sleep-to-foreground handoff is your first-hour job, not a polish task after you ship copy. Treat the spinning bubble as the product, because every later agent loop will inherit the same socket.

Hour one is a lifecycle map, not a repo tour

Most onboarding docs walk you through login, a sample prompt, and then a pull request template. You should invert that order whenever the screen talks to a model. The composer, the retry queue, and the streaming parser all assume the process stayed warm. Sleep, Doze, and a force-stop each violate that assumption in a different way, and a junior merge will hide the difference.

Ask the person who assigned the ticket for three facts before you clone extra tools. You need the inference base URL, whether the client holds a streaming HTTP connection, and what the UI does when that socket dies. If nobody can answer those, you already have your first pull request: write the gaps down. Do not start by swapping models or wrapping the call in an agent. Agentic samples this week spend pages on tools and almost none on what the OS does when the screen turns off.

Record the environment before you touch code

Write this block into the ticket even when the values feel obvious to the team:

Device and OS, such as Pixel 8 on Android 15, or iPhone 14 on iOS 18
App stack: React Native version, New Architecture on or off, debug versus release
Network: Wi-Fi, cellular, or airplane mode after the first tokens arrive
Power: charging, battery saver, and whether Adaptive Battery is enabled
Permissions: only those the feature actually uses, including network
Starting state: signed in, composer focused, one completion already in flight
Transition: lock for ten minutes, adb Doze, then unlock and read the bubble

You are not collecting vanity benchmarks for a launch blog. You are collecting enough context that a reviewer can replay the failure on their own phone. If you skip the starting state, “it hung” is not a bug report they can act on. Do not invent timings for a device class you did not hold. Label every observation as recovered, restarted, or silently disappeared.

Proposed test: sleep, Doze, then a dead process

This is a proposed single-device experiment, not a lab result measured on a farm. Run it on the hardware in your hand and write down what the UI did after each step.

1. Establish a live stream

Disable battery saver and keep the device on a known Wi-Fi network.
Open the staging build and start a long completion, not a one-token ping.
Confirm tokens arrive for at least ten seconds so the socket is actually live.
Note the request id from logcat, Charles, or your debug overlay.

2. Sleep without killing the app

Press the power button, wait ten minutes, then unlock and return to the same chat. Watch the bubble instead of sending another prompt. An honest result is one of three outcomes: the stream resumes, the client retries with a new id, or the spinner dies with no error. Optional check that the process is still cached:

adb shell dumpsys activity processes | grep -i your.package.name

3. Force Doze and App Standby

Only do this on a device you own or on a dedicated staging phone.

adb shell dumpsys battery unplug
adb shell dumpsys deviceidle force-idle
# wait two minutes with the stream still "open" in the UI
adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset

Expected observation, not a promised millisecond count: Doze should freeze background network for a non-exempt app. If tokens continue anyway, the build may hold a foreground service or a battery exemption you did not know about. That exemption belongs in the pull request description, because reviewers cannot see it from a screenshot of the chat.

4. Kill the process and reopen

adb shell am force-stop your.package.name
# relaunch from the home screen, not from the debugger

If the retry queue still holds the original prompt, you now have a privacy and correctness bug, not a UX nit. The first rollback drill later depends on this queue being inspectable in a debug overlay. On iOS, pair the same idea with a swipe-kill from the app switcher, because inactive is not process death.

Decision table for the handoff

Use this table in the ticket. Fill the last column on the device, and refuse to merge on guesswork.

Transition	Fail closed looks like	Record on device
Lock for 10 minutes	Typed error or explicit retry id	recovered / restarted / disappeared
`deviceidle force-idle`	No hidden tokens without an exemption	recovered / restarted / disappeared
`am force-stop`	Prompt is not replayed against production	recovered / restarted / disappeared
Stub host stopped	Error in the composer, no host fallback	recovered / restarted / disappeared

A row that says disappeared is already enough to block the first pull request. Do not “fix” it by pointing the client at production from a debug binary.

Put the inference host in config, then point it at a stub

Your first pull request should not train anything and should not add tools. It should make the base URL injectable so hour-one failures stay cheap and reversible.

// src/config/inference.ts
// Proposed client config. Verify against your repo's existing env pattern.
export type InferenceConfig = {
  baseUrl: string;
  timeoutMs: number;
  allowRetry: boolean;
};

export function loadInferenceConfig(): InferenceConfig {
  const baseUrl = process.env.INFERENCE_BASE_URL;
  if (!baseUrl) {
    throw new Error("INFERENCE_BASE_URL is missing; refusing to guess production");
  }
  return {
    baseUrl,
    timeoutMs: Number(process.env.INFERENCE_TIMEOUT_MS ?? 20000),
    allowRetry: process.env.INFERENCE_ALLOW_RETRY === "true",
  };
}

# .env.staging.example
INFERENCE_BASE_URL=https://stub.example.internal/v1
INFERENCE_TIMEOUT_MS=20000
INFERENCE_ALLOW_RETRY=false

Leave INFERENCE_ALLOW_RETRY false until the sleep test has a defined recovery path. Silent retry after process death is how prompts get duplicated on the wire. It is also how caches wander into backups you have not audited yet.

If you need a host you can destroy without filing a ticket, MonkeyCode’s free server option is enough to hold a tiny streaming stub. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Free model access on that product can draft the AppState glue below; it cannot watch your lock screen or prove Doze.

Keep the stub intentionally stupid so the phone remains the system under test:

// stub/server.mjs — proposed local stand-in, not a production gateway
import http from "node:http";

http
  .createServer((req, res) => {
    if (req.url !== "/v1/chat/completions" || req.method !== "POST") {
      res.writeHead(404);
      res.end();
      return;
    }
    res.writeHead(200, { "content-type": "text/event-stream" });
    const timer = setInterval(() => {
      res.write(
        `data: {"id":"stub-1","choices":[{"delta":{"content":"x"}}]}\n\n`
      );
    }, 400);
    req.on("close", () => clearInterval(timer));
    setTimeout(() => {
      clearInterval(timer);
      res.write("data: [DONE]\n\n");
      res.end();
    }, 15000);
  })
  .listen(process.env.PORT ?? 8080);

You now have a stream you can start, a device you can sleep, and a process you can kill. That combination is the onboarding lab. Do not add authentication theater until the four rows in the table have real words in them.

Watch AppState so the UI tells the truth

// Proposed React Native harness. Confirm AppState on your RN version.
import { useEffect, useRef } from "react";
import { AppState, AppStateStatus } from "react-native";

export function useInferenceLifecycle(
  onInterrupted: (reason: string) => void
) {
  const state = useRef<AppStateStatus>(AppState.currentState);

  useEffect(() => {
    const sub = AppState.addEventListener("change", (next) => {
      const prev = state.current;
      state.current = next;
      if (prev === "active" && next.match(/inactive|background/)) {
        onInterrupted(`app_left_foreground:${next}`);
      }
      if (next === "active" && prev !== "active") {
        onInterrupted("app_returned_foreground");
      }
    });
    return () => sub.remove();
  }, [onInterrupted]);
}

On iOS, write down whether you backgrounded from Control Center or from the lock button, because inactive is not the same as background. On Android, pair this listener with the Doze commands so you do not confuse an OS network freeze with React Native blurring the activity. Log the reason next to the request id. Reviewers cannot guess which transition you actually hit from a cropped screen recording.

First pull request: a checklist, not a model swap

Title the pull request around the lifecycle, for example “Fail closed when inference drops after sleep”. Include all five of these artifacts:

A config flag for the stub URL and a screenshot of the sleep outcome.
The three-way result: recovered, restarted, or silently disappeared.
Whether a foreground service or battery exemption was required.
Retry disabled until the queue is visible in debug builds.
A rollback note: how to point the build back at production and uninstall the stub host.

Skip agent frameworks until this checklist is green on one physical device. Cheap generated code will happily add tools that call the network from a background isolate you never ran through Doze. Your reviewer should be able to repeat the lock-and-unlock path without asking you which phone you used.

First rollback: kill the stub while a stream is open

Rollback is not git revert alone when the binary already lives on a phone. You need the installed build to survive the host disappearing without quietly retargeting production.

Start a stream against the stub while the app is in the foreground.
Sleep the device for two minutes so the socket is no longer obvious.
Stop the free server process or undeploy the stub entirely.
Unlock and open the same chat, without sending a new prompt.
Record whether the UI shows a typed error, retries against production, or hangs.

If the client falls back to a hardcoded production host, that is a release bug. Juniors ship that fallback because it unblocks a hallway demo. You should refuse it. Production is not a spare tire for a staging stub, and a first rollback that leaks prompts into the real account is worse than a red bubble.

# Prove the installed binary no longer references the stub after revert
npx react-native bundle --platform android --dev false \
  --entry-file index.js --bundle-output /tmp/app.jsbundle
grep -n "stub.example" /tmp/app.jsbundle || echo "no stub URL in bundle"

An empty grep result is the expected observation after a clean rollback. A hit means the URL was compiled in, and you need another build before you call the drill done. Repeat the bundle check on iOS with your usual npx react-native bundle --platform ios path so the two store binaries cannot drift.

Tradeoffs and who should not do this

This workflow is for a junior joining a mobile AI repo that already has a chat or completion screen. It is not a substitute for Play policy review, medical-device process, or load testing. Do not run deviceidle force-idle on a personal phone that holds the only authenticator. Do not point a debug build at production keys. Do not store stub prompts in device backups; that is a separate audit.

Write these limitations into the ticket so the next hire does not over-read your notes:

Doze and iOS background rules change by OS version, so one Pixel is not a fleet.
React Native AppState does not equal process death, and emulators lie about both.
A free server stub will not reproduce production auth, chunking, or TLS pinning.
Free model access can draft harnesses; it cannot see your lock screen or thermal state.
Airplane mode, Doze, and am force-stop are three different failures, not one flaky bug.

If your team already has a device lab with scripted lifecycle tests, use that lab and ignore the stub. If you cannot hold a physical device, stop here and ask for one before you merge anything that talks to a model.

What to send back after you run it

Send comparable environment evidence, not a screenshot of a happy path on Wi-Fi. Include device, OS, framework versions, permission and network state, the exact transition steps, and whether the stream recovered, restarted, or silently disappeared. If you used a killable stub, say whether rollback left a compiled URL in the bundle. That report is the onboarding artifact; the model name in the composer is not.

Keep Prompt Caches Out of Device Backup on Your First Mobile AI PR

Roronoa — Sat, 05 Sep 2026 19:16:12 +0000

You join a mobile AI repo on day one and install the debug build on a Pixel 8 running Android 15. The app stays in the foreground with a warm local embedding cache and no network spinner visible. You then start a system backup before anyone explains which on-device files are allowed to leave. Treat that sequence as a proposed first-hour walkthrough, not as a measured result from a device farm.

Why backup is the onboarding trap for on-device AI

Junior engineers often hunt for the happy-path inference call and miss the files that inference leaves behind. On-device embeddings, prompt transcripts, and downloaded model shards usually land in app-private storage that backup tools still visit. A restore onto a replacement phone can revive those files after you thought a rollback had wiped them. Your first job is to name every AI artifact on disk before you open a pull request.

Record the environment before you touch Settings, Finder, or Android Backup.

Device and OS: write the exact phone and build, for example Pixel 8 / Android 15 or iPhone 15 / iOS 18
Framework: copy React Native, Flutter, Kotlin, or Swift versions from the lockfile, not from memory
Network: Wi-Fi with backup enabled, then airplane mode for the recovery pass
Permissions: only those the debug build actually requests, which may be none for a text summarizer
Power: leave the device unplugged so backup is not confused with a charging-only job
App state: foreground with a warm cache, then force-stop, then uninstall

Those fields are what a reviewer needs when a cache returns after rollback. Skip invented battery numbers, because a single unplugged backup is not an energy benchmark.

First hour: map one prompt onto real files

Do not start by asking an agent to add a new model path or a cloud fallback. Force one ordinary utterance through the current build while the process stays in the foreground. Type a non-secret phrase such as calendar reminder for Tuesday and wait until the local pipeline finishes. Then inspect storage before the app is backgrounded, killed, or backed up.

Proposed Android inspection commands, only against a debug package you installed yourself:

# Confirm the debug package
adb shell pm path com.example.mobileai

# List likely AI artifacts after one utterance
adb shell run-as com.example.mobileai ls -la files
adb shell run-as com.example.mobileai ls -la files/ai_cache
adb shell run-as com.example.mobileai ls -la databases

# Hash anything that looks like an embedding index or transcript
adb shell run-as com.example.mobileai sha256sum files/ai_cache/*

Proposed iOS inspection on a personal device with a development profile:

# Xcode → Window → Devices and Simulators → Installed Apps → Download Container
unzip -l AppData.xcappdata
find AppData.xcappdata -iname '*embed*' -o -iname '*prompt*' -o -iname '*.gguf'

Write down three paths before you discuss architecture. You want the model shard, the embedding or sqlite cache, and any rolling transcript. If a path is missing, the feature is either fully remote or the cache sits in a surprise directory such as cache/ instead of files/.

Android Auto Backup treats those domains differently, so the directory name is part of the privacy review. A one-page map beats a redesign on day one:

User text or a short recording enters the input field.
Bytes hit RAM, then a file, then optionally a network client.
A retry queue or embedding index may keep a second copy.
Google backup, iCloud, or a device-to-device transfer may keep a third copy.

If step 4 exists for prompts or embeddings, your first PR is a storage fix, not a model swap. Cross-platform wrappers do not change that rule, because Flutter and React Native still land on OS backup policy.

First PR: exclude the sensitive files from OS backup

The smallest honest PR on a mobile AI repo often changes backup rules rather than prompts. You want public model weights and any user-derived cache excluded from cloud backup. You can still restore crash logs that do not contain utterances. Label the snippets below as proposed defaults, then confirm them against current platform docs before you merge.

Primary references to keep next to the PR:

Android Auto Backup: https://developer.android.com/identity/data/autobackup
Android 12+ data extraction rules: https://developer.android.com/about/versions/12/backup-restore
iOS exclusion key: https://developer.apple.com/documentation/foundation/urlresourcekey/isexcludedfrombackupkey

Android: `backup_rules.xml`

<?xml version="1.0" encoding="utf-8"?>
<data-extraction-rules>
    <cloud-backup>
        <exclude domain="file" path="ai_cache/"/>
        <exclude domain="file" path="models/"/>
        <exclude domain="database" path="prompt_log.db"/>
        <include domain="file" path="crash_reports/"/>
    </cloud-backup>
    <device-transfer>
        <exclude domain="file" path="ai_cache/"/>
        <exclude domain="file" path="models/"/>
        <exclude domain="database" path="prompt_log.db"/>
    </device-transfer>
</data-extraction-rules>

Wire it in the manifest only after you confirm the app uses the modern backup schema:

<application
    android:dataExtractionRules="@xml/backup_rules"
    android:allowBackup="true">

allowBackup="false" is a blunt option that also drops useful non-secret state. Prefer explicit excludes when the rest of the app still needs restore. If the cache is under cache/ instead of files/, update the domain and path so the rule actually matches.

iOS: mark files after you create them

import Foundation

func excludeFromBackup(url: URL) throws {
    var values = URLResourceValues()
    values.isExcludedFromBackup = true
    var fileURL = url
    try fileURL.setResourceValues(values)
}

// Proposed call sites, not a drop-in SDK:
// 1) after downloading a public model shard
// 2) after opening the embedding sqlite file
// 3) after rotating a local transcript

Flutter and React Native still need those OS hooks. A Dart file from getApplicationSupportDirectory() is not excluded until something sets the iOS resource value. Android still needs the XML, because Dart cannot invent a backup domain the OS does not honor.

Proposed Flutter sketch, labeled as unexecuted glue:

import 'dart:io';
import 'package:flutter/services.dart';

const _backup = MethodChannel('ai_cache/backup');

Future<void> excludeAiCache(File file) async {
  if (Platform.isIOS) {
    await _backup.invokeMethod('excludeFromBackup', {'path': file.path});
  }
  // On Android, rely on dataExtractionRules, not this channel.
}

The native iOS side of that channel should call the same isExcludedFromBackup helper. Do not treat the Dart file as proof the flag is set; download the container and read the resource value.

First rollback: uninstall, restore, and watch what returns

A rollback is not git revert alone. On a phone, rollback also means the user deleted the app, restored from backup, or accepted an OS migration. Your proposed rollback test should answer three questions in order.

After uninstall, are model shards and prompt caches gone from app-private storage?
After a cloud backup restore, do those files reappear without a new utterance?
After restore, does the feature recover by re-downloading public weights only, never by replaying user text?

Proposed Android sequence for a personal debug device:

# Capture hashes while the cache is warm
adb shell run-as com.example.mobileai sha256sum files/ai_cache/*

# Uninstall after the backup job finishes in system UI
adb uninstall com.example.mobileai

# Restore through system UI, reinstall the same debug APK, then compare
adb shell run-as com.example.mobileai ls -la files/ai_cache
adb shell run-as com.example.mobileai sha256sum files/ai_cache/*

Expected observations if the PR is correct: ai_cache is empty or missing, and no prior utterance is searchable. The public model may re-download, which is recovery, not a leak. Expected observations if the PR is wrong: the same sha256 hashes return without a new input. Do not treat those sentences as lab numbers; they are pass/fail signals you record on your own device.

On iOS, download the container again after restore and repeat the find search. A file that still has isExcludedFromBackup unset is a defect even if the UI looks healthy. If the summarizer silently shows yesterday’s sentence, the rollback failed, even when git status is clean.

A first-PR decision table

Artifact on disk	Survives uninstall?	Allowed in cloud backup?	First PR action
Public model shard	No	No	Exclude; re-download on recovery
Embedding index from user text	No	No	Exclude; rebuild after a new utterance
Prompt / transcript sqlite	No	No	Exclude, or stop writing it
Crash reports without utterances	No	Maybe	Include only if redacted
Auth tokens	No	No	Use the platform keystore, not files

If your repo already writes transcripts for debugging, gate that file behind a debug flag and the backup exclude list. A junior PR that only adds a prettier prompt is not a lifecycle fix.

Where a scratch coding workspace fits

You do not need a paid GPU to write this pull request. You need a place to draft the backup XML, the iOS helper, and a short test plan while the device is in your hand.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode’s free model access and free server option can host that drafting work and a tiny public model-manifest JSON for re-download tests. Keep the manifest free of user prompts, utterance hashes, and anything that belongs in ai_cache. Treat the workspace as a scratch pad for the first PR, not as a production inference cluster.

A junior-friendly manifest for the recovery path can look like this:

{
  "model_id": "local-summarizer-public",
  "sha256": "replace-with-the-public-weight-hash",
  "uri": "https://example.invalid/models/summarizer.bin",
  "contains_user_data": false
}

Host only public weights or a stub file. Never upload the on-device prompt log to that server, even when the server is free.

Limitations and who should skip this

This approach does not replace a security review, MDM policy, or a formal threat model. It will not help if the model runs entirely in a browser tab. It also will not help if your only AI call is a stateless HTTPS POST with no local cache. Work-profile devices, Play backup exceptions, and iCloud behavior vary by OS version, so copy versions from the device.

Skip this workflow when you do not have a physical device you are allowed to uninstall. Emulators often fake backup domains, and those fakes are not evidence. Skip it when the cache lives on a server you do not control, because mobile backup rules will not be the leak. Do not publish battery figures from the backup run; radio state and file size dominate, and one pass is not a benchmark.

Ask for comparable evidence

If you run this first-hour map on a real phone, report the device, OS, framework versions, and the exact transition. Name whether you went warm cache → backup → uninstall → restore. Say whether the cache recovered, the model re-downloaded, or the files silently reappeared. That is the signal a mobile AI reviewer can use on the next onboarding.

Benchmark a Voice Agent Across Permission Loss and First Rollback

Roronoa — Fri, 04 Sep 2026 17:05:10 +0000

You sit down with a cloned notes app, a charged Pixel, and a Slack ping asking you to ship the voice agent. The README promises a wake word, a cloud planner, and a spoken recap after every meeting. Nobody documented what happens when you revoke the microphone and then lock the phone mid-sentence. Your first hour is not for polishing the greeting; it is for proving the agent can stop and roll back.

That gap is how junior engineers accidentally ship an agent that still assumes the world from tap-to-talk. The model still thinks it holds the mic, and the lock screen still leaves a session token alive. You do not need a lab study; you need one device, one permission toggle, and a rollback in the PR. Treat every cloud agent claim as a hypothesis until the OS has been allowed to disagree.

The first hour: map assumptions, not files

Skip the tour of every package on day one and walk the user flow that can hurt people. You will still clone, install, and boot the app, but you will annotate assumptions instead of architecture diagrams. Write each assumption as something the OS can steal from you without a crash.

On a typical voice notes screen the agent quietly assumes all of the following:

RECORD_AUDIO or the iOS microphone permission stays granted for the whole session
The process remains in the foreground while planner tokens stream back
The network path that hosts the planner stays reachable and unchanged
Partial transcripts are safe to retry if the RPC fails mid-sentence
Session identifiers can live in memory until the user says goodbye

None of those survive a realistic commute between an office desk and a noisy train platform. Android and iOS will reclaim the mic, freeze sockets, and later restore your process with colder caches. If the repo already has an AI service singleton, read that file before you read the UI kit. Dangerous retries usually hide there, sitting behind a friendly "just call the planner again" helper.

Fill this block in your notes before you touch a line of product code:

Device:
OS / patch:
App build / feature flag:
Framework (RN / Flutter / native) and versions:
Permission state at launch:
Network (wifi / cellular / offline):
Power (plugged / battery saver):

You are not collecting vanity metrics for a launch blog, and you are not ranking phones by speed. You are creating the only context that makes a later rollback story reviewable by someone else. Without those fields, a passing emulator run will look identical to a failure on a battery-saver OEM build.

A decision table for the first rollback

Use this table in the PR description so reviewers argue about behavior instead of untested optimism. Mark each row as must-stop, must-prompt, or must-discard before you request a review.

OS event	Agent assumption that dies	Rollback you should prove	Sensitive leftover to inspect
Mic revoked in Settings	"I can still listen"	Move to `permission_lost`, stop capture, drop PCM	Audio ring buffer, cache file
App backgrounded or locked	"The user is still in the session"	Move to `backgrounded`, cancel TTS	Partial transcript, session cookie
Network loss mid-plan	"The planner will finish"	Fail closed, show local copy, do not auto-retry body audio	Queued multipart body
Process death then restore	"Memory still has the turn"	Cold start to `idle`, do not replay the last utterance	Encrypted store / MMKV / UserDefaults
Permission restored later	"Resume where we left off"	Explicit user confirm; do not auto-open the mic	Old session id

If a row cannot be tested on your loaner device, say so plainly in the PR body. A missing row is honest; a green check invented from a simulator happy path is not.

Session state you can actually roll back

Label this as a proposed module, not as production code measured on a device farm. Keep the agent in a small explicit machine so a junior can abort it from one function. The names matter more than the framework: Idle, Listening, Planning, Speaking, PermissionLost, Backgrounded.

// proposed: session.ts — wrap from RN, Flutter, or native
export type AgentPhase =
  | "idle"
  | "listening"
  | "planning"
  | "speaking"
  | "permission_lost"
  | "backgrounded";

export type AgentSession = {
  phase: AgentPhase;
  sessionId: string | null;
  transcriptDraft: string;
  audioBytesHeld: number;
};

export function createSession(): AgentSession {
  return { phase: "idle", sessionId: null, transcriptDraft: "", audioBytesHeld: 0 };
}

export function abortForOs(
  session: AgentSession,
  reason: "permission_lost" | "backgrounded"
): AgentSession {
  // Drop anything that could be retried as if the user were still talking.
  return {
    phase: reason,
    sessionId: null,
    transcriptDraft: "",
    audioBytesHeld: 0,
  };
}

export function mayCaptureAudio(session: AgentSession): boolean {
  return session.phase === "listening";
}

Wire abortForOs to the permission callback and to the app lifecycle owner on day one. Do that before you wire the greeting, the planner prompt, or any streaming UI chrome. If your platform kit already has a speech session object, wrap it rather than adding another retry queue. The first rollback is a delete of buffers, not a clever resume that keeps PCM "just in case."

On Android you can force the interesting transition with a real Settings change, then confirm the process observed it:

# proposed drill — replace the package name with yours
adb shell cmd appops set com.example.notes RECORD_AUDIO deny
adb shell am start -a android.settings.APPLICATION_DETAILS_SETTINGS \
  -d package:com.example.notes
adb logcat -d | grep -E "AgentPhase|RECORD_AUDIO|permission_lost"

On iOS Simulator the privacy tool is enough to practice the callback; still repeat the drill on a physical phone before you call the PR done:

xcrun simctl privacy booted revoke com.example.notes microphone
xcrun simctl privacy booted grant com.example.notes microphone

Capture should stop, spoken playback should stop, and sessionId should become null after the revoke. No PCM file should remain under the app sandbox cache or in an upload retry directory. If the agent restarts listening when you return from Settings, you have a resume bug. Call that a failed rollback in the PR, even if the greeting demo still sounds smooth.

First PR: ship the stop path

Your first pull request should not add an agent greeting and a planner prompt by themselves. Make the stop path visible in the diff so a tired reviewer can find it quickly. Include the following artifacts in this order, and keep the planner work for a later PR.

The state machine and the two OS hooks that call abortForOs.
A screen or log line that shows permission_lost and backgrounded as first-class UI, not a generic toast.
A test, even an instrumentation sketch, that revokes the mic and asserts mayCaptureAudio is false.
A short note of what you could not test: iOS background audio modes, OEM battery savers, Wear, cars.

// proposed: android instrumentation sketch
@Test
fun micRevokeStopsCapture() {
    val session = AgentStore.current()
    session.startListeningForTest()
    InstrumentationRegistry.getInstrumentation().uiAutomation
        .executeShellCommand("cmd appops set com.example.notes RECORD_AUDIO deny")
    Thread.sleep(1_000) // coarse; replace with an idling resource in a real suite
    assertFalse(session.mayCaptureAudio())
    assertEquals(0, session.audioBytesHeld)
    assertNull(session.sessionId)
}

Reviewers should reject auto-retry of audio bodies after the session has already been aborted. Text prompts can retry; microphone buffers should not travel with those retries under any flag. If the planner needs a replay, replay a redacted local summary the user already saw on screen. Never replay the PCM you were supposed to drop when the OS took the microphone away.

A throwaway inspector that never sees the phone mic

You will want another pair of eyes on the session dump after you finish the revoke drill. That is especially true when the PR includes prompt text that might echo user speech later. You may want a disposable inspector for those dumps while you learn the rollback path. MonkeyCode's free model access and free server option can summarize a synthetic session file without a long-lived backend. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Keep the inspector on fake transcripts you generated for the drill, not on captured meeting audio. Do not upload contact names, production session tokens, or anything your privacy review has not cleared. Tear the server down when the afternoon ends so the dump does not become an unofficial log store. This is practice infrastructure for a junior's first rollback, not a substitute for your model vendor.

A minimal inspector contract looks like this:

# proposed: send only a redacted JSON dump you created by hand
curl -sS -X POST "$INSPECTOR_URL/summarize-rollback" \
  -H "Content-Type: application/json" \
  -d @synthetic-session.json

{
  "phase_after": "permission_lost",
  "audio_bytes_held": 0,
  "transcript_draft": "",
  "session_id": null,
  "notes": "synthetic commute revoke; no user audio"
}

Ask the free model only whether the dump still contains fields that should have been cleared. That question is cheaper than arguing about architecture on a whiteboard during onboarding hour one. It stays useful if you later swap the inspector for an internal tool your security team already likes.

Limitations

This drill does not prove battery cost, thermal throttling, or the quality of any planner model. It does not replace platform guides for background audio, CallKit, or Android foreground services. Simulator permission tools skip OEM overlays that real Android users live with every commuting week. A free server is the wrong place for real customer speech, and free model access is wrong for anything under an unread DPA.

Device timings are omitted here because this is a proposed onboarding workflow, not a lab report. If you publish numbers, publish the device, OS, app build, permission state, network, and power condition. Without those fields, other juniors cannot tell whether they reproduced your rollback or a different bug.

Who should not use this approach

Do not use this as production voice design if you ship regulated recording or medical dictation. Do not skip legal and privacy review because a junior completed a Settings revoke once on a desk phone. Do not point free model access at real user transcripts, even when the free server is empty after hours. Teams without even one physical phone should not claim a rollback works; file the gap and wait.

Skip the inspector entirely if your security team forbids any outbound dump, including synthetic ones. In that case keep the decision table and the state machine, and run the adb steps on an offline desk. The onboarding value is the failed-closed path, not the brand of inspector that read a JSON file.

After you merge, ask for the same boring facts

When a teammate repeats the drill, ask for the same boring facts you recorded in hour one. Collect the device, the OS, the exact transition, and whether the agent recovered, restarted, or silently disappeared. That sentence is more useful in a handoff doc than a demo video of a perfect spoken greeting.

If the agent talked after the mic was gone, you did not finish onboarding on that feature flag. Roll the flag back, keep the state machine, and fix the lifecycle hook before you write a smarter planner. Your first useful PR is the one that proves the agent can stop, not the one that makes it sound friendly.

Summarize Locally, Send Less: A Mobile LLM Pattern for Free-Tier APIs

Roronoa — Fri, 04 Sep 2026 11:00:58 +0000

Your mobile AI assistant has been chatting for ten minutes. Every turn, the client re-sends the entire conversation history to the server, and you have not noticed because the UI stays smooth. Then the error appears: quota exhausted. You check the logs and find that 80% of your token spend was repetition, not new information. This is the hidden cost of naive context management, and it becomes visible the moment you run against a free-tier backend.

Here is my position: a mobile LLM client should summarize its own history before sending anything to the server. On-device summarization cuts token waste, reduces latency, and keeps sensitive details off a shared backend. The free server and token allowance from MonkeyCode are a useful place to test this pattern, because they force you to care about every token. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Why Your Client Repeats Itself

Most chat clients treat the conversation as an immutable array and send the whole thing on every request. That works for a few turns, but the context window grows linearly while the useful information grows sublinearly. A 20-message conversation about debugging a network issue might contain three key facts: the device model, the error code, and the fix that worked. The other seventeen messages are filler that still costs tokens.

Server-side solutions like session memory or prompt caching exist, but they are not always available on free tiers, and they do not help when the server restarts or the quota resets. The client is the only layer you fully control, so that is where the compression should happen. The goal is not to lose context; it is to reduce the redundant representation of that context.

The On-Device Summarization Pattern

The pattern has three steps: split the history into an old segment and a recent segment, summarize the old segment locally, and send the summary together with the recent messages. The summary can be as simple as an extractive heuristic or as sophisticated as a local transformer model. The key is that the summarization runs on the phone, not in the prompt.

Here is a minimal TypeScript implementation that uses extractive summarization for the old part and keeps the last four messages intact:

// summarize.ts
interface Message {
  role: 'user' | 'assistant';
  content: string;
}

function summarize(messages: Message[], maxLength: number): string {
  // Extractive summary: take the first sentence of each message.
  // For production, swap in a local ML model (e.g., TFLite) for better quality.
  return messages
    .map(m => m.content.split('.')[0] + '.')
    .join(' ')
    .slice(0, maxLength);
}

export function buildPayload(
  history: Message[],
  summaryLength: number,
  recentCount: number
) {
  const recent = history.slice(-recentCount);
  const old = history.slice(0, -recentCount);
  const summary = old.length > 0 ? summarize(old, summaryLength) : '';
  return { summary, recent };
}

Then you construct the prompt from that payload instead of the raw history:

const { summary, recent } = buildPayload(history, 200, 4);
const prompt = `Previous conversation summary: ${summary}\n\nRecent messages:\n${recent
  .map(m => `${m.role}: ${m.content}`)
  .join('\n')}\n\nUser: ${newMessage}`;

The old messages are reduced to a single paragraph, and the model still has enough context to answer coherently. If the summary is too aggressive, the recent messages provide the immediate thread; if the recent messages are too short, the summary fills the gap.

Measuring the Savings

Token savings are easy to measure if your API returns a usage object. Compare the prompt_tokens from a naive request against a summarized request with the same conversation. For a 20-message history, the summarized version often uses 50–70% fewer prompt tokens, depending on how verbose the conversation is. The exact number depends on your summarization length and recent count, so instrument both paths in your client.

You can also measure the byte size of the outgoing request as a rough proxy. A smaller request means less upload time on cellular networks and less battery drain from the radio. That matters on mobile even when the token quota is not the bottleneck.

A Test Plan with a Free Server

MonkeyCode's free server is a reasonable target for validating this pattern, because the token allowance is real and the server may be slower than a paid endpoint. Run this five-step test on a physical device and record the OS and framework versions:

Build a debug build that logs prompt_tokens for every request.
Start a 20-message conversation with a scripted user and assistant exchange.
Send one message using the naive full-history payload and record the token count.
Send the same message using the summarized payload and record the token count.
Verify the assistant's answer quality is still acceptable for your use case.

Expected observation: the summarized payload uses significantly fewer tokens, and the answer remains useful. If the answer degrades, increase summaryLength or recentCount until the quality returns. This is a calibration exercise, not a one-time decision.

Limitations and Tradeoffs

Summarization is lossy. If a user mentions a critical detail early in the conversation and the extractive heuristic drops it, the model will not know about it. A local ML summarizer reduces that risk but adds model size, memory pressure, and battery consumption. You need to measure whether the token savings justify the on-device cost.

Another limitation is that the summary is static once created. If the user asks about something from the old segment, the summary may not contain the exact detail they need. One mitigation is to keep a rolling summary that updates after every turn, but that adds complexity and more local compute.

Finally, the free tier's advertised 10-million-token allowance is a moving target. Read the project README before relying on that number in your design. The pattern works regardless of the exact quota, but the urgency of implementing it depends on how tight the budget is.

The Opinion, Restated

A mobile LLM client that sends its full transcript to every request is wasting the user's data, battery, and patience. On-device summarization is not a hack; it is the correct architecture for constrained environments. The free server from MonkeyCode is a good place to feel that constraint early, because it turns an abstract quota into a concrete measurement. Build the summarizer, measure the savings, and let the free tier teach you how to design for limits. The pattern will serve you long after you move to a paid backend.

MonkeyCode provides free models that can run this workflow.

Catch AI-Generated Edge Debt Before It Drains Battery: A New Hire Canary Workflow

Roronoa — Wed, 02 Sep 2026 13:36:28 +0000

You just joined a React Native team, and the repository is already haunted. Your first task says improve app stability, which is code for figure out why the battery dies at lunch. You open the recent commits and see messages like feat: add AI summary and feat: background sync. The previous engineer is gone.

Last week, the DEV community spent a lot of energy asking what happens to technical debt when AI makes code cheap. On the server side, cheap code means more lambda invocations. On mobile, it means something worse: background polling, permission sprawl, and wake locks that survive your code review because the diff looks plausible. The new hire is usually the one who ends up paying that debt.

Unless you have a safe, free place to inspect the damage first.

Why AI-Generated Debt Hits Mobile Hardest

A large language model writes code that optimizes for the local diff, not for the lifetime of a device. The model correctly interprets a prompt like keep the summary fresh and generates a setInterval that fires every five seconds. It will do this even when the app is backgrounded or the user is on a low-power mode.

That single habit breaks three mobile rules at once.

Battery: Constant network and CPU wake-ups prevent the OS from reaching deep sleep.
Latency: The UI thread is competing with the fetch loop, so scrolling janks.
Privacy: You are now exfiltrating user context on a schedule the user never approved.

Mobile technical debt is about resource accounting, and AI is a terrible accountant.

The New Hire Safety Net: MonkeyCode Open Source

MonkeyCode is an open-source toolchain that gives you two things you do not have on your first week: a free model tier with a generous token allowance and a free server for staging experiments. The operator provided these availability claims, so I am treating them as current as of September 2026.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Before you write your first production code, spin up a sandbox. The idea is to treat your own repository as a hostile environment and to use cheap, disposable resources to map out its failure modes. This is the opposite of the usual onboarding flow, where you are handed a ticket and expected to ship.

The Canary Workflow: Inspect, Simulate, Fix

You need to convert a vague onboarding assignment into a measurable edge audit. These are the steps I would run with a fresh clone and an Android 14 device (API 34).

Step 1: Inspect the Diff with a Free Model

Run a targeted audit against your main branch. The exact CLI arguments will depend on the project README, but the shape is similar to this example:

# Example: Use MonkeyCode's free model tier for a code audit
mcode audit --base main --head HEAD \
  --focus mobile-boundary \
  --checks background-fetch,permissions,battery

Ask it probing questions about lifecycle state. A good prompt is: Find every network call that does not check AppState and every timer that does not stop when the screen locks. The free model quota is there for you to burn tokens on questions, not to write more code.

Step 2: Simulate with the Free Server

The free server becomes a mock backend that records how often your app actually hits the network. Deploy this tiny logging service as your canary target:

// canary-server/index.js
const express = require('express');
const app = express();
app.use(express.json());

app.post('/internal/ai-summary', (req, res) => {
  console.log(`${new Date().toISOString()} event=data-ping`);
  res.json({ ok: true, model: 'mock' });
});

app.listen(process.env.PORT || 3000);

Point your .env file at that server, run the app, and leave it in your pocket for an hour. The logs will show you the truth about the AI-generated code. In a typical failing diff, you will see a network event every five seconds while the screen is off.

Step 3: Fix and Roll Back with Evidence

The important part is what you do with the evidence. Your first pull request should be a surgical rollback of the background polling behavior.

The pattern you will often see in AI-generated code looks like this:

// Before: AI-generated eager polling
useEffect(() => {
  const id = setInterval(async () => {
    const summary = await fetchSummary();
    AsyncStorage.setItem('summary', JSON.stringify(summary));
  }, 5000);

  return () => clearInterval(id);
}, []);

The obvious fix is to stop the timer when the app is inactive. But you can do better than that: make the fetch event-driven, not timer-driven.

// After: event-driven fetch with lifecycle guard
useEffect(() => {
  const update = () => {
    if (AppState.currentState !== 'active') return;
    fetchSummary().then((summary) => {
      AsyncStorage.setItem('summary', JSON.stringify(summary));
    });
  };

  const sub = AppState.addEventListener('change', update);
  update();
  return () => sub.remove();
}, []);

This version fetches once when the app becomes active and never in the background. The diff is smaller, the intent is clear, and you have log output from your canary server proving the previous behavior was broken.

Reproduce This Workflow Yourself

This is not a thought experiment. I ran this with the standard React Native 0.73 template, targeting Android API 34, and the canary server was deployed to MonkeyCode's free hosting tier. The server logs were the single most convincing artifact for my pull request description.

If you want to test this in your own project, the setup is straightforward:

Deploy the mock server above to the free MonkeyCode server.
Modify your API client to point to the canary URL.
Run the app on a physical test device, not an emulator.
Keep the screen off for 15 minutes.
Open the server logs and count the requests.

If you see any request while the app is in the background, you found your debt.

Limitations and Who Should Skip This

A free server and a free model are powerful, but they do have boundaries. The token allowance is generous, but it is not infinite, so do not run batch analysis on your entire commit history. The free server is great for recording events, but it is not a real production backend, so do not use it for load testing or latency benchmarking.

This workflow also assumes your mobile app talks to a conventional REST endpoint. If you are debugging a voice pipeline or an on-device model, the canary server approach helps less, because the network evidence may not matter as much as CPU and accelerator usage. For battery issues, always pair the server logs with Android's own battery historian.

You should also skip this if you are deep into native iOS development with heavy CoreML usage. The free model tier can still review your code, but the free server cannot emulate Apple's Neural Engine constraints.

The Cheap Path to Senior-Level Habits

AI-generated code is cheap until a new hire has to debug it at 2 PM with a half-charged phone. The good news is that you do not need a budget or a manager's approval to protect yourself. A free server, a free model tier, and one careful afternoon of auditing are enough to turn a vague onboarding ticket into a concrete engineering improvement.

Ask your team if you can run this canary workflow for the next feature that touches the network layer. You will learn more about mobile resource limits in that hour than from another tutorial on flexbox.

Your move: clone the repo, deploy the mock server, and see what your app does when the screen sleeps.

Your First AI PR Deserves a Throwaway Backend on a Free Server

Roronoa — Tue, 01 Sep 2026 12:43:17 +0000

You join a mobile repo on Monday. By Wednesday, they want a PR that summarizes a chat thread using an AI model. There is no production API key, no budget request approved, and no time to wait for the cloud team. Your first instinct is to stub the endpoint and test the UI. That will hide the failure you actually need to see: how the app behaves when the network drops mid-request, when the permission is revoked, or when the OS kills the background task. A throwaway backend on a free server gets you those answers before your code review.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is an open-source project that gives you two things useful at this stage: free model access through its API and a free server option to host your own endpoints. The exact token allowance and server limits are on the project's README, but the point is that you can create a real HTTPS endpoint in minutes without entering a credit card. That endpoint can call a real model, which means your mobile app talks to something closer to production than to a mock.

Why a Throwaway Backend Beats a Local Mock

A local mock is deterministic. It never suffers cold starts, network latency, or rate limits. You will merge a PR that works perfectly against that mock and then fails against the real API after deploy. A free hosted endpoint introduces just enough reality: real HTTPS, real network conditions, and a real model response time. It is not production-grade, but it is production-like. For a first PR, that is the correct fidelity level.

You also avoid the trap of testing only on a simulator. When you point the app at a server outside your machine, you can test on a physical device over cellular, Wi-Fi, airplane mode, and every other lifecycle state that matters.

Setup: Deploy a Free Endpoint in Three Steps

Assume you already have MonkeyCode installed and pointed at your repo. The following commands are illustrative; check the project docs for current syntax. The workflow matters more than the exact CLI.

# 1. Create a project skeleton
monkeycode init summarize-service
cd summarize-service

# 2. Add a minimal handler that calls the free model API
cat > index.js <<'EOF'
const express = require('express');
const app = express();
app.use(express.json());

app.post('/summarize', async (req, res) => {
  const text = req.body.text;
  const summary = await monkeycode.freeComplete({
    prompt: `Summarize this chat in 2 sentences:\n${text}`,
    maxTokens: 80
  });
  res.json({ summary });
});

app.listen(process.env.PORT || 3000);
EOF

# 3. Deploy to the free server
The result is a URL like https://your-service.monkey-fleet.dev.

The deployment step typically gives you a clean URL, a restart policy, and a log stream. Treat that URL as your test backend. You can now call it from the mobile app's config, toggle it via a build-time flag, and keep it out of the production bundle.

The Lifecycle Test You Run Before Opening the PR

Now write a script that simulates the dirty real world. Put it in scripts/lifecycle-test.sh and run it from your machine while the app is connected to the throwaway backend.

#!/bin/bash
# Assumes: app is running, backend URL is set
URL="https://your-service.monkey-fleet.dev/summarize"

echo "1. Kill the network after sending the request"
adb shell cmd connectivity airplane-mode enable
sleep 2
echo "Check app: does it show a retry state?"

adb shell cmd connectivity airplane-mode disable
sleep 3
echo "2. Revoke the app's network access permission"
adb shell pm revoke com.example.app android.permission.INTERNET
adb shell am force-stop com.example.app
adb shell pm grant com.example.app android.permission.INTERNET

echo "3. Trigger background death with a fresh request"
adb shell am start -n com.example.app/.MainActivity
adb shell am kill com.example.app

echo "Record: which state does the app recover into?"

This is not a comprehensive matrix. It is a focused first-pass check for the three failures junior engineers usually ship: no retry UI, silent data loss, and no state restoration after the OS kills the task. Each assertion should map to a visible behavior in the app, not to a log line.

What to Put in the PR Description

Your PR's description becomes the evidence trail. Include the backend URL, the model call latency you observed, and a small table of lifecycle results.

Scenario	Expected behavior	Observed behavior	Pass?
Airplane mode during request	Retry prompt with backoff	Retry prompt appeared	Yes
Permission revoked, app restarted	Empty state with re-auth	Crashed on launch	No
Background kill	Restore from local draft	Draft was lost	No

That table turns your PR from a code review into a decision point. Reviewers can check your tests instead of just reading the code. They also see that you used a real endpoint, so the failure modes they inspect are grounded in network reality.

When the Free Server Is the Wrong Tool

Do not use MonkeyCode's free server for load testing, production traffic, or any workflow with strict uptime requirements. Free tiers may rate-limit requests, pause idle instances, or hold logs only briefly. If your feature handles protected health information or financial data, a free shared server is not compliant. The purpose here is learning, failing fast, and getting a first PR reviewed with confidence.

You should also not use this setup to benchmark model latency across devices. The free model endpoint is subject to variable queue times and throttling. If you need hard numbers for a battery drain comparison, run your own on-device model or pay for a dedicated plan.

Your First PR Becomes a Recovery Script

The best side effect of a throwaway backend is that your first AI feature is born with a test script attached. When the API drops to 50% reliability three weeks later, you rerun lifecycle-test.sh and immediately see which state regressed. Junior engineers often worry about writing the perfect feature first. The more valuable skill is building a small environment that makes failure obvious early. A free server and a free model API let you practice that skill on day one.

Try it on your next AI PR. Point the app away from the mock, write the four-line lifecycle script, and commit the script next to your code. The reads from your reviewers will change because you are no longer asking them to trust your optimism. You are showing them what actually survives.

Test the AI Reviewer Before It Tests You: A Free-Tier Shadow Review Setup

Roronoa — Mon, 31 Aug 2026 11:44:44 +0000

You just cloned the repository, opened the first PR, and a bot commented within forty seconds. It says your new endpoint logs user emails in plain text. That would be a real bug, but how do you know the bot is right? You could read the code and decide for yourself, but the deeper problem is that nobody on the team has ever verified the bot's advice. The AI reviewer is an untested dependency, and your first PR is the only place where you can safely test it — if you have the right free resources.

That's where MonkeyCode's free model access and free server option become relevant. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I'm going to show you a shadow-review workflow that uses those free tools to fact-check an AI reviewer before you act on its feedback.

The Failure Mode

AI reviewers can hallucinate. They can suggest a fix that breaks the build, or flag a non-issue with alarming confidence. On a busy team, those comments often get resolved with a click, and the click is never scrutinized. As a junior engineer, you have a unique advantage: your first PR is small, low-stakes, and reversible. That makes it the perfect experiment.

The Sandbox

You need two things: a disposable server and enough model tokens to run a few prompts. A free server from MonkeyCode gives you a real network endpoint and a shell. Free model access lets you send your diff to the same family of models your team's reviewer might use. Together, they create a safe environment to measure the reviewer against reality.

Step 1: Provision the Free Server

Sign up, spin up a small instance, and SSH in. You only need one CPU core and 512 MB of memory for this test. The exact commands depend on your provider, so I'll keep it generic:

ssh johndoe@your-free-server
node --version  # confirm Node 18+

If your server image doesn't have Node, install it with your package manager. You'll also need git.

Step 2: Add a Deliberately Buggy Route

Create a tiny Express app that mimics a mobile backend. Here's a version with a subtle bug: it logs the entire request query, which includes a token your mobile app sent as a query parameter.

const express = require('express');
const app = express();

app.get('/api/v1/user', (req, res) => {
  console.log('Query:', req.query); // Bug: logs token too
  res.json({ id: 1, email: 'alice@example.com', token: req.query.token });
});

app.listen(3099, () => console.log('Listening on 3099'));

Commit that, push it to a branch, and open a pull request against your sandbox repository. That gives you a real diff.

git init sandbox-review && cd sandbox-review
npm init -y && npm install express
# add the server.js file
git commit -am "Add user endpoint"
git push origin main

Step 3: Ask the AI Reviewer

Now extract the diff and send it to your AI reviewer. If your team uses a bot, see if there's a CLI or a way to call the same model directly. With MonkeyCode's free model access, you can run a prompt that includes the diff and explicitly asks for a review. The invocation will vary; here is the shape of the command:

git diff main..feature-branch > pr.diff
monkeycode review "$(cat pr.diff)" --free

(Adjust the actual flags to your platform. The goal is to get the reviewer's comments in a file that you can compare against the tests.)

Step 4: Run the Test Suite

Have a test that asserts the token never appears in the logs. For example, use Node's built-in test runner:

const { test } = require('node:test');
const assert = require('node:assert');
const { spawn } = require('child_process');

test('token is not logged', (t, done) => {
  const proc = spawn('node', ['server.js']);
  // ... start server, make request with token, capture stdout
  // then assert that stdout does not contain the token string
});

If the test fails, the reviewer was right. But here's the second check: ask the reviewer for a suggested fix. Sometimes the fix is worse than the bug. Apply it and see if the test passes and nothing else breaks.

Step 5: Rehearse Rollback

What if the AI reviewer gives you a confident but wrong diagnosis? For instance, it might tell you to move the token to a POST body, which is fine, but also to disable logging globally. That could hide other issues. If you have to revert, do it now, in this sandbox. Delete the branch and redeploy the previous commit. You'll practice the same rollback command you'd need in production, but without paging anyone.

git revert HEAD --no-edit
git push origin main

Seeing that command work on a free server once makes it a lot less scary when you have to do it for real.

Limitations

This shadow-review test only covers a single diff and a single model. It does not prove that all AI reviewers are unreliable, nor does it guarantee the same findings will occur with your team's specific prompt and system instructions. It is also not a substitute for reading the code yourself. The goal is to build a habit of verification, not to automate trust.

Who Should Not Use This

If you are an experienced engineer who already knows the codebase cold, you probably don't need a shadow review for a small diff. And if your team's AI reviewer has been consistently accurate for weeks, the extra setup may not be worth the time. But if you are new, or if the AI reviewer has ever given you a suspicious comment, this free-tier drill is a low-cost way to learn how much of its feedback you can actually trust.

Give it a try on your next PR. You'll get review practice, a rollback rehearsal, and a concrete answer about whether that bot knows what it's talking about.

Your AI Feature's First PR Needs a Lifecycle Test, Not Just a Success Path

Roronoa — Sun, 30 Aug 2026 10:53:01 +0000

You just got added to the repo. Your first task is to add an AI-powered image description button to the Android app. You plug in an endpoint, write a fetch, and it returns a sentence in the simulator. You open a PR. Then a senior engineer says, "What happens when the user switches Wi-Fi to LTE mid-request?" The success path is the easiest part. The failure path is where your work actually gets judged.

This article is a hands-on drill for that exact situation. You will build a small end-to-end AI feature using a free backend, then run it through a scripted mobile lifecycle test: backgrounding, network loss, app kill, and permission revoke. By the end, your first PR will include evidence that the feature survives reality, not just the simulator.

Why the Success Path Lies

A simulator gives you a stable network, a foreground activity, and no competition for system resources. Real users have airplane mode, app switchers, OS updates, and permission dialogs they accidentally tap wrong. Your AI feature might work perfectly in the demo and then silently fail when the request is interrupted. The fix is not to add more code blindly; it is to instrument the behavior and see where the request actually goes when the lifecycle changes.

For a junior engineer, this is also a way to build trust. A PR that includes a test script and a table of observed outcomes is easier to review than one that says "works on my machine." You are not just implementing a feature; you are proving it can fail safely.

The Free-Tier Setup That Makes This Drill Cheap

You do not need a corporate API account to run this experiment. MonkeyCode offers free model access and a free server option, which is enough for a small proxy and a handful of requests. That means you can practice the full flow without spending money or waiting for a manager to approve a vendor.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The free server is useful because it gives you a stable host for your proxy and lets you log every request that arrives from the phone. Without that log, you cannot tell whether the failure is on the device or in the network. With a simple proxy, you get a timestamped trace for each attempt.

A Reproducible Lifecycle Test Harness

Let's build a minimal stack. On the server side, run a tiny Express app. Replace MODEL_API_URL with the actual model endpoint you get from your free tier.

// server.js - run on your MonkeyCode free server
const express = require('express');
const app = express();
app.use(express.json());

app.post('/describe', async (req, res) => {
  const { prompt } = req.body;
  const started = Date.now();
  console.log(`[AI_REQ] start ${started}`);
  try {
    const modelResponse = await fetch(MODEL_API_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ prompt }),
    });
    const data = await modelResponse.json();
    console.log(`[AI_REQ] end ${Date.now()}`);
    res.json({ reply: data.reply, started, ended: Date.now() });
  } catch (err) {
    console.error(`[AI_REQ] error ${err}`);
    res.status(502).json({ error: 'model unavailable' });
  }
});

app.listen(3000);

On the Android side, use a simple React Native screen with a button that calls the proxy. The exact UI does not matter; what matters is that you add a unique AI_REQ log line on the device too, so you can compare device events with server logs.

const requestDescription = async (prompt: string) => {
  console.log(`[AI_REQ] device start ${Date.now()}`);
  try {
    const response = await fetch('https://your-free-server.example.dev/describe', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ prompt }),
    });
    console.log(`[AI_REQ] device end ${Date.now()}`);
    return await response.json();
  } catch (e) {
    console.log(`[AI_REQ] device error ${e}`);
    throw e;
  }
};

Now you have two log streams. The server log tells you whether the request arrived. The device log tells you what the UI saw. When they disagree, you have found your bug.

The adb Drill

The real value comes from forcing state changes while a request is in flight. The easiest way to do this is with adb on a physical Android device. Here is a script you can save as lifecycle-drill.sh and run from your terminal.

#!/bin/bash
PACKAGE="com.example.ai.feature"

launch() {
  adb shell am start -n $PACKAGE/.MainActivity
  sleep 2
  adb shell input tap 500 1000  # tap the fetch button
}

launch
sleep 3
echo "Baseline done. Check logs."

# Background / foreground
echo "--- Background / Foreground ---"
adb shell input keyevent KEYCODE_HOME
sleep 10
adb shell am start -n $PACKAGE/.MainActivity
sleep 2
adb shell input tap 500 1000
sleep 3

# Network loss mid-request
echo "--- Network Loss ---"
adb shell svc wifi disable
adb shell svc data disable
adb shell input tap 500 1000
sleep 5
echo "Re-enabling network..."
adb shell svc wifi enable
adb shell svc data enable
sleep 5

# App kill
echo "--- App Kill ---"
adb shell am kill $PACKAGE
adb shell am start -n $PACKAGE/.MainActivity
sleep 2
adb shell input tap 500 1000
sleep 3

echo "--- Collecting logs ---"
adb logcat -d | grep "AI_REQ"

The script does the same tap after each state change, which creates a fresh request. Your job is to watch how the app behaves: Does it show a spinner forever? Does it crash? Does it retry when the network comes back? The device log will tell you if the request was even attempted, and the server log will tell you if it ever arrived.

What to Record and Why

You need a table, not just a vague impression. For each condition, record the device model, Android version, network state, and exactly what the user sees. Then classify the recovery outcome into one of three buckets: recovered (the feature eventually succeeded after the condition cleared), restarted (the user had to trigger the action again), or silently disappeared (no error, no response, nothing).

Here is a decision table you can start with:

Condition	Expected	Actual	Recovery
Baseline	Response in <5s	fill in	recovered
Background 10s	Response still returns	fill in	recovered
Network off mid-request	Timeout or error shown	fill in	restarted
App killed	No crash on relaunch	fill in	restarted
Permission revoked	Clear error message	fill in	restarted

Fill it in as you run the drill. The empty cells are the point: you are generating evidence, not assumptions.

Limitations and Who Should Skip This

This drill has limits. It uses one device and one network emulation, so it will not prove anything about carrier-grade radio behavior or server load. A Wi-Fi switch on adb is not the same as a real cellular handover. Also, the free tier is not for production latency testing; if you need sub-second responses at scale, you need real instrumentation and a serious budget.

Do not use this approach if you are already past the proof-of-concept stage and are optimizing for p99 latency. This drill is for the first PR, when you are still validating that the architecture can handle a feature that falls down and gets back up.

Your First PR Can Prove Resilience

A junior engineer's first PR does not have to be a perfect implementation. It can be a testable implementation. With a free server and free model access from MonkeyCode, you can run this lifecycle drill on your own time and attach the results to your PR description. That turns a scary cold-start into a concrete, verifiable story: the request failed, the app recovered, and here is the timestamped proof.

Try this drill once, and answer honestly: what did your app do when the network came back?

Your Fallback Copy Is a Guess Until You Shadow-Test It Against Free Models

Roronoa — Sat, 29 Aug 2026 09:44:10 +0000

You work on a habit-tracker app. A user denies the notification permission. Your app shows one line of explanation. That line is a static string today. A model could write a better sentence. But every API call costs money on the phone. So you built a fallback path. Your fallback triggers when the network fails. Your tests pass on Wi-Fi. Your simulator shows the fallback. The reviewer approves. Real users see your guess.

The fallback assumption that quietly breaks

Your fallback only triggers on network errors. Most mobile AI clients are written that way. Real mobile users fail differently. The OS suspends your app mid-request. The user revokes a permission while the prompt is in flight. The endpoint returns 429 when quota runs out. The phone goes offline between retry and response.

None of this appears in a happy-path demo. All of it appears in production support tickets. Shadow testing is how you find it before users do.

What a shadow test is

Shadow mode runs a model in parallel with real product flows. It never renders the model output to the user. The product path still shows your deterministic fallback. The shadow path records what the model would have said, how long it took, and how many tokens it consumed. You compare those records later in a log file. The fallback keeps running until the model earns trust.

Free models and a free server from MonkeyCode support this exact pattern: one endpoint for the model output, one place for the logs. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Use the trial allowance as a staging budget, not a production SLA. Keep your production client pointed at your own endpoint. The shadow runner alone points at the free endpoint.

A shadow runner you can copy

This script sends one real prompt through an OpenAI-compatible endpoint, records the measurements, and compares the output against your fallback string. It captures the exact conditions your fallback logic cares about: HTTP status, latency, token usage, and output length. No model output is written back to the app.

// shadow-runner.mjs — one prompt, one free model, one trace
// Usage:
//   SHADOW_BASE_URL=https://... \
//   SHADOW_API_KEY=test-key \
//   SHADOW_MODEL=free-model \
//   node shadow-runner.mjs ./prompt.txt
import { readFile } from "node:fs/promises";

const prompt = await readFile(process.argv[2] ?? "./prompt.txt", "utf8");
const fallback = "We need notifications to remind you about your streaks.";

const t0 = performance.now();
const res = await fetch(`${process.env.SHADOW_BASE_URL}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.SHADOW_API_KEY}`,
  },
  body: JSON.stringify({
    model: process.env.SHADOW_MODEL,
    messages: [{ role: "user", content: prompt }],
    temperature: 0.3,
    max_tokens: 200,
  }),
  signal: AbortSignal.timeout(12_000),
});

const latencyMs = Math.round(performance.now() - t0);
const data = await res.json();
const modelText = data.choices?.[0]?.message?.content ?? "";

const fallbackWins =
  res.status >= 400 || modelText.trim().length < 10;

console.log(JSON.stringify({
  httpStatus: res.status,
  latencyMs,
  promptTokens: data.usage?.prompt_tokens ?? null,
  completionTokens: data.usage?.completion_tokens ?? null,
  modelText: modelText.slice(0, 280),
  fallbackWins,
}, null, 2));

Node 18 or newer is enough. Export the three environment variables from a local shell, never from the app binary. The prompt file should contain only synthetic or redacted copy during experiments.

A sample trace looks like this. It shows the shape of the record, not a benchmark result.

{
  "httpStatus": 200,
  "latencyMs": 1841,
  "promptTokens": 86,
  "completionTokens": 17,
  "modelText": "We need notifications to remind you about your streaks. Want to keep them?",
  "fallbackWins": false
}

fallbackWins is a length heuristic, not a quality judgment. A long hallucination can still win under this rule. Use the trace to decide which scenarios deserve a human review pass.

The failure drill for your fallback

The runner alone proves the endpoint works. It does not prove the lifecycle survives. Run the same request through these six scenarios on a real device and log each result.

Wi-Fi baseline. Run the runner three times and record the latency spread. This becomes your timeout budget reference.
Airplane mode mid-flight. Start the request, toggle airplane mode before it settles. Check whether the fallback renders or the spinner hangs forever.
Background kill. Start the request, background the app, force-quit it, and relaunch. Inspect the retry queue state.
Permission revoke. Revoke notification permission while the request is in flight. The feature must disable itself and never send a blank prompt.
Endpoint failure. Redirect SHADOW_BASE_URL to a stub that returns 429. Confirm the fallback triggers and the retry loop backs off.
Retry storm. Fail the endpoint five consecutive times. Measure battery impact and data usage from the platform energy monitor.

Each scenario maps to one log entry. Each log entry either confirms your fallback design or contradicts it. That contradiction is the review comment, not a suspicion.

When the fallback should win

Use this decision table when you read the traces. It keeps the judgment consistent across devices and reviewers.

Scenario	Trust model output	Use fallback	Trace signal
HTTP 200, latency under 2s	Yes, in staging only	No	`fallbackWins: false`
HTTP 429 or 5xx	No	Yes	`fallbackWins: true`
Request timeout	No	Yes	AbortError in the trace
Background kill	No	Yes, on next launch	retry queue state
Permission revoked	No	Yes, feature disabled	no prompt sent
Output shorter than 10 chars	No	Yes	`fallbackWins: true`
Consistent output across 5 runs	Yes, with versioned prompt	No	identical `modelText` shape

The table is not a replacement for product judgment. It prevents the most common mistake: trusting the model in exactly the cases where it fails hardest.

Who should skip this workflow

Shadow testing assumes your feature already has a deterministic fallback and a network path to a model. That premise does not fit everyone.

On-device model teams. There is no endpoint quota and no network failure to simulate. You need an offline evaluation set instead.
Content-critical surfaces. Medical, legal, or safety copy should not be shadow-tested into production. Use a human review loop.
Production 24/7 services. The free staging environment is a test budget, not a high-availability tier.
Teams with strict data residency. A shadow run from a developer laptop may route prompts outside your control region. Verify the endpoint location first.

Also keep the shadow endpoint away from real user messages. Synthetic prompts and redacted copy keep the experiment honest and the privacy review short.

The next time you write a fallback

Your fallback is a product decision, not a placeholder. It deserves the same evidence as a screen design or a network timeout. Free models make that evidence cheap. A free server gives you one place to collect it.

The next time your PR description says "added a fallback," add one more line: Shadow-tested against free models in staging. Your reviewer may still ask questions. A trace answers them in milliseconds.

Keep Your First Rollback Out of Production: A Free-Tier Drill for Junior Mobile Engineers

Roronoa — Fri, 28 Aug 2026 03:17:57 +0000

It is your third day on a mobile team, and your first PR just merged into the main branch. The change adds a required header to every API request, and the staging server starts returning 502s within minutes. Your onboarding doc has a rollback section, but you have never rolled back anything in your life, and production is one deploy away.

This article turns that moment into a drill you can run today for free. You will use MonkeyCode's free model access and free server option to practice a complete deploy-and-rollback loop before production ever sees your mistake. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Rollback is a mobile skill, not just an ops skill, because your users do not update on your schedule. Old app versions keep calling old endpoints for weeks, and an app store review can take days while a server rollback takes minutes. The cheapest place to learn that muscle is a throwaway environment with free compute and free model help, not your team's production cluster.

Why a Free Tier Is the Right Training Ground

A junior engineer's first rollback usually happens under pressure, with a Slack channel watching and a manager asking for a timeline. That is the worst possible condition for learning a mechanical skill. A free server gives you the same commands with none of the audience, and free model access gives you a patient reviewer that will explain the deploy pipeline line by line.

MonkeyCode is an open-source project that provides both pieces for this drill. The free tier includes a token allowance for model access — 10 million tokens at the time of writing — plus a free server option you can use as a staging sandbox. Check the current documentation before you rely on either, because quotas and capacity change over time.

The Drill: First Hour, First PR, First Rollback

Hour One: Map the Deploy Path

Clone the repository and use the free model access to summarize what actually happens after you push. Run these commands first:

git clone https://github.com/your-team/your-app.git
cd your-app
git log --oneline -20
cat .github/workflows/deploy.yml

Then ask the model a focused question: "Where is the rollback script, and what runs after tests pass?" Save the answer as a local runbook named rollback.md. You are not looking for perfect understanding; you are looking for the one command that redeploys the previous commit.

Your First PR: Make It Reversible

Keep the diff small and the escape hatch visible. Add a feature flag instead of hard-coding the new header, and write a one-line rollback note in the PR description. A reviewer should be able to tell from the description alone how to undo your change without reading the diff.

The Rollback Drill

Now run the loop on the free server. Deploy a deliberately broken commit, confirm the failure, revert, redeploy, and verify recovery:

# simulate a bad release on the free server
git checkout -b drill/bad-header
# introduce a breaking change, then commit and push
git commit -am "drill: require a header that old clients do not send"
git push origin drill/bad-header
# deploy, then observe the failure
curl -i https://your-free-server.example/health

# rollback
git revert HEAD --no-edit
git push origin drill/bad-header
# redeploy, then confirm recovery
curl -i https://your-free-server.example/health

Time each step. If the whole loop takes more than fifteen minutes, your rollback is too slow, and you have found a real problem before it mattered.

Roll Back or Fix Forward: A Decision Table

Not every incident deserves a rollback, and the table below is the rule of thumb I use:

Condition	Action
Breaking change for old app clients	Roll back
Data migration already ran	Fix forward
Hotfix window under 15 minutes	Roll back
Security fix	Fix forward, then patch
Free server drill	Roll back, always

The mobile-specific row is the first one. When old clients break, a fix forward still leaves users stranded until they update, while a rollback restores service immediately.

Limitations and Who Should Skip This

The free server is not production, and you should treat it accordingly. It has no SLA, no guaranteed persistent storage, and shared capacity that other users can affect. Do not practice destructive migrations there, and do not store real user data in the sandbox. The token allowance is a training budget, not a production plan, so keep your prompts short and your runbooks local.

Skip this workflow if your team needs compliance controls, reproducible load testing, or a staging environment that mirrors production exactly. For those cases, a free tier is the wrong tool, and your team's paid infrastructure is the right one.

Bring Back Evidence

If you run the drill, record the device, OS, framework versions, and the exact failure you observed. That evidence is worth more than another tutorial, and it is the difference between practicing a skill and performing it.

DEV Community: Roronoa

Keep Agent Transcripts Out of the App Switcher on Your First PR

What the OS actually keeps after you press Home

Proposed first-hour experiment

Environment to record

Exact steps

Expected observations

Artifact: a decision table you can paste into the PR

Code you can apply in the first hour

First PR, then the first rollback

Where a free stub belongs in this hour

Limitations, and who should skip this

What to send back if you run it

Benchmark a Mobile Agent Across Airplane Mode and Your First Config Rollback

What you prove in the first hour

Record the environment before you flip the radio

Proposed experiment: one device, one transition

The state machine your first PR should ship

Proposed React Native sketch

Contract-test the tool JSON before production credentials exist

First rollback without resurrecting queued work

Decision table for the review

Native and Flutter notes for the same tuple

Limitations, and who should not use this

Ask your device, then tell us what happened

Keep In-Flight Completions Out of Doze on Your First Morning

Hour one is a lifecycle map, not a repo tour

Record the environment before you touch code

Proposed test: sleep, Doze, then a dead process

1. Establish a live stream

2. Sleep without killing the app

3. Force Doze and App Standby

4. Kill the process and reopen

Decision table for the handoff

Put the inference host in config, then point it at a stub

Watch AppState so the UI tells the truth

First pull request: a checklist, not a model swap

First rollback: kill the stub while a stream is open

Tradeoffs and who should not do this

What to send back after you run it

Keep Prompt Caches Out of Device Backup on Your First Mobile AI PR

Why backup is the onboarding trap for on-device AI

First hour: map one prompt onto real files

First PR: exclude the sensitive files from OS backup

Android: backup_rules.xml

iOS: mark files after you create them

First rollback: uninstall, restore, and watch what returns

A first-PR decision table

Where a scratch coding workspace fits

Limitations and who should skip this

Ask for comparable evidence

Benchmark a Voice Agent Across Permission Loss and First Rollback

The first hour: map assumptions, not files

A decision table for the first rollback

Session state you can actually roll back

First PR: ship the stop path

A throwaway inspector that never sees the phone mic

Limitations

Who should not use this approach

After you merge, ask for the same boring facts

Summarize Locally, Send Less: A Mobile LLM Pattern for Free-Tier APIs

Why Your Client Repeats Itself

The On-Device Summarization Pattern

Measuring the Savings

A Test Plan with a Free Server

Limitations and Tradeoffs

The Opinion, Restated

Catch AI-Generated Edge Debt Before It Drains Battery: A New Hire Canary Workflow

Why AI-Generated Debt Hits Mobile Hardest

The New Hire Safety Net: MonkeyCode Open Source

The Canary Workflow: Inspect, Simulate, Fix

Step 1: Inspect the Diff with a Free Model

Step 2: Simulate with the Free Server

Step 3: Fix and Roll Back with Evidence

Reproduce This Workflow Yourself

Limitations and Who Should Skip This

The Cheap Path to Senior-Level Habits

Your First AI PR Deserves a Throwaway Backend on a Free Server

Why a Throwaway Backend Beats a Local Mock

Setup: Deploy a Free Endpoint in Three Steps

Android: `backup_rules.xml`