Your AI spends money before your customer does.

tack reverses the order. Prepaid wallets, a turn that refuses when the balance is empty, and one number per customer you can invoice on. Agencies run it one project per client. You write the tools and the screens. Even when your clients hold their own keys — someone still has to meter, cap and prove it per user.

two API calls to a live tenant

For teams that have to charge early.

In production atsynoveoAI-native SaaS for lodging: every property is a tenantminuitagency: AI builds for clients, one project per client

AI broke billing in arrears.

Every answer costs real money the instant it is generated — before anyone has paid for it, and with no invoice to hide behind. Five beliefs follow from that. Everything below them is what they forced.

The beliefWhat it forcedWhat it buys you
Never spend money you haven't collectedPrepaid wallet checked before the turn, not after; refusals cost 0 and write their audit rowYou stop financing your customers' usage out of your own cash, and a runaway loop can't hand you a bill you can't pay
A turn is the unit, not a token countOne metered turn per exchange, rolled up per tenant, priced per classOne number per customer you can put on an invoice — the spread is your margin
Proof beats assuranceUsage row and wallet debit committed in one transaction; every turn reconstructible from its span treeYou end a billing dispute with a record instead of an apology
A customer is a boundary, not a columnorg → project → tenant from migration 0001 — every row, cache key, queue job and traceYour client never appears inside another client's data, and you can demonstrate it in their security review
Access is earned, never assumedClearance computed in the engine, failing closed, before context is injectedYour AI cannot be talked into revealing what the person talking to it hadn't earned

We didn’t choose these. We hit all five in production, in this order, before tack existed.

When a customer disputes a bill, show them the turn.

A ship’s log is the record that holds up afterwards. tack keeps one for your AI: every turn writes both books, usage and money, committed in one transaction. Both or neither.

usage_ledger ⇄ wallet_ledgerorg_01J9 / project-prod / ten_04QFbalance 3,418.00 u
09:41:02.114reserveturn_01JCM8QK · standardhold 1.00
09:41:02.371llm.turn2,305 tok · frontier
09:41:03.008tool.callcheck_slots · 212ms · ok
09:41:04.101tool.gatebook_appointmentpending_confirmation
09:41:05.913confirmPOST /turns/:id/confirm
09:41:06.442usage.committurn_01JCM8QK1.00⎤ txn 4189
09:41:06.442wallet.debitorg_01J9−1.00⎦ txn 4189
09:41:06.501reply.send"Booked. Tuesday 14:30."
09:47:11.083turn.refusedten_09ZR · wallet_gate0.00audited
entries marked ⎣ txn commit in the same database transaction: both or neither. A refused turn writes its audit row and costs 0.

Two API calls between a signup and their AI answering.

01

Create a tenant

From your own signup code. Idempotent: retries can't fork a customer.

POST /v1/tenants { "external_ref": "cus_9f2k" }
02

Submit a turn

Stream the reply over plain SSE. Tools call back into your codebase, signed.

POST /v1/turns { "tenant": "ten_04qf", "message": "Book me Tuesday" }
03

Bill in turns

Usage rolls up per tenant. Price your product per turn: the spread is your margin.

GET /v1/usage?group=tenant → invoice your customers on it

Pick your anxiety. It has a table.

Enforced in the schema and the type system, not asserted in comments.

IDGuaranteeMechanism
MTR-01A turn that can't pay never runsPrepaid wallet checked before every turn; hard cap; the usage row and the wallet debit commit in one transaction. Refusals cost 0 and are audited.
ISO-01Tenants cannot see each otherorg → project → tenant from migration 0001. Every row, Redis key, queue job and trace carries the tuple; a foreign tenant id is a 404.
CLR-01Access fails closedYour backend asserts what a user earned; tack computes min(ceiling, earned) once per turn. Unknown rung → ladder floor.
TOOL-01A broken tool degrades a turn, never kills itPer-tool timeout resolves to an error envelope; the model works around it. Repeated failure raises tool_degraded: failure is routed, not accidental.
AUD-01Every AI decision is reconstructibleSpan tree per turn, tool inputs/results, clearance verdict, cost by trace id. Cost is read from the ledger, never recomputed.

The six months you don’t spend.

Every AI SaaS rebuilds the same subsystems before it can send its first invoice. None of them are your product. They are runway burned before go-to-market.

