> ## Documentation Index
> Fetch the complete documentation index at: https://docs.genieforge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Controlling credits

> How Build vs Chat spend credits, what active build time means, and how to keep costs predictable without exact quotes.

# Controlling credits

GenieForge usually includes monthly credits in your subscription for AI and related platform usage. This page is about **controlling spend**, not quoting exact prices. For current plan numbers, use [https://genieforge.ai](https://genieforge.ai), your billing settings, or [support@genieforge.ai](mailto:support@genieforge.ai).

## The rule of thumb

Credit usage reflects **work performed**, not how big a screen looks.

A small page can still be expensive if it needs heavy data processing, many integration calls, large file analysis, or lots of plan-and-rebuild loops. A large dashboard can be cheap if it reuses tools and pages you already have.

## Build vs Chat

| Mode  | Typical spend                                          | What you are paying for                                     |
| ----- | ------------------------------------------------------ | ----------------------------------------------------------- |
| Build | Higher                                                 | Planning, writing tools/pages, migrations, retries, testing |
| Chat  | Usually lower per turn when capabilities already exist | Operating the app with existing tools and agents            |

Preview clicks and ordinary page browsing are not the same as asking the AI to rebuild features.

## Active build time

On **Credit Usage**, **active build time** is how long the agent spent working on Build requests. It excludes idle gaps while you think. Long active time often means large plans, repeated failures, or broad rebuilds.

## What tends to cost more

* Broad prompts that rebuild many surfaces at once
* Redoing work that already exists instead of refining
* Large imports, scrapes, or file analysis in the main Build loop
* Fan-out of many sub-agents or long agent loops in automations
* Tight trial-and-error without reading errors from **Preview as**

## What tends to cost less

* Asking for a small, named change ("add a status column to the Clients page")
* Reusing tools, libraries, and pages
* Moving bulk work into **background tasks**
* Testing with **Preview as** before another Build turn
* Using Chat mode once the capability exists

## How to keep a build predictable

1. Approve a clear plan before heavy work.
2. Prefer incremental asks over "rebuild the whole app."
3. Put durable preferences in **Build Rules** so you do not re-argue them every chat.
4. Fix role and access issues with **Access** + **Preview as** instead of guessing in Build.
5. Watch **Credit Usage** (Build vs Chat, spend by person) for the app.

## Exact quotes are hard

The same sentence can expand into very different work depending on existing schema, integrations, and edge cases. GenieForge should not invent a fixed credit quote for a feature. Use active build time and recent rows as your signal, and ask support if you need help choosing a plan.

## Where to look

* App sidebar **Credit Usage** (admin or owner): [Credit usage in an app](/account/credit-usage)
* Account billing settings for balance and top-up
* [Billing, plans, and credits](/account/billing-plans-and-credits)