How RapidNative Uses Multiple LLMs to Generate Better React Native Code

Most AI code generators bet the entire user experience on a single large model. Send the prompt, wait for a response, render the output. It is simple, and it is also why most of them feel slow, expensive, and brittle.

RapidNative takes a different approach. Behind every "build me a fitness tracker" prompt is a multi-LLM pipeline that strategically deploys different models at different stages — each picked for the job it is actually good at. A small, cheap model reads your project. A large, smart model writes your code. A vision model interprets your screenshot. A specialist routes the whole thing through six providers with automatic fallbacks.

This post is a tour of that architecture. We will walk through the four-step generation pipeline, the role each LLM plays, why we use six providers instead of one, and what this design buys you in practice — faster output, better React Native code, and inference costs that stay sustainable as you iterate.

Modern AI app builders run dozens of model calls behind every prompt — Photo by Hal Gatewood on Unsplash

Why a Single LLM Cannot Handle Production Code Generation

Multi-LLM code generation is the practice of routing different stages of a code-generation request to different language models — a fast, cheap model for context gathering, a powerful model for the actual code, and a multimodal model for image inputs. The result is faster, cheaper, and more accurate output than any single model can produce alone.

If you have ever used a one-model AI builder, you know the pain points. The model has to do everything in one shot: understand your existing project, decide what files to read, pick image assets, plan the screen, then write the code. With a frontier model like Claude Sonnet 4.5 or GPT-5, every one of those tool calls bills at premium rates. With a cheaper model, the code quality collapses.

The single-LLM approach forces a brutal trade-off:

• Use a small model: low cost, low latency, but the React Native code is full of layout bugs, deprecated imports, and Tailwind classes that do not exist in NativeWind.
• Use a large model: high quality, but every "list the files in my project" call burns the same dollar-per-million-tokens that you really only need for the code generation itself.
• Use one model for everything: pay frontier prices for janitorial work, and watch the user wait while the model reads twelve files it did not need to read.

The fix is to stop treating code generation as a single task. It is a pipeline of distinct sub-tasks, and each sub-task has its own ideal model.

The Three Roles RapidNative Assigns to LLMs

Inside RapidNative, every model fills one of three roles, defined explicitly in the model configuration layer at src/modules/api/services/ai/llm/types.ts. Each role has different requirements, so each gets a different class of model.

1. Context Gathering (fast and cheap)

Before the main model writes a single line of code, a smaller model reads your project. It calls tools like get_files_content, batch_grep, and get_images_by_keywords to figure out what already exists, what the user is asking for, and what assets are available.

This stage benefits from speed and aggressive caching far more than from raw reasoning. RapidNative typically routes it to a claude-3-haiku, meta-llama/llama-3.3-70b-instruct, gemini-1.5-flash, or z-ai/glm-4.6 — all priced at fractions of a cent per thousand tokens. A typical context-gathering pass costs around $0.000055 to $0.0003 per 1K tokens, versus $0.003 to $0.015 for the main generation.

2. Main Code Generation (slow and smart)

Once the context is gathered, the user's intent is clear, and any database schema or auth scaffolding has been resolved, RapidNative hands the full picture to a frontier model that does nothing but generate code.

This stage runs on anthropic/claude-sonnet-4-5, gemini-2.0-flash-exp, qwen/qwen3-coder, deepseek/deepseek-coder, or other top-tier coding models. The model receives the entire system prompt, the gathered context, and the conversation history — but no tools. We deliberately strip tool access so the model focuses on writing tight, mobile-correct React Native code instead of detouring to read more files.

3. Vision (multimodal)

When a user uploads a screenshot, sketches a wireframe, or pastes a Figma frame, the request becomes a vision problem. RapidNative routes those calls to a multimodal model — claude-sonnet-4-5 with image input, gemini-pro-1.5, or kimi-k2.5 (Moonshot). The image becomes a multimodal message part in the AI SDK call:

const imagePart: ImagePart = {
  type: 'image',
  image: imageUrl,
};

The vision model translates pixels into a structured plan, which then flows back into the same downstream code generation. The user never sees the handoff — they just see their sketch turn into a working React Native screen.

Vision-capable LLMs interpret sketches and screenshots into structured React Native code — Photo by Christopher Gower on Unsplash

Inside the Four-Step Generation Pipeline

The three roles above slot into a four-step pipeline that runs on every chat-to-code request. The orchestration logic lives in src/app/api/user/ai/generate-v2/route.ts. Here is what happens between the moment you hit Send and the moment the first line of code starts streaming back.

Step 1: Context Gathering with Tools

The first model is the context-gathering LLM, configured with toolChoice: 'auto' and maxSteps: 10. It can call any of six tools:

1. get_files_content — read project files (with line ranges)
2. batch_grep — regex search across the codebase
3. get_images_by_keywords — pull stock images for UI components
4. list_skills, search_skills, read_skills — load reusable patterns from the skills system

The model decides which tools to call. For a brand-new project, it might just glance at the skills registry. For "add filtering to my product list screen", it grep-searches for the existing component, reads it, and pulls related files. The pass runs at temperature 0.7 with an 8,000-token output cap — small enough to stay cheap, large enough to summarize what it found.