SubsystemBuild yourself¹On tack
Metering + usage ledger4 wkincluded
Prepaid wallets, top-ups, billing reconciliation5 wkincluded
Tenant isolation: rows, caches, queues3 wkincluded
Permissions for AI: clearance, channel ceilings3 wkincluded
Tool safety: timeouts, confirmations, idempotency3 wkincluded
Audit trail + trace explorer3 wkincluded
Cost control: caps, kill switches, fair-use envelopes2 wkincluded
Runway spent before your first invoice≈ 6 monthsday one

1Typical single-engineer estimates for a production-grade version, not a demo. Your mileage varies; the total doesn’t shrink much.

Built for our own products first.

tack wasn’t built to be sold: it was extracted from a SaaS that needed all of it in production. The strongest proof it generalizes came next — an agency running client builds on it.

minuit
Agency · one engine, every client

Ships AI features for client products on one engine: a project per client, tenants per their customers, wallets keeping every client’s spend separate and capped. The client invoices on turns; the agency keeps the spread and carries no on-call for the engine.

client builds · isolated projects · one console
synoveo
AI-native SaaS · customer zero

Guest-facing and back-office AI for lodging businesses. Every property is a tenant; every reply, booking action and escalation runs as a metered turn with a full audit trail.

in production · thousands of turns/mo · the engine’s origin

You pay per turn. A turn is one exchange with your AI.

Plans make turns half price and include room for what your AI knows.

A turn where your AI…ClassPay as you goOn a plan
answers a questionLight1.5¢
does something — places an order, issues a refund, checks an IDStandard24¢12¢
works through something — analyzes documents, plans multi-step tasksHeavy$1.9095¢

Turns can see: photos, IDs and scanned documents count as normal input, at no extra charge. tack picks the class from what the turn actually did. Definitions in the docs.

Metered
$0/mo
pay-as-you-go rates
  • 1 product · 25 customers
  • 2,000 knowledge pages
  • 2,000 turns ≈ $180/mo
Join the waitlist
Launch
$249/mo
turns at half price
  • 1 product · 100 customers
  • 10,000 knowledge pages
  • 5,000 turns ≈ $700/mo all-in
Join the waitlist
Agencies and SaaS
Scale
$899/mo
turns at half price
  • 5 products · 1,000 customers
  • 100,000 knowledge pages
  • 40,000 turns ≈ $6,750/mo all-in
Join the waitlist
Business
$2,999+/mo
turns at half price
  • Unlimited products, customers
  • 1,000,000 knowledge pages
  • security pack · committed packages
Talk to us

Product: one thing you ship, with its own keys, tools, knowledge and clearance. Customer: one tenant inside it, isolated, with its own usage line. Extra products are $99 each per month.

Knowledge block+10,000 pages — $19/mo

A page ≈ 500 words. Processing is included, and searches sit inside the turn price. Delete content and you get the room back. Self-host is available: annual, your keys, a real number on the first call.

PrepaidBalance empty and the turn refuses, free. You are alerted before it happens.
One priceThe same turn price on every plan. Founding rates locked 12 months.
ShownEvery turn shows its class and why it was charged that way. No surprise invoices.
Knowledge fullUploads pause and you are told. Nothing bills without you.

Metered has no monthly fee: zero fixed cost until a plan pays for itself. Nothing is invoiced in arrears. The price buys the run itself: the wallet gate, clearance, guards, tool contracts, and the audited ledger row each turn commits with. A fair-use envelope bounds each class. After the founding year, any class change gets 30 days’ notice, and balances you have already bought are honoured at the price you bought them. No free tier, 14-day money-back. tack never spends money it hasn’t collected.

The questions serious buyers ask.

