Claude Opus 4.7 for a mobile app prototype: use it for one turn, not every turn

Open mk0r.com, type one sentence describing the app, watch Haiku 4.5 stream the first screen into the preview iframe. That first draft is free and takes seconds. Then sign in, upgrade to a paid session, click the model picker chip, and switch from 'Scary' (haiku) to 'Smart' (opus[1m]). Use Opus 4.7 for ONE prompt, the planning turn for whatever cross-screen change comes next. Then switch back to 'Scary' to actually write the files. Opus 4.7 is wired into mk0r as the picker entry 'opus[1m]' in MODEL_LABELS at src/components/header.tsx line 768; the [1m] suffix selects Anthropic's 1M-token long-context variant.

Because vibe coding is a back-and-forth, not a single shot. The thing that decides whether the loop converges is iteration count per unit of attention. Opus 4.7 is roughly 5x the per-token cost of Haiku 4.5 on output, and Opus also plans before it writes, which adds latency on every turn. On a fresh single-screen build, neither the planning compute nor the larger model is doing work the user can tell apart from Haiku, so all you are buying with Opus is a slower loop and a bigger bill. Opus only earns its keep on turns where the answer is not in any one file, which on a mobile prototype is the cross-screen state planning turn and the cross-file debug. Everywhere else, run Haiku.

Claude Opus 4.7 with the 1M-token context variant. The picker chip lives in src/components/header.tsx and reads from a four-entry MODEL_LABELS map: 'default' shows as 'Fast', 'haiku' as 'Scary', 'sonnet[1m]' as 'Fast+', and 'opus[1m]' as 'Smart'. The labels are an opinion about the loop, not the leaderboard. 'Smart' is the right word because Opus produces the kind of output you have to read through to evaluate; the win is reasoning quality, not perceptual speed. Anonymous and free-tier users are pinned to 'haiku' by FREE_MODEL = 'haiku' in src/app/api/chat/model/route.ts line 5. The 'opus[1m]' option only appears callable for an authenticated session that is entitled or routing inference through a connected Claude.com plan.

The planning turn does not edit any files. The prompt has the shape 'we have <n> screens, the data is in <where>, I want to <change>, write me a plan and a list of files to change.' Opus 4.7 reads the conversation history, the file tree the agent already built, and writes back a numbered plan with file paths and the order of edits. Then you switch the picker back to 'Scary' and prompt 'execute the plan.' Haiku takes the plan and writes the files. The reason this split works is that the expensive part of vibe coding is figuring out what to ask for. Once you know what to ask for, Haiku can almost always write it.

Yes, by a meaningful amount. Anthropic notes that Opus 4.7 uses a new tokenizer that may use up to 35% more tokens for the same fixed text compared to previous Opus models. The headline per-token rate dropped versus Opus 4.1, so the net effect for a typical vibe-coding session is still a real price drop, but the multiplier is not the full one you would estimate from the rate card alone. The practical workflow consequence is the same as the latency consequence: every Opus turn that did not need to be on Opus is paying for more tokenization than it is producing, on top of the larger model premium. Keep planning turns on Opus, write turns on Haiku.

Yes. mk0r supports an OAuth path to Claude.com so the inference for every turn is billed against your Pro or Max plan instead of mk0r's shared API key. The picker labels still apply; what changes is who pays the per-token cost. With the OAuth path, Opus turns count against the rolling weekly cap on your Pro or Max plan rather than against an mk0r usage line. Heavy users who already pay Anthropic for Claude Code typically pick this path because it makes builder turns flat-rate, which means the only thing left to optimize is the picker discipline above: do not waste an Opus turn on a Haiku problem.

Not much, and that is the point. Every model in the mk0r picker writes mobile-first HTML/CSS/JS by default, because the system prompt the agent loads in the sandbox already constrains the viewport, the spacing, and the touch targets. The model's job is the logic, not the breakpoints. So the choice between Haiku, Sonnet, and Opus 4.7 for a mobile prototype is not 'which one understands mobile better.' It is 'which one matches the shape of this turn.' Layout-and-styling turns are Haiku turns regardless of how complex the screen looks. State-migration turns are Opus turns even if the screen looks simple.

mk0r is honest about this: the output is HTML, CSS, and JS, mobile-shaped, running in a real Chromium inside the sandbox. That is the right shape for a throwaway prototype, a demo link you can share in a Slack thread, a clickable thing for a stakeholder review. It is not the right shape for App Store submission or for native APIs like CoreMotion or background fetch. If your prototype is going to ship as a native app, mk0r is the place you build the disposable first draft to learn what the screens should be. After that, you hand the spec to a native dev, or you migrate the working layout into a React Native or Expo project. Opus 4.7's planning turn is also the right place to write that migration plan when the time comes.

The picker chip in the header POSTs to /api/chat/model with the new modelId for the current sessionKey. The route at src/app/api/chat/model/route.ts validates entitlement, calls setSessionModel under the hood, and the next turn runs on the new model with the conversation history intact. There is no reset. The agent process continues, the same files in /app are still there, and you can interleave Haiku, Sonnet, and Opus turns inside one prototype session. That is the reason the workflow above is feasible at all: switching between Haiku and Opus is one click, not a session reset.

On a small prototype, often no. Sonnet 4.6 is good enough at multi-file coordination that the planning turn it writes is usually fine. The case where Opus 4.7 noticeably beats Sonnet for planning is when the conversation history is long enough that earlier context starts to matter, or when the change crosses concerns that span more than two or three files. For a one-week throwaway prototype, the realistic split is Haiku for almost everything, Sonnet for the cross-screen turns, and Opus reserved for the one or two refactors where you actually feel Sonnet getting confused. The money you save on the wrong picker setting is not small over a hundred turns.