Crucially, the context-gathering model also emits semantic signals — short tags like NEW_SCREEN: yes or AUTH: required that downstream stages parse to make deterministic decisions.

Step 2: Auth Detection from Semantic Signals

Step 2 is not really a model call — it is a parser. The pipeline reads the AUTH signal from Step 1's output and decides whether the request needs an authentication scaffold. This is a great example of using a small model to summarize intent, then letting deterministic code act on the summary instead of asking the big model again. It is faster, cheaper, and more reliable.

Step 3: Deterministic Generation Tools

Step 3 runs targeted helper tools — database schema generation and auth page scaffolding — based on the signals from Step 1. Each tool is either fully deterministic (template substitution) or backed by a single, scoped MAIN_GENERATION call with maxSteps: 1. By restricting these calls to one step, RapidNative prevents the model from wandering off and re-reading the project.

Step 4: Pure Code Generation

This is where the frontier model finally writes the screen. By the time Step 4 runs, the system prompt includes:

• The role section (expert React Native + Expo developer)
• Mobile-native rules (Yoga layout engine constraints, SafeAreaView patterns)
• The unsupported Tailwind blacklist (space-x, space-y, grid, etc.)
• The allowed imports list (React Native primitives, lucide icons, NativeWind)
• Template-specific path prefixes (app/(app)/ vs app/)
• The full output of Step 1's context gathering
• Any selected code (for point-and-edit operations)

The model runs at temperature 0.6, maxTokens: 32000, maxSteps: 1, and no tools. It produces one streaming response, which the client renders as the code generates.

This separation is the core insight: the model that decides what to build is not the model that builds it. Each model is doing the work it is best at, and nothing else.

Model Selection: Why We Use Six Providers

RapidNative's ai_model_config table maps every model to one of six provider integrations, each chosen for a specific reason:

1. OpenRouter — primary routing layer with sub-provider fallbacks (Cerebras, Together, Fireworks, Groq, DeepInfra). When one host is congested, OpenRouter transparently retries on another.
2. AWS Bedrock — for enterprise customers who need their inference inside an AWS account. Used for us.anthropic.claude-sonnet-4-5-20250929-v1:0 and claude-3-haiku-20240307-v1:0.
3. Google Vertex AI — for Gemini models with VPC controls and regional pinning.
4. Azure AI Foundry — supports both Claude and OpenAI families with Microsoft compliance.
5. Anthropic direct — lowest latency to Claude when prompt caching matters most.
6. OpenAI direct — for GPT-family models in narrow internal use cases.

The provider order is configured per model in code:

if (config.providerOrder.length > 0) {
  return {
    openrouter: {
      provider: {
        order: config.providerOrder,
        allow_fallbacks: true,
      },
    },
  };
}

If one sub-provider 503s, the request retries on the next one without surfacing the error to the user. For a real-time tool where users watch code stream in, that resilience matters more than shaving a millisecond off the happy path.

The dependencies in package.json reflect this multi-provider strategy:

"@ai-sdk/anthropic": "^1.2.12",
"@ai-sdk/amazon-bedrock": "^1.1.6",
"@ai-sdk/azure": "^1.3.25",
"@ai-sdk/google-vertex": "^1.0.4",
"@anthropic-ai/sdk": "^0.53.0",
"@openrouter/ai-sdk-provider": "^0.7.3",
"ai": "^4.3.19"

The Vercel AI SDK sits on top, providing one uniform interface — streamText, generateText, generateObject — across every provider. That abstraction is what makes swapping models cheap. Want to A/B test Gemini against Claude on the main generation step? Flip a row in the ai_model_config table. No deploy.

How Tool Calling Bridges the Models

The link between the context-gathering model and the main generation model is structured tool calling, defined in src/modules/api/services/ai/providers/ToolsProvider.ts. Each tool has a JSON schema, a description the model reads, and a server-side handler.

A typical Step 1 call looks like this:

const step1Result = await streamText({
  model: contextModel,
  messages: contextMessages,
  tools: contextTools,
  toolChoice: 'auto',
  temperature: 0.7,
  maxTokens: 8000,
  maxSteps: 10,
  providerOptions: contextProviderOptions,
});

Not every model handles tool calling equally well. RapidNative's per-model configuration explicitly disables batch_grep for qwen/qwen3-coder and meta-llama/llama-3.3-70b-instruct because both models tend to call it on irrelevant queries and burn tokens. Claude Sonnet 4.5 gets the full tool set — it knows when to use them and when to stop.

This per-model tuning is the difference between a multi-LLM system that works in production and one that looks great in benchmarks but melts in real traffic.

Tool calling lets context models read your existing screens before code is generated — Photo by Carl Heyerdahl on Unsplash

Prompt Caching, Streaming, and Cost Engineering

A multi-LLM pipeline is only useful if you can keep the per-request cost predictable. RapidNative uses three techniques to do that.

Anthropic Ephemeral Cache

Before sending the system prompt to Claude, RapidNative tags it with ephemeral cache control:

