Base44 Credit System Explained: Why You Run Out and How to Stop

Base44 credits come in two types. Message credits pay for prompts to the AI builder, which Base44's docs estimate at about 0.5 credits for a simple text change up to 3–4 for an app-wide change, and about 0.3 for a Discuss-mode message. Integration credits pay for your running app's calls to Base44's built-in services: about 1 credit for an email or an image, about 15 for a GPT-5.4 call. Both reset monthly, unused credits expire, and the documented way to get more before reset is a plan upgrade. Agent iteration drives burn while you build; integration calls drive it once the app has traffic. Cut burn via narrow-scope prompts that name the file and lines, reverting instead of re-prompting, caching deterministic integration results in entities, and tracking burn rate as an explicit weekly metric.

Why this matters

Credits are the line on a Base44 bill that surprises teams. The subscription is predictable. The credit overage is not. Credits can quietly become the largest single cost in a team's monthly stack, larger than the platform subscription itself, and much of that burn is reducible with a few mechanical changes.

This article, written by the lead engineer at Base44Devs, is the working model for how credits actually work, what consumes them disproportionately, and the specific patterns that cut burn without changing the team's velocity.

How credits actually work

Four rules to internalize, each taken from Base44's Credits documentation (read 23 September 2026):

1. Credits reset monthly and expire. Paid plans reset "on your reset date, which is the same day of the month you subscribed", at the exact time of purchase in UTC. The Free plan allows up to 5 credits a day and 25 a month. "Unused monthly credits expire at the end of your credit cycle and do not carry over to the next month."
2. The documented way to get more before reset is an upgrade. When you hit the limit, actions that need credits pause until your reset date; "if you prefer not to wait, you can upgrade or adjust your plan". No separate credit-pack purchase is documented.
3. Burn rate is decoupled from feature value. Credits are "based on how much work the system has to do, not on how small the change looks". A small change can cost more than a large feature, depending on how much of the app the agent touches.
4. Credits are a workspace pool. Every member and every app in the workspace draws from the same balance, so one runaway app or one teammate's regression loop spends everyone's allowance.

Rule 3 is the source of most surprise costs. The instinct is "small change = small cost." The reality is "small change = small cost only if the agent's response is small," which is not the default.

Message credits vs integration credits: what each one pays for

Message credits pay for building; integration credits pay for running. Base44's docs define message credits as the ones used "when you interact with Base44's AI while building apps", and integration credits as the ones used "whenever your app uses Base44's built-in services, such as sending an email, generating an image, running an LLM call, or using in-app agents". Base44's own explanation for the split: "Message credits cover your building process, while integration credits cover your app's live operations."

The two are separate allowances on the same monthly clock. Every published plan sets both, read from base44.com/pricing on 23 September 2026:

Plan	Price per month (monthly / annual billing)	Message credits / mo	Integration credits / mo
Free	$0	25 (up to 5 a day)	100
Starter	$20 / $16	100	2,000
Builder	$50 / $40	250	10,000
Pro	$100 / $80	500	20,000
Elite	$200 / $160	1,200	50,000
Enterprise	Custom	Custom	Custom

Which one runs out first

While an app is being built, usually message credits, because every agent iteration draws on them. Integration credits run out on a different trigger, traffic, and the failure is worse because it breaks the live app rather than the editor. Base44's docs say that when integration credits are gone, any action that needs them fails, and your app's users "receive a generic error message without any reference to integration credits". Running out of message credits only stops you prompting; the app keeps serving.

If the message allowance is the one that keeps emptying on small edits, why minor changes drain Base44 credits walks through the workflow fixes.

What each action costs, per Base44's own docs (read 23 Sep 2026)

Base44 now publishes rough per-action figures on its Credits documentation page. They are estimates. The docs say credits "are calculated after the action runs, so your actual cost may differ", that there is "no way to preview an integration credit cost before running an action", and that "how an action is billed can differ between workspaces". Treat them as the vendor's baseline, and treat the Credits Used figure on your own prompts as the truth.

