Two Balances, Not One: Reading Rork's Build Credits and Cloud Credits Apart

I opened the account menu to check what I had left, and there were two numbers sitting side by side. Credits, and Cloud Credits.

One was a count. The other was in dollars. The same word — credit — was doing two different jobs in the same menu.

For a while I read them as one wallet. That did not serve me well. I could see the numbers going down, and I could not tell which of my actions had moved them.

Build credits are what I spend. Cloud credits are what my users spend. Once I wrote that line down, the billing screen started making sense. Here is the order I now check things in, and the three places where it gets confusing.

They bill for different work, at different moments

Rork's own Build credits vs Cloud credits page describes them as two balances that are billed and topped up separately. That framing is the whole starting point.

The Cloud side starts with a one-time dollar of free credit when you switch Rork AI Cloud on for a project, and the docs are explicit that it only drops when your app actually uses a cloud feature.

So the Cloud balance tracks traffic, not effort. That is the sharpest difference between the two.

Two screens tell you which one moved

The check itself is short. What helps is doing it in the same order every time.

1. Open the account menu from your avatar in the top right. Credits (build) and Cloud Credits (the dollar balance) are shown together there.
2. Open the Build Credits tab in billing. You get the remaining balance, subscription credits versus usage credits, your current plan, and a way to top up.
3. Open the Cloud Credits tab. You get the USD balance, an Add funds section that goes from $5 to $200 at a time, and the Use Cloud Credits toggle.
4. Open Cloud Usage in that same tab. The last 30 days are broken down by AI model and by project.

Step four is where the answer usually lives. If nothing is listed for the period you are asking about, the spend was on the build side. If one model name dominates the list, you can narrow it down to the feature in your app that keeps calling it.

When a charge still looks wrong, the docs ask you to bring the project link, the rough time, and the action you took. Collecting those three before you write means the support thread finishes in one round trip.

One prompt does not always cost one credit

Plans & Subscriptions defines a credit as a unit of AI compute — roughly one request where Rork designs, builds, or edits your app. The same page carries a caveat that quietly breaks most estimates.

iOS builds and cloud simulator sessions rent real machines, so they are charged on top of the message that started them.

Count your credits by counting your prompts and the gap widens on exactly the days you iterated most on previews. I tracked conversations for my first stretch and only learned the difference at the end of the month.

The per-plan allowances are worth having in view:

The reset dates do not line up either. Paid plans reset on the anniversary of your first purchase; the free plan resets at the start of the calendar month. That mismatch is usually why refills arrive a few days off from when you expected them. On the daily cap specifically, I went deeper in Rork's Free Tier Gives You 35 Credits a Month, but the Number That Shapes Your Work Is 5 a Day.

A balance that never moves is its own kind of problem

This is the part I would have wanted someone to tell me first.

The docs carry a warning: if Use Cloud Credits is off for a project, the app stays on legacy features and will not use Rork AI Cloud at all.

Which means a Cloud balance that sits perfectly still after you added AI features is not necessarily thrift. More often it means nothing is being called.

I lost days to the same shape of problem elsewhere. While running one of my own sites, the feature was implemented correctly and a single toggle in the dashboard was off, and I kept re-reading my code looking for the bug. Do not read a still balance as a sign that things are working. Since then I check the switch before I suspect the implementation.

Three checks are enough: the toggle state, whether Cloud Usage shows requests for that day, and whether the model you expected appears in the per-model breakdown. If all three come back empty, you have a settings problem rather than a code problem.

Once you ship, someone else is spending it

Build credits stop when you stop. Cloud credits do not. With the app live, the balance moves every time a user touches a feature that calls out to the cloud.

Rork offers a low-balance email alert and auto top-up that refills when you run low. Both are designed so your app does not stall mid-use. Neither is designed to stop you from overspending. Those are different goals and worth keeping separate in your head.

So put the ceiling in the app. Count per-user calls per day in a backend function and refuse the ones past the line — that alone flattens most of the surprising growth curves.

// ai-proxy.ts — a minimal gate protecting the Cloud balance after launch.
// Caps AI calls per user per day and refuses anything beyond it.
 
const DAILY_LIMIT = 30;
 
type UsageRow = { count: number; day: string };
 
type Deps = {
  userId: string;
  // Wherever you keep per-day counts (Supabase, KV, anything durable)
  getUsage: (userId: string, day: string) => Promise<UsageRow | null>;
  bumpUsage: (userId: string, day: string) => Promise<void>;
  callModel: (prompt: string) => Promise<string>;
};
 
export async function handleAiRequest(req: Request, deps: Deps): Promise<Response> {
  const day = new Date().toISOString().slice(0, 10); // e.g. "2026-09-15", bucketed in UTC
  const row = await deps.getUsage(deps.userId, day);
 
  if ((row?.count ?? 0) >= DAILY_LIMIT) {
    // Expected response: { "error": "daily_limit_reached", "limit": 30 } with status 429
    return new Response(
      JSON.stringify({ error: "daily_limit_reached", limit: DAILY_LIMIT }),
      { status: 429, headers: { "Content-Type": "application/json" } },
    );
  }
 
  const { prompt } = (await req.json()) as { prompt: string };
 
  // Increment before the call, and do not roll it back on failure
  await deps.bumpUsage(deps.userId, day);
 
  const text = await deps.callModel(prompt);
  return new Response(JSON.stringify({ text }), {
    headers: { "Content-Type": "application/json" },
  });
}

The increment sits before the model call on purpose. Put it after, and a request that dies partway through never gets counted while the spend still happens. Double-counting is the safer direction to fail in.

Pick the actual limit after reading the per-model breakdown in Cloud Usage, not before. Per-call cost swings by an order of magnitude between models, so a raw call count tells you very little about dollars.

I ship wallpaper apps as an indie developer, and I thought I was used to costs that move with how people use a thing rather than with what I do. The Cloud balance still felt different. A prepaid balance shrinking outside my own hands is not the same sensation as a usage bill arriving after the fact.

If you are reconsidering the plan itself, Rork Pricing Compared: Free vs Pro vs Max and Rork's Free Plan and Free Trial — What You Actually Keep When the Credits Run Out cover the ground around this one.

If you check one thing today

Open Cloud Usage in billing and look at the model name on the largest row of the last 30 days. Ask whether that name matches the model you believe you are using. That single comparison is enough. If it does not match, something in your prompts is switching models on you.

Thank you for reading this far. I hope the two balances feel a little easier to hold apart than they did.