Purchase & billing

How to upgrade an organization to a paid Basic or Pro plan, manage the subscription, read your receipts, and recover from a failed payment. For the full price table see /pricing; that page is canonical.

Plans at a glance

• All prices in USD. Stripe Tax adds JCT (10%) for Japan-resident customers.
• 1 DL token = ceil(model.size / 500MB).
• Free test/public token allowances reset at the start of each calendar month (UTC).
• mk_live_* (production) and mk_svc_* (agent / CI) keys require a paid plan — issuing one on the Free tier returns HTTP 402.

Upgrading to Basic or Pro

From the dashboard

1. Open /dash/<slug>/billing and sign in.
2. Select Basic or Pro and a monthly or yearly billing interval.
3. Click Continue to Stripe Checkout (shown while your org is on the Free tier).
4. You are redirected to a Stripe Checkout session and pay there. Promotion codes are accepted.
5. On success you are redirected back to the dashboard. The checkout.session.completed webhook switches your org to paid immediately — no manual review.

The Upgrade button calls this endpoint (session-authenticated) and redirects to the returned URL:

POST /v1/orgs/<slug>/billing/checkout
{ "plan": "basic" | "pro", "interval": "month" | "year" }
→ { "url": "https://checkout.stripe.com/...", "sessionId": "cs_..." }

From the CLI

manashiki billing upgrade [--org <slug>]   # opens Stripe Checkout in your browser
manashiki billing status  [--org <slug>]   # verify the tier after paying

If you omit --org, the CLI uses the org selected with manashiki orgs select <slug>. After paying, your keys immediately work for production. The current CLI upgrade command starts a Basic monthly checkout; use the dashboard to choose Pro or yearly billing.

Upgrading unlocks mk_live_* and mk_svc_* key issuance and meters test/public/live token overage. Contact support if you need help onboarding an org-private model.

Managing your subscription

Payment methods, invoice history, and cancellation are handled in the Stripe customer portal. From /dash/<slug>/billing, click Manage subscription (shown once you are on a paid tier), or use the CLI:

manashiki billing portal [--org <slug>]    # opens the Stripe Customer Portal

Both call:

POST /v1/orgs/<slug>/billing/portal
→ { "url": "https://billing.stripe.com/..." }

In the portal you can update your card, view and download past invoices, and cancel. If your org has never checked out, the portal call returns HTTP 409 no_customer — run the upgrade flow first.

Receipts & invoices

Refunds: the initial base fee is fully refundable within 7 days of signup if your org has fewer than 100 cumulative live tokens. Usage charges (metered tokens) are not refundable. See the 特定商取引法に基づく表記 for the full policy.

If a payment fails

1. Your org's tier changes to past_due and you receive the payment-failed email. While Stripe reports the subscription as past_due, existing mk_live_* / mk_svc_* keys keep working, downloads continue uninterrupted, and new keys can still be issued. The duration is controlled by the Stripe retry and dunning configuration rather than a fixed application timer.
2. If the subscription is not brought current and Stripe marks it unpaid or canceled, the tier becomes canceled: issuing new mk_live_* / mk_svc_* keys is blocked, custom-model eligibility is withdrawn, and free test/public token allowances apply again.
3. Your keys are not deleted, and the org's Stripe customer and subscription IDs are kept, so reactivating restores full access without re-creating anything.

Restoring service

1. Open the customer portal (Manage subscription or manashiki billing portal).
2. Pay the open invoice or update your payment method.
3. When Stripe confirms payment (invoice.paid), the webhook automatically returns your tier to paid — no support ticket needed. If the subscription was fully canceled, run the upgrade flow again instead.
4. Verify with manashiki billing status or the billing status endpoint below.

Checking your entitlements

GET /v1/orgs/<slug>/billing/status
→ {
  "tier": "paid",
  "currentPeriodEnd": "2026-07-01T00:00:00.000Z",
  "stagingQuotaUsed": 4,
  "stagingQuotaLimit": null,
  "testTokensThisPeriod": 3,
  "testTokenFree": 100,
  "publicTokensThisPeriod": 0,
  "publicTokenFree": 1000,
  "liveTokensThisPeriod": 312,
  "liveDownloadsThisPeriod": 312,
  "customModelAllowed": true,
  "liveKeyIssuanceAllowed": true,
  "serviceKeyIssuanceAllowed": true,
  "downloadGuardrails": { ... },
  "supportContactMailto": "mailto:..."
}

Tier values:

A token allowance, stagingQuotaLimit, or guardrail limit of null means unlimited. After fixing a payment, re-check this endpoint (or click Refresh on the billing page) — the tier flips back as soon as the webhook lands.

Download guardrails

Downloads pass through a set of guardrails. Their live state is shown on /dash/<slug>/billing and in the downloadGuardrails object of the status endpoint.

Test/public token allowances (Free tier)

Free orgs get 100 test tokens and 1,000 public tokens per month. One download costs ceil(model.size / 500MB) tokens. Requests over the allowance return HTTP 402 payment_required with reason: "test_token_quota_exceeded" or reason: "public_token_quota_exceeded", your current usage, and a checkout URL. Upgrading meters overage instead of blocking.

Live download cap (auto-stop)

Paid orgs can have a per-period cap on billable live downloads (unlimited by default). Auto-stop is armed by default: when usage reaches the cap, live downloads are suspended and further requests return HTTP 402 with reason: "live_download_cap_reached", including used, limit, remaining, and the support contact. The suspension clears automatically when the next billing period starts and usage resets. The status endpoint also reports a live cap warning state at 50%, 80%, and 100% so the dashboard can surface risk before auto-stop triggers.

Per-key live cap

Operators can set an optional monthly live download cap on individual live or service keys. When a key reaches its cap, the download route returns HTTP 402 with reason: "live_key_download_cap_reached" even if the organization-level cap still has remaining capacity. Self-service key creation accepts liveDownloadLimit, and the CLI exposes it as --live-download-limit for production and svc keys.

Concurrent download limit

Each org may hold at most 25 concurrently active signed download URLs by default. Exceeding it returns HTTP 429 with reason: "concurrent_download_limit_reached". Slots free up when your client releases its lease after finishing, using the requestId returned by the download response (DELETE /api/download/lease/:requestId) or automatically after the 10-minute lease backstop. A separate per-key download rate limit also returns HTTP 429 when exceeded.

Service-wide suspension

During an incident, operators can engage a global kill switch; all downloads then return HTTP 503 downloads_suspended. Its state appears as killSwitch.enabled in the billing status.

Cap, concurrency, suspension, and kill-switch errors include a support contact in their details (free-token 402 responses carry a checkout URL instead). If a limit blocks you, write to contact@utakata-scifi.com.