Message credits (building):

Scope of change	Base44's description	Typical credits
Simple visual or text change	A lightweight update to a single element or short piece of text	~0.5
Improving a small feature	Adjusting logic across a few files	~1
Adding a complex module	Entities, flows and logic across multiple files	~2
Large-scale or app-wide change	Touching many pages, components or the full app structure	~3–4
Discuss-mode message	Brainstorming or asking questions without changing the app	~0.3

Manual edits in the editor (dragging elements, changing layouts, editing text directly) use no credits. On paid plans, automatic AI fixes are free; on the Free plan they draw message credits.

Integration credits (your running app):

Action	Typical credits
SendEmail	~1 per email (~2 from a custom domain)
SendPushNotification	~1 per notification
UploadFile / ExtractDataFromUploadedFile	~1 per call
GenerateImage	~1 per image
GenerateVideo	~5 per second of video
GenerateSpeech	~1 per 50 characters (up to ~100 per call)
invokeLLM, Automatic model	~1 per call
invokeLLM, Gemini 3 Flash	~5 per call
invokeLLM, GPT-5.4	~15 per call
In-app agent message, Automatic model	from ~3 per message
Workflow steps	~1 per 10 steps, plus whatever each step calls
Backend function	~1 per 100 invocations, plus whatever the function calls
Database reads and writes	0
External service called with your own API key	0

Two lines in that table matter more than the rest. The model you pick for an LLM call moves it from about 1 credit to about 15, and the database is free, so the expensive part of a backend function is never the data it reads, only the services it calls.

Where the burn actually comes from

In the apps we audit, burn comes from four sources:

Source	Typical pattern
Agent prompts	Each turn regenerates large regions
Managed integrations	invokeLLM, generateImage, sendEmail
Discuss-mode turns	Planning messages at ~0.3 each
Backend functions and workflows	Invocations plus the integrations they call

Because message and integration credits are separate allowances, read those sources as where the work goes rather than as one pool: a team can empty its message credits mid-cycle while much of its integration allowance expires unused.

Backend functions and workflows stay a small line until you run nightly batch jobs or external-API-heavy workflows. If you want a deeper diagnosis of why Base44 is burning through your credits, we walk through the specific signals to look for.

The credit-burn anatomy of a single change

Walk through a realistic example. You want to add a logout button to the header.

Naive prompt: "Add a logout button to the header."

What happens:

1. Agent reads the entire Header.tsx file (200 lines).
2. Agent considers the surrounding components for context (3–5 files).
3. Agent regenerates the full Header.tsx with the logout button added and minor "improvements" the model decided to make.
4. Agent submits the diff for review.

Credit cost: somewhere in the docs' range for work that spreads across files: about 1 credit for "adjusting logic across a few files", up to about 3–4 once it touches many components. Where you land depends on how far the agent wanders.

What's wasted:

• The 195 lines of Header.tsx that didn't need to change were re-emitted.
• The "improvements" the agent made elsewhere may be regressions you'll need to fix in subsequent turns.
• The follow-up prompts to undo those improvements, each billed as a new message.

Tighter prompt: "In components/Header.tsx, between the user menu and notification bell (around line 45), add a logout button that calls base44.auth.logout() then redirects to /. Do not modify any other line of this file. Do not modify any other file."

What happens:

1. Agent reads Header.tsx.
2. Agent generates a small diff (5–10 lines).
3. Submits for review.

Credit cost: about 0.5–1 credit, the docs' figures for a single-element change and a small feature.

For UI tweaks, Base44's docs add one more lever: select the element in Edit mode before you describe the change, "so the AI does not need to scan your entire layout".

Nothing here is exotic: the difference comes from how much of the app the agent touches, and the same prompt structure applies to every change.

The regression-loop credit trap

The regression loop spends credits on turns that never produce a stable change. It is covered in detail in the AI agent regression loop fix.

