Below is the plans table, not a marketing approximation of it. Every figure is a column the gateway re-reads on each gated action. Self-hosting Verity costs nothing and is limited by the hardware you point it at; hosted pricing is not announced yet, and inventing a number here would be the first dishonest thing on this site.
| Metric | Free | Procommon | Max |
|---|---|---|---|
| Messagesper day | 50 | 2,000 | unlimited |
| Tokensper day | 100,000 | 5,000,000 | unlimited |
| Flowsper day | 5 | 200 | unlimited |
| Office runsper day | 2 | 100 | unlimited |
| Uploadsper day | 10 | 500 | unlimited |
| SpiderMesh creditsper day | 100 | 10,000 | unlimited |
| House model callsper day, on models Verity provides | 20 | 1,000 | 5,000 |
| Standing officesconcurrent | 1 | 20 | 100 |
| Priority routingfeature flag | no | yes | yes |
A gated action is decided from two things: the subject on the verified token, and the entitlement row that subject owns. The gateway resolves one, looks the other up in the database, and answers from those.
Plan, quota and usage all come from the database on each gated action, so what you are allowed to do is the same on any client you sign in from.
Every metered action writes a row with an idempotency key that is unique across the whole table.
A retried or replayed request lands on the same key and is absorbed, so a flaky network cannot double-charge you or double-grant you.
Reads treat an absent row as the free plan, and the first metered action creates one. There is no state where a user falls through the checks into unlimited access.
BoundSome limits in Verity are still compile-time constants rather than plan columns: the tool-iteration ceiling, and the worker counts for flows and research. They are deliberate defaults, but they are not yet entitlement-scoped, so they do not appear in the table above.
Fifty messages a day, five flows, two office runs and a hundred SpiderMesh credits, on your own model keys, with the same security model as every other tier.