Billing and plans

Overview

During the Beta, Gitmoap is free of charge and takes no payment: every organisation is on the Free plan, and the checkout, billing portal and invoices described on this page are switched off. They are described so the page is ready when paid plans exist.

Every organisation on Gitmoap runs on a plan, and the plan decides how much you can store, how many repositories you keep, and how much pipeline compute you get each month. You can read the plan you are on, move to a paid one through Stripe Checkout, change the card or cancel from Stripe's billing portal, and list the invoices recorded for your organisation. When a single limit is the only thing in your way, ask for that limit to be raised rather than buying a bigger plan — limits are soft, and a raise is one request against one number.

Before you start

How it works

Two systems share the work, and the line between them explains almost every surprise on this page.

Stripe holds the money. The card, the charge, proration, tax, dunning, refunds and the invoice document itself all live at Stripe. Gitmoap computes no amount and stores no card.

Gitmoap holds the entitlement — which plan your organisation is on, and therefore every limit enforced when you push, create or run something. That plan changes because Stripe told us the subscription moved, never because Gitmoap decided.

The subscription's status is what grants the plan:

Upgrades apply at once. Downgrades apply at the end of the period you paid for. Stripe schedules the lower price for the next renewal and reports it then, so you keep what you bought until the date you bought it through.

A drop in plan never deletes anything. If your storage sits above the new plan's limit, the repositories keep every byte; what is refused is new growth, with 429 TOO_MANY_REQUESTS, until you are back under the number.

Limits are soft, ceilings are hard. A plan's number is a starting point. One limit can be raised for one organisation without changing plan, and every raise stops at an absolute ceiling:

An approved limit increase writes the override. It touches neither your plan nor your card, and it applies to the very next check — there is nothing to redeploy or restart.

How to

See which plan you are on

A namespace that has never subscribed reads back as Free and active, so this call always answers; there is no such thing as a missing subscription. Alongside the plan you get the renewal date, whether a cancellation is already scheduled, when a trial ends, the seat count, and has_payment_method, which turns true once a subscription exists at Stripe for the organisation.

Subscribe to a paid plan

Checkout is Stripe's page, not ours: the call returns a URL and you send the browser to it. You supply the two absolute URLs Stripe returns to — one for a completed purchase, one for an abandoned one — so Checkout lands the buyer back wherever it makes sense in your own product.

seats sets the starting quantity for a per-seat plan and lets the buyer adjust it in Checkout and later in the portal. Entitlement follows the product, never the quantity — twenty seats of Team grants exactly Team. Where the plan comes with a free trial, Checkout starts the subscription in trialing and you have the full plan until it ends.

Checkout sells whichever paid plans Gitmoap publishes a price for. Ask for one it does not price and the call is refused with 400 BAD_REQUEST naming the plan; free is never among them, because it is what you fall back to rather than something you buy.

Creating a session changes nothing about your plan. The plan changes when Stripe reports the subscription, which follows the payment rather than the click that opened Checkout — and a subscription whose first charge has not cleared reads incomplete and grants Free until it does.

Change plan, update the card, or cancel

The billing portal is Stripe's too, and it is the one place to swap plan, change the card, update the billing address or cancel. Anything you do there reaches us as an event; there is nothing to tell Gitmoap afterwards.

Cancelling leaves the plan in place until the period you paid for ends — the subscription reads cancel_at_period_end as true, and current_period_end is the date it drops to Free. An organisation for which no Checkout session has ever been started has no customer at Stripe to open a portal for, and the call answers 400 BAD_REQUEST saying so. Starting one is enough — the portal opens even if nobody finished paying.

Read your invoices

Invoices arrive as Stripe issues them, newest first, twenty to a page and at most a hundred. Amounts are whole minor units of the currency named — 2000 with "usd" is twenty dollars — so no rounding can creep in. Each entry carries Stripe's own hosted view and PDF links where Stripe supplies them, because the document lives at Stripe; what we keep is the summary and the way back to it.

The list reads what has already arrived, with no call out to Stripe, so it answers quickly and it answers even while payments are unavailable — in which case it shows what had arrived before.

See your AI organization's balance

An AI organization's model calls are paid for from a balance held in dollars, before each call is made: the call's most it could cost is reserved, and when it ends what it actually cost is charged and the rest released. The balance shows what is left, how much is reserved by calls in flight, and the low-balance threshold.

During early access Gitmoap funds the balance, and there is no top-up to buy.

Read what each model call cost

The ledger holds one entry per model call, newest first: what it cost, the fee beside it, the session and turn it belonged to, and the model and token counts it was priced from. Amounts are in millionths of a dollar — 1500000 is a dollar fifty — so no rounding creeps in. A call is never charged twice, and never more than was reserved for it.

Fund a balance

