Skip to content
AskVault Docs
Try Free →

Why MB-cap, not query-cap or seat-cap

Written by , Founder, AskVault · Reviewed by Aashiq
Last updated: · 4 min read

The three common billing axes

Competitors typically bill on:

  1. Queries per month. Per-message metering.
  2. Per seat. Per team member.
  3. Per content MB. Per indexed knowledge.

Most platforms combine 2 or 3 of these. We pick one: content MB.

Why not per-query

Per-query billing punishes engagement. The more your customers engage with your bot, the more you pay. This:

  • Discourages bot improvement. Less effective bots cost less.
  • Penalizes growth. As your customer base grows, costs spike unpredictably.
  • Creates anxiety. Customers ration bot usage to control bill.

Why not per-seat

Per-seat billing punishes team growth. Adding a team member costs more even if they barely use AskVault. This:

  • Limits team visibility. Managers don't add observers due to cost.
  • Penalizes shared inboxes. Multi-agent teams pay more for the same workload.
  • Distorts hiring. "Can we afford to give Alice access?" is the wrong question.

Why MB-cap

Indexed content is:

  • Predictable. You know exactly how much content you have.
  • Stable. Doesn't fluctuate with customer behavior.
  • Aligned with value. More content = more bot intelligence = more value to you.
  • Easy to optimize. Delete what's not used; index what is.

When you hit the cap, you know exactly why. Upgrading the plan addresses the root cause directly.

What about query throughput

We do have per-plan query caps as a fairness mechanism, not a billing axis:

  • 100 queries/mo on Free (anti-abuse).
  • 3,000 on Starter, 15,000 on Growth, 50,000 on Business.

These scale with plan tier. You almost never hit query cap before MB cap.

What we tried and reverted

Earlier versions had dual-axis billing. We learned:

  • Customers confused. "Why am I blocked? I have storage left."
  • Trust broke. Surprise charges erode goodwill.
  • Support cost spiked from billing confusion.

We reverted to single-axis. Trust improved measurably.

Comparison

ApproachPredictabilityValue alignmentCustomer friction
Per-queryLowLowHigh
Per-seatMediumLowHigh
Per-MB (us)HighHighLow
Multi-axisLowMediumVery high

The MB calculation

What counts toward MB:

  • Crawled URL text. Body content, not HTML overhead.
  • Uploaded files. Extracted text.
  • Snippets and Q&A pairs.
  • Integration-sourced content (Notion, GitHub, etc.).

What doesn't:

  • Conversation history. Stored separately.
  • Audit logs.
  • Customer profiles.

About 5 MB typically covers 50 to 100 pages of content.

Plan tier breakdown

  • Free. 5 MB.
  • Starter. 15 MB.
  • Growth. 40 MB.
  • Business. 100 MB.
  • Enterprise. Unlimited.

When you hit the cap, expand or upgrade.

Common pitfalls

Treating MB cap as content quality. It's storage, not quality. Audit and trim.

Indexing low-value content burns MB. Be selective.

Assuming query cap matters. For most teams it doesn't bind first.

FAQ

What if my content compresses well?

We use the post-extracted text size, not raw HTML. Compression doesn't change effective MB.

Can I see exactly what's consuming my MB?

Yes under Knowledge Hub > Storage Usage > By Source.

Will you change billing again?

No plans to. Single-axis is stable.

Was this page helpful?