Billing & Earnings — overview

This section is for extension developers publishing on the Imperal Marketplace. It covers how users pay, how your extension earns, and how you get paid out.

Not building extensions? This section is for marketplace publishers. If you're a regular Imperal Cloud user looking at your own bill, log into the Panel → Billing tab.

Credits are Imperal's usage currency. In the SDK/API the field is named tokens — 1 credit = 1 token.

The three things users pay for

Imperal users pay along three independent surfaces:

┌──────────────────────────────────────────────────────────────┐
│ Tier 1: Platform subscription                                │
│   Flat monthly/annual fee for Panel access.                  │
│   Charged via Stripe recurring (auto-renew).                 │
├──────────────────────────────────────────────────────────────┤
│ Tier 2: Credit wallet (pay-as-you-go)                        │
│   Replenishable credit balance — top up via Stripe one-shot. │
│   Credits get consumed on every action call.                 │
├──────────────────────────────────────────────────────────────┤
│ Tier 3: Extension rental (planned — not yet enforced)        │
│   Optional monthly credit subscription per paid extension.   │
└──────────────────────────────────────────────────────────────┘

As a developer, you earn from Tier 2 — every time a user invokes one of your extension's @chat.function handlers, credits flow from their wallet, and a percentage accrues to your developer balance. Your developer tier controls the split, app cap, payout access, analytics window, and rate limit:

Default for new developers is explorer. Tier subscriptions auto-renew once a year; lapse drops you back to explorer (existing earnings stay in your balance). See Developer Tiers for break-even math, upgrade flow, and tier-lock semantics on existing apps.

What your extension can charge for

Every @chat.function in your extension has an action_type (read / write / destructive). When a user invokes it:

1. The platform resolves the credit cost from your pricing config.
2. Cost = base_price (from your pricing) + platform_fee (covers the platform's LLM cost; zero for BYOLLM users — see BYOLLM Pricing).
3. Credits are deducted atomically from the user's wallet.
4. The charge is recorded to your developer earnings.

You see the result in Dev Portal → My App → Earnings.

What you DON'T charge for

These flows bypass your earnings — they're either platform-side or run by the platform itself:

• Skeleton refreshes (@ext.skeleton decorator) — free; the platform runs them in the background, never billed.
• Panel renders (@ext.panel handlers) — free, also background-driven.
• Conversational turns — when a user chats without invoking a tool, the platform charges its own system meter (not your extension). For BYOLLM users this is zero.
• Cancelled / refunded actions — the user is automatically refunded; your earnings row is reversed.

Quick reference

Lifecycle of pricing edits

App status:  draft  →  pending_review  →  active
             ─────     ───────────────     ──────
Pricing:     editable  locked (review)    locked (must `Pause` to edit)

To change prices on an active app: Pause in Dev Portal → edit → Resubmit for Review → admin re-approves. Prices take effect once approved.

Real-time observability

In Dev Portal → Earnings:

• Total Earned — your developer share summed across all earning events
• Pending Payout — earned minus what's already paid or approved
• Paid Out — your approved and paid payouts

Updates within seconds of each user call (consumer-driven).

Billing guarantees

The platform enforces these guarantees on the billing path, so you can rely on them:

See BYOLLM Pricing for the developer-facing impact of the BYOLLM guarantee.