if (cacheType === 'anthropic') {
  (codeGenMessages[0] as any).experimental_providerMetadata = {
    anthropic: { cacheControl: { type: 'ephemeral' } },
  };
}

Anthropic's prompt caching feature lets repeated content (system prompts, large context blocks) bill at a 90% discount within a five-minute window. For follow-up requests in the same chat — extremely common when iterating on a screen — this is the difference between a 10-cent generation and a 1-cent generation.

Persistent SSE Streaming with Reconnection

Step 4 streams its output to the client over Server-Sent Events. To survive flaky mobile connections, RapidNative buffers the stream into a Vercel KV-backed log keyed by streamId. If the client disconnects and reconnects, resilientSSE.resume() replays missed chunks from the buffer. The user does not lose their generation if their phone briefly drops Wi-Fi.

Events are formatted as:

function formatSSE(event: string, data: unknown): string {
  return `event: ${event}\ndata: ${JSON.stringify(data)}\n\n`;
}

The event types — start, text, done, error, usage, screen_limit_exceeded — let the client render structured UI states instead of just dumping raw text.

Per-Purpose Pricing and Detached Billing

Cost calculation is centralized in calculateModelCostAsync(), which knows the per-provider, per-purpose rate. Credit deduction runs after the response completes, inside Next.js' after() lifecycle hook. The user's screen has already streamed in by the time the credits are debited, saving roughly 800ms of perceived latency on every generation.

Specialized AI Models Outside the Main Pipeline

The four-step pipeline handles code generation, but RapidNative runs several other AI workloads that each get their own dedicated model.

• Sentiment analysis — meta-llama/llama-3.1-8b-instruct returns a {score: -1.0 to 1.0} JSON for each user message. At ~$0.000055 per 1K tokens, you can run it on every message and it costs essentially nothing.
• User message analysis agent — extracts a structured profile (userProfile, userIntention, biggestFrustration, projectCategory) using generateObject and the same cheap Llama model.
• Support chat — runs on google/gemini-2.0-flash-001 for streamed help-desk responses, with automatic pause when a human takes over.
• Support reply drafts — uses perplexity/sonar (with built-in web search) to draft replies grounded in current docs and changelogs.
• App icon generation — bypasses LLMs entirely and calls fal-ai/flux/schnell to generate three icon variants (flat, gradient, 3D) in parallel with Step 1 of the main pipeline.

The takeaway is that "multi-LLM" is not just one big model plus one small model. It is a portfolio of specialists, each picked because it is the cheapest and fastest model that solves its problem at acceptable quality.

Why Multi-LLM Code Generation Beats Single-Model Approaches

When teams ask why we did not just pick one model and tune it, the answer comes down to four numbers that each fall out of this architecture.

1. Time to first token. The user sees code start streaming in seconds, not after a full reasoning pass. The fast context model warms up the data; the main model only starts when there is something useful to say.
2. Code accuracy. Because the main model never burns its context window on file listings or grep results, more of its capacity goes into producing valid React Native — fewer hallucinated imports, fewer unsupported Tailwind classes, fewer broken layouts.
3. Cost per generation. Routing simple operations (sentiment, intent extraction, file reads) to sub-cent models keeps margins healthy even on the free tier. The frontier model only runs when frontier reasoning is needed.
4. Resilience. Six providers and OpenRouter's sub-provider fallbacks mean a single outage does not take RapidNative down. A Bedrock hiccup quietly rolls over to OpenRouter; an OpenRouter sub-provider failure rolls over to its peers.

You can see all four of these in action by opening RapidNative and watching how quickly the first prompt resolves. The shape of the experience — the fast first response, the clean code, the affordable iterations — is the architecture made visible.

Multi-model orchestration is what lets a chat prompt produce a working React Native screen in seconds — Photo by Rob Hampson on Unsplash

Where Multi-LLM Architecture Goes from Here

The most interesting part of building a multi-LLM system is that the lineup is never finished. Models keep getting cheaper and smarter — Llama 4 changes the context-gathering economics, the next Claude release shifts where the main-generation budget goes, and a new vision model rearranges the screenshot-to-code stack.

A database-driven configuration like RapidNative's ai_model_config is what turns those external shifts into a one-row change. No deploy, no code rewrite. The model menu evolves in days, not quarters.

If you are building anything serious on top of LLMs in 2026, the architectural question to ask is not "which model should we pick?" — it is "which models, doing which jobs, routed how?" That is the difference between a prototype and a product.

Try It Yourself

The fastest way to see how multi-LLM code generation feels in practice is to use it. Open a free RapidNative project, paste a prompt, and watch the pipeline run.

• Start building a React Native app from a prompt
• Turn a screenshot into a working app with the vision model
• Generate from a PRD instead of a chat prompt
• See pricing for the credit-based plans

If you want to go deeper on the underlying systems, the two-step AI pipeline post and the chat-prompt-to-production-code deep dive cover the bundler and end-to-end request flow that pair with the model architecture above.

Multi-LLM code generation is the substrate. What you build on top of it is the product.