Which models run my turns?
Frontier reasoning and embedding models on managed keys. You configure a classper function (light / standard / heavy), never a provider. Model routing is tack’s job; your prices don’t move when providers reprice.
Can I bring my own API key?
Not on the hosted plans. Managed keys are how the hard caps, margin and audit trail stay true: a key outside the meter would make every guarantee optional. If your own contracts require your keys — an existing provider commitment, negotiated data terms, a residency obligation, or a continuity plan your client’s contract demands — that is what Self-host is for: annual licence, your keys permitted, an engine identical to the hosted one. It has a real number, and you get it on the first call.
My clients use their own API keys — I never front the money. Why would I need tack?
Then you’ve moved the problem, not solved it. Nobody caps anything: when the agent runs away, your client gets the surprise bill and you get the Monday call. They receive a provider invoice in tokens they can’t read, and you can’t tell them which feature or which week cost what. tack gives you what the key doesn’t: a balance checked before every turn, a clean stop at zero, and a per-client, per-turn record you can defend. Who pays the provider is a detail. Who controls the spend is the product.
What happens when a wallet runs out?
Turns refuse at the gate: cost 0, audit row written, a typed refusal envelope to your app, webhook fired at the threshold before it happens. Optional auto-reload tops up from Stripe. Nothing silently serves unbilled.
Anthropic workspaces already have spend limits. Why tack?
Workspace limits bound your monthly spend, per workspace, set by hand in a console with no API to provision them. They don’t reach your end users: your client’s two hundred users share one ceiling, one of them can eat everyone else’s, and when it trips they all stop at once. And a limit is not a balance — it caps what you spend, it doesn’t collect from anyone first. tack does both: prepaid per end user, checked before every turn, with the per-turn record you invoice on.
Am I locked in?
Your tools live in your codebase; the interface is plain HTTPS + SSE. Transcripts, knowledge and usage export via API. If you leave, you take your data and your business logic — what stays is the engine you no longer need.
Is tack an orchestrator? I already use LangGraph / Temporal / my own workflow engine.
Inside a turn, yes — tack runs the whole loop: model calls, tool dispatch, guards, retrieval, confirmation gates. That’s exactly why it can bound, meter and bill it. Above the turn, no: your graph, your workflow engine, your multi-agent logic stay yours. Each step they trigger is a turn tack runs, gates and records. tack sits under your orchestrator, not in its place.
Are you SOC 2 or ISO 27001 certified?
Not yet — tack is pre-launch, and a certification claim we can’t evidence would be worth less than a straight answer. What exists today is the guarantee table and threat model above, an append-only audit trail per turn, tenant isolation enforced in code rather than convention, and a DPA plus sub-processor list on request. If your procurement needs a certification date, ask when you join the waitlist and you’ll get the real one, not a marketing one.
What do I hand my client’s security review?
The security pack: the full threat model mapped to MITRE ATLAS, the DPA, the versioned sub-processor list, and the disclosure policy. Every turn already carries a reconstructible audit trail, so “show me what the AI did” has a literal answer. Pick blocked by a security review in the waitlist form and the pack goes out by reply — before any call, before any signature.
Where does inference actually run, and who are the sub-processors?
Model routing is tack’s job, but which providers process your customers’ data is yoursto disclose downstream — so it’s published, versioned, and never changed silently. You get the current sub-processor list, the regions inference runs in, and advance notice before a class is re-routed, so your own DPA stays accurate.
Where does my customers’ data live?
Isolated per tenant, retention windows you configure, erasure cascade on tenant deletion (money rows anonymize: financial records survive, attribution doesn’t). You are the controller, tack is the processor; DPA available.
What does tack add to latency?
Turns are model-dominated: measured production p50 ≈ 4.5s is the model call itself. Engine overhead (queue, gates, ledger) is 2–10% of the turn. Tool callbacks add your endpoint’s latency, bounded by per-tool timeouts.
What if tack is down?
Turn submission is durable: queued work survives restarts; results deliver at-least-once via signed webhooks with idempotent event ids. Status page + incident history public from day one, reported per turn class — “tack is up” and “the heavy class is servable” are different facts, and only the second one matters to you. Turn submission and delivery are redundant by design; no single engine failure loses a queued turn or double-charges a delivered one.
Why is there no free tier?
Because a free tier optimizes the engine for tenants who will never pay. But there is no barrier either: Metered has no monthly fee, so you pay only on turns you are already billing your own customers for. You pay — just never before you have collected. That is the whole product in one sentence, and it would be strange to contradict it at the door. 14-day money-back on the plans.

Set your course. The books keep themselves.

Create a tenant. Submit a turn. Everything else was already running.

Pre-launch. The prices on the home page are the real prices; keys go out to the waitlist first. Blocked by a security review? Say so: the threat model, DPA and sub-processor list go out by reply. We only use your email to notify you — see the privacy policy.