The call belongs to Gitmoap's platform administrators: it credits or debits an organisation's balance with a stated reason, which the organisation's ledger of transactions keeps. It needs a platform administrator signed in to Gitmoap, and answers 403 FORBIDDEN for anyone else. At most 20 adjustments may be made to one organisation in a day.

Ask for one limit to be raised

Name the limit, the value you need and why you need it. Give the reviewer something to act on: what you are building, what stopped, and the number that would unblock it. The justification runs from 1 to 2000 characters.

Three rules decide whether the request is accepted for review. The value has to be strictly above your current effective limit, it has to sit at or below the limit's hard ceiling, and only one request per limit may be open at a time for an organisation — a second one answers 409 CONFLICT until the first is decided.

One limit is not an organisation's at all: max_root_groups is the number of top-level groups you may own. File it against any organisation you own, and an approval raises your personal budget rather than that organisation's limits. For this one limit the must-be-an-increase check is made against the standard starting budget of three rather than against a raise you already hold, so ask for a number above whichever of the two is higher. No group's usage view reports it either, because it belongs to you and not to a namespace: the only way to see where you stand is that creating one more top-level group either works or answers 429.

Track a request you filed

Requests come back newest first and you can filter by status. pending is waiting for a reviewer, denied carries the reason in its decision note, and applied is the terminal success state — approval writes the override in the same step, so a successful request never rests at approved.

Review the queue

The four calls below belong to Gitmoap's platform administrators, not to an organisation's Owner. They need a platform administrator signed in to Gitmoap, and they answer 403 FORBIDDEN for anyone else.

The queue spans every organisation and defaults to the pending ones, which is the working list. Each entry carries the limit asked for, the value, the effective limit at the moment of filing, the justification and who filed it.

Approve a request

Approval applies immediately, and it is safe to retry: the override is written before the request is marked applied, so an interruption leaves the request still pending and approving again finishes the job without granting anything twice. Approve with no value to grant exactly what was asked, or name your own value, larger or smaller than the request.

The applied value is clamped to the limit's hard ceiling, so an approval can never exceed it however it is written. A request that has already been decided answers 409 CONFLICT — decisions are final, and a second raise is a second request. An approved max_root_groups writes the filer's own budget, not the organisation's limits.

Deny a request

A denial requires a reason, and the requester reads it. Say what would change the answer — a smaller number, a different plan, a workload split across organisations — because the only route on from a denial is a fresh request.

Set an organisation's limits directly

The negotiated path: set limits for one organisation with no request in front of them. Every value is checked against the hard ceiling and refused if it is over — the direct call rejects rather than quietly clamping, so a fat-fingered number surfaces as a 400 BAD_REQUEST instead of as a silently smaller raise.

The call merges rather than replaces. Limits you name are set, limits you send as null are cleared, and limits you leave out keep whatever they had. The id in the URL has to be the top-level group; a subgroup answers 400 BAD_REQUEST.

Keep the plan in step with Stripe

Stripe reports every subscription and invoice change to a single address on Gitmoap. It is the only path by which a plan changes, and it authenticates on Stripe's signature over the exact bytes of the request rather than on a token — a body that has been altered in flight fails verification and is never processed.

We handle replays and out-of-order delivery, so Stripe's retries are safe: an event already applied changes nothing the second time, and an older event arriving after a newer one is skipped instead of undoing it. An event about a subscription Gitmoap has never seen is ignored rather than treated as an error. A delivery whose signature timestamp sits more than five minutes from the deployment's clock is refused outright, which is what a captured request replayed later looks like.

Reference

Limits

Four plans, and each raises every limit or holds it level — nothing gets smaller as you move right. The ceiling column is the absolute maximum an override reaches for that limit, whatever plan you are on and whatever value is approved. Below are the limits people meet; the full set of names a request may name is listed on the request card in Reference.

The branch and tag limits are agreed rather than counted: creating a branch or a tag past them is not refused.

Three more numbers do not come from a plan at all. Top-level groups one person may own starts at 3 and is raised by an approved request against max_root_groups, up to 1,000. Access tokens per person or service account is a flat 100, and an uploaded avatar is 5 MiB, on every plan.

Reaching a limit refuses the request; it never half-performs it. The answer is 429 TOO_MANY_REQUESTS, and nothing is created, stored or started — a repository that would have taken you past the storage limit is not left half-made. Settings → Usage shows every meter against the effective maximum enforced for you, which is the number to read before you decide whether you need a bigger plan or a single raise. That view is not Owner-gated the way billing is — Reporter on the group is enough — so the people who actually hit a limit can see where they stand without holding the card.

Two ways to get more room: move to a plan whose defaults cover you, through Checkout or the billing portal; or file a limit-increase request naming the one limit that is in your way. The second changes nothing else about what you pay.

Troubleshooting

FAQ

Related