The pattern: agent introduces a regression on prompt N. You ask it to fix on prompt N+1. The fix introduces a different regression. Three turns later, the original change is still not stable, and every one of those turns was billed as a new message at whatever scope it touched.

On paid plans, the loop's cost is the manual prompts, not the automatic ones. Base44's docs say that "on paid plans, automatic AI fixes are free and do not use credits" (on Free they draw message credits). The docs' own advice matches ours: try the automatic fix once or twice, and if the problem is not resolved, stop repeating it, switch to Discuss mode, explain what is not working, and work out the fix there before applying it.

When a single-link change turns into a multi-turn repair loop, it costs far more than the docs' ~0.5 for a simple change. That gap is this pattern.

The fix is structural, not tactical: scope every prompt narrowly, snapshot before every turn, and revert immediately rather than asking the agent to re-fix. We have a complete playbook in the linked fix article.

Caching integration calls

The per-call figures are in the docs table above. What turns them into a problem is volume: an app that calls invokeLLM on every page load, with no caching, spends an integration credit on every uncached view on the Automatic model, and about 15 on GPT-5.4.

The fix: cache aggressively. For deterministic prompts (same inputs produce the same output), store the result in an entity:

async function getCachedOrFresh(promptHash: string, prompt: string) {
  const cached = await base44.entities.LLMCache.list(
    { hash: promptHash },
    null,
    1
  );
  if (cached.length > 0) return cached[0].response;

  const response = await base44.integrations.Core.InvokeLLM({ prompt });
  await base44.entities.LLMCache.create({
    hash: promptHash,
    response: response,
    created_date: new Date().toISOString(),
  });
  return response;
}

The cache lookup itself is free: database reads and writes use no integration credits. Hit rate depends on how often the same inputs repeat in your app. Every hit is an integration call you do not pay for, so a 70% hit rate, for example, cuts that call's integration credit cost by 70%.

Discuss mode: plan cheaply, then build

Discuss mode is the mode you choose to brainstorm, ask questions or refine an idea "without changing your app". Base44's docs put each Discuss message at about 0.3 message credits, less than the ~0.5 of the simplest Build change, and recommend it as the place to explore before switching to Build.

When Discuss helps: anything where you are not yet sure what the change should be. Working out the approach in Discuss and then sending one scoped Build prompt costs less than three half-formed Build prompts that each change the app.

When to skip it: a change you already know exactly. Send the scoped Build prompt, or make the edit by hand in the editor, which costs nothing.

The pattern that helps: plan in Discuss, apply in Build, and never use Build mode to think out loud.

Backend function execution credits

Backend functions (available on the Builder plan and above) cost less than their reputation. Base44's docs put the invocation itself at about 1 integration credit per 100 invocations, and "reading and writing data to your app's database does not use integration credits". A backfill that pages through 100,000 records with list() calls spends nothing on the reads themselves.

What costs credits is what the function calls. An LLM call, an email or a file upload from inside a function is billed at that service's rate, per record if you call it per record. A nightly job that runs invokeLLM over every new row is an integration-credit line to size before you ship it.

The fix: count the integration calls per run, not the records. For one-time migrations, factor those calls into your migration plan. For recurring batch jobs, cache results and skip rows whose output has not changed.

How to measure your real burn rate

Start with what Base44 shows you. Each prompt's Credits Used figure sits under the More actions icon; Settings → Credit usage splits both credit types by app and charts daily usage; and each app's usage page breaks integration credits down By source (workflows, AI, tools), with a ranked list under Show details.

Those views cover the current billing cycle. To keep history across cycles, log it yourself:

// backend/functions/recordCreditUsage.ts
export default async function handler(req: Request) {
  const { operation, beforeBalance, afterBalance, metadata } = await req.json();

  await base44.entities.CreditLog.create({
    operation,
    cost: beforeBalance - afterBalance,
    metadata,
    user_id: metadata.user_id,
    timestamp: new Date().toISOString(),
  });

  return new Response(JSON.stringify({ ok: true }), { status: 200 });
}

Wrap each significant operation in the frontend or backend function with a before/after read of credit balance, then call recordCreditUsage. Aggregate weekly to see where the burn actually goes.

Check that breakdown for:

• Agent iteration concentrated on a small number of "hot" files.
• A single high-volume integration (often LLM-on-page-load) dominating integration credits.
• The rest spread across many small operations.

Once you know the breakdown, optimization is straightforward.

Credit-saving patterns

A focused pass through these patterns cuts avoidable burn:

1. Scope every agent prompt. Name the file, function, and lines. Forbid changes elsewhere. That keeps each turn close to the docs' single-element or small-feature figures.
2. Snapshot before every agent turn. Revert cheaply if the turn fails. No more re-fix loops.
3. Cache integration calls in entities. Every cache hit skips an integration call.
4. Use the code editor directly for small fixes. Manual edits use no credits. The agent isn't always the right tool.
5. Move stable code to backend functions. The agent rewrites stable code less often when it's behind an HTTP boundary.
6. Plan in Discuss mode, apply in Build. About 0.3 credits a message, and nothing changes until you switch.
7. Audit hot files monthly. The files you edit most often are where burn concentrates. Refactor or freeze them.
8. Set per-user rate limits on AI-triggering endpoints. Prevents abuse and runaway loops.
9. Track burn rate as a metric. Alert if today exceeds 2x the trailing 14-day average.
10. Plan for tier upgrades, don't fight them. If you genuinely need more credits than your tier allows, the upgrade is cheaper than perpetual mid-cycle scrambling.

Common credit mistakes

Treating credits as unlimited until the end of the cycle. Track burn weekly, not at month-end.

Assuming the agent is the cheapest path. For small edits, the editor is cheaper. For greenfield, the agent is cheaper.

Thinking out loud in Build mode. Every Build message can change the app and is billed at the scope it touches. Discuss is about 0.3 a message and changes nothing.

Picking a manual model by default. Base44's docs recommend leaving the builder on Automatic; choosing a model manually "is less predictable and can use more credits".

Not caching integration calls. The single highest-leverage credit fix.

Letting one regression loop eat half the cycle. Snapshot, revert, escalate to human review.

Buying upgrades reactively, not predictively. If your trailing 14-day burn says you'll exceed the tier, upgrade preemptively at the start of the next cycle.

When to stop optimizing and just upgrade

Optimization has diminishing returns. After a focused pass, your burn rate is mostly necessary work, not waste. At that point:

• Calculate the marginal cost of one more tier of credits vs. the engineering hours you'd spend further optimizing. The Base44 monthly cost calculator prices each plan against your edit pace and integrations.
• If the upgrade costs less than 5–10 hours of Base44 engineering time per cycle, upgrade.
• If you're consistently at 90%+ utilization on a higher tier, you've sized correctly.

Don't optimize for status. Optimize for total cost (cash + engineering opportunity cost). Sometimes the right answer is to pay more.

Credit summary checklist

Pattern	Effort	What it reduces
Narrow-scope prompts	Behavioral	Billed scope of each turn
Snapshot before turns	Behavioral	Regression-loop re-prompts
Cache integrations	2–4 hours	Repeat integration calls
Use editor for small fixes	Behavioral	Credits on routine edits (manual edits use none)
Stable code in backend functions	4–8 hours	Agent rewrites of hot files
Plan in Discuss, apply in Build	Behavioral	Fewer repair prompts
Per-user rate limits	2–4 hours	Prevents runaway burns
Burn-rate alerting	2–4 hours	Detects regressions early

Want us to optimize your credit burn?

Our $497 audit instruments your credit usage, identifies the top 3–5 burn sources, and produces a prioritized fix list. Order an audit or book a free 15-minute call.

Related reading

• Base44 Pricing Real Costs Analysis — the broader cost picture, of which credits are one line.
• AI Agent Regression Loop — how the fix-then-regress cycle drains credits, and how to break it.
• Base44 Performance Optimization Guide — performance and credit optimization overlap heavily on the integration-caching dimension.