Skip to main content
By Armaan Kapoor Pathway runs agentic pipelines on behalf of organizations. A lot of the actions in those pipelines have a real dollar cost: extraction, reconciliation, identity lookups, web research, sandboxed compute. Cost scales with the complexity of the work, not the number of users or features enabled.
Pathway does not charge per seat and does not charge per feature. Every plan includes full access to everything. The only variable is usage.
We price usage through a single unit called a conversion. A conversion wraps raw action cost into a number the org can plan around. Since cost is proportional to what the pipeline actually does, an org that wants to reduce their cost per document can turn off pipeline stages they don’t need. Certain stages are auxiliary to core extraction, and they can be toggled on and off or have their strength controlled, giving the org a cost profile they manage themselves. The pricing page covers what conversions look like from the org’s side. This page covers how they’re constructed, the margin guarantees for every party in the chain, and the proofs that let any party at any layer verify that the only markup is the one they agreed to.
Bank statement settings showing toggleable pipeline features

​
What a conversion actually is

Each org has a monthly subscription price Y, a conversion limit X, and a take-profit factor TP. The org sees Y and X. TP is internal to the party setting the pricing. Every action that costs money accumulates a dollar cost during execution. When the job finishes, the total cost feeds into one function: conversions=cost×X×TPY\text{conversions} = \frac{\text{cost} \times X \times TP}{Y} That number gets written to the job record. In the codebase, this is calculate_conversions(), called at the terminal state of every parse job: 
def calculate_conversions(cost, conversions_monthly_limit,
                          subscription_amount_usd, take_profit_factor):
    quoted_price = (
        subscription_amount_usd / conversions_monthly_limit
        if conversions_monthly_limit and subscription_amount_usd > 0
        else 0.20
    )
    return cost / quoted_price * take_profit_factor
The result is stored in parse_job_meta.conversions alongside the action cost, document count, page count, and transaction count. Every completed, failed, or cancelled job writes this record. The org’s monthly usage is the sum of those floats across all jobs.
Parse history table showing per-job conversion costs
A month of bank statements from one account lands around 1 conversion. A 6-month deal package across 3 accounts: 8-12. Credit report: 1-2. Tax return: under 1. The numbers are stable because the work is proportional to document structure, and structure doesn’t shift between runs. The unit cost is competitive with dedicated bank statement and credit report parsers despite doing significantly more work per document, which is a function of how the pipeline is built. The parser white paper covers the technical details: transaction compression, parallel extraction, and reconciliation design that keeps token counts low relative to output quality. This is also how we onboard new orgs. Grant 100 conversions on a free trial. They process their first few deal packages, see real conversion costs, get a feel for the unit relative to their volume. When they’re ready to scale to full deal flow, we set Y and X to match their throughput and TP to match the economics. The conversion count ramps with them. The unit stays the same.

​
Why X doesn’t control cost

X appears in the conversion formula, but it doesn’t appear in the cost bound. The org is blocked when total conversions reach X. Setting the sum equal to X and solving for total cost: ∑iCi⋅X⋅TPY=X⇒TPY∑iCi=1⇒∑iCi=YTP\sum_{i} \frac{C_i \cdot X \cdot TP}{Y} = X \quad \Rightarrow \quad \frac{TP}{Y} \sum_{i} C_i = 1 \quad \Rightarrow \quad \sum_{i} C_i = \frac{Y}{TP} X cancels. Grant 500 or 50,000 conversions, max spend is Y/TP. At the default TP of 2.5, that’s 40% of revenue, 60% margin floor.
TPMax costMargin floor
2.050% of Y50%
2.540% of Y60%
3.033% of Y67%
X is how the org thinks about their budget. TP is how we think about ours. Raising X doesn’t grant more compute, it slices the same compute into finer units. The org sees more conversions, but each one is proportionally smaller. Total spend at cutoff is still Y/TP. Since there are no per-seat or per-feature charges, the conversion is the only thing absorbing the cost of everything we build. New pipeline stages, new integrations, new capabilities all flow through the same unit. The org’s incentive is to process more documents. Our incentive is to make processing cheaper so we can either pass savings through to the org or improve margin. Both sides grow from the same usage. X also becomes the natural gate for operational scaling. Custom integration work, dedicated account management, white-label access, SLA tiers can all be unlocked at conversion thresholds rather than priced as separate line items. The org scales into those by growing their usage, not by negotiating add-ons. Every commercial relationship reduces to three numbers.

​
Mid-cycle raises

An org maxes out halfway through the month. We raise X₀ to X₁ without changing Y. Stored conversions from completed jobs are frozen. They were computed with the old quoted price of Y/X₀. At the new limit, they take up proportionally less of the budget. Theorem. Cost ceiling after one raise: C=YTP(2−X0X1)C = \frac{Y}{TP}\left(2 - \frac{X_0}{X_1}\right) Proof. At maxout: stored conversions = X₀, cost so far = Y/TP. Remaining budget is X₁ − X₀ conversions at the new rate of X₁ · TP / Y per dollar. C1=(X1−X0)⋅YX1⋅TPC_1 = \frac{(X_1 - X_0) \cdot Y}{X_1 \cdot TP} C=YTP+C1=YTP(2−X0X1)■C = \frac{Y}{TP} + C_1 = \frac{Y}{TP}\left(2 - \frac{X_0}{X_1}\right) \quad \blacksquare Bounded between Y/TP and 2Y/TP. One raise can at most double the exposure. With TP ≥ 2, a single raise can never push cost above revenue, so there’s real room to be flexible with orgs that need more capacity mid-month. Repeated raises accumulate. k raises after maxout, successive limits X₀ < X₁ < … < Xₖ: C=YTP(1+∑j=1k(1−Xj−1Xj))<YTP(1+k)C = \frac{Y}{TP}\left(1 + \sum_{j=1}^{k}\left(1 - \frac{X_{j-1}}{X_j}\right)\right) < \frac{Y}{TP}(1 + k) Linear in k. TP = 2 and three raises: cost can reach 2Y. Each phase respects TP individually, but they stack. The safe pattern is to raise Y proportionally when repeated raises are needed.

​
Enforcement

Before any action that costs money, the system checks: 
parse_conversions = SUM(parse_job_meta->>'conversions')  # completed jobs, this month
chat_conversions  = chat_cost / quoted_price * TP         # same formula, live
total = parse_conversions + chat_conversions

if total >= conversions_monthly_limit:
    block
Adding a new paid component to the platform means calling this check before it runs and writing a conversion record when it finishes. The gate sees a sum of floats against a ceiling. It doesn’t know what kind of work produced them, which makes extending it to any new action the same few lines of code. A running job can overshoot by at most one job’s worth of conversions, which is fine. The overshoot is bounded by document size and model context limits, not the billing system. conversions_monthly_limit = NULL means unlimited. Parse conversions are frozen at completion-time parameters. Chat conversions recompute live against current TP, so changing TP mid-month reprices chat retroactively but leaves stored parse records intact.

​
Multi-tenant composition

Each org has its own Y, X, TP. A platform operator white-labels Pathway, creates sub-orgs, sets pricing per tenant: 
@orgs_router.patch("/orgs/{org_id}/subscription")
async def update_org_subscription(org_id, subscription):
    await session.execute(text("""
        UPDATE organizations
        SET plan_type = :plan_type,
            subscription_amount_usd = :amount,
            conversions_monthly_limit = :limit,
            take_profit_factor = :tpf
        WHERE id = :oid AND deleted_at IS NULL
    """), {...})
TP = 3 on a sub-org gives the operator 67% margin on that tenant’s work. TP = 2 gives 50%. They can grant 10,000 conversions at $500/month or 500 at $500/month, same cost ceiling for them, different unit economics for their users.
Admin panel showing all tenant organizations
Clicking into any org opens the subscription modal where Y, X, and TP are configured directly.
Manage Subscription modal showing Y, X, and TP fields
The operator sees their tenants’ parse history the same way they see their own. Each job record carries the conversion cost, document count, pages, transactions, and time. Filterable by org, searchable by book name, with aggregate stats across the selection.
Jobs dashboard with per-org filtering and aggregate stats
Because X cancels at every level, the margin guarantee holds independently at each layer of the stack. Pathway sets TP on the operator. The operator sets TP on their tenants. Each party’s margin is a function of their own TP and nothing else. On-prem deployments get the same structure. The operator sees the rate card, sees their TP, can verify the conversion math against every job record. The proofs hold for any party at any level because the algebra doesn’t depend on who’s running it.

​
The broader point

The conversion system is built around a specific assumption: paid tenants are high-trust relationships. The cost table is real, the formula is public, the proofs are on this page. An operator running Pathway on-prem can verify every conversion against the rate card and confirm that TP is the only markup. That trust runs in both directions. We trust our tenants enough to let them see the cost structure, and they trust us enough to let us optimize the pipeline without renegotiating every time we ship an improvement. The conversion is the contract that makes that possible. We can move to a cheaper model, add an expensive reconciliation pass, restructure the entire pipeline, and the org’s bill stays predictable because we absorb the variance into TP or pass the savings through. Because X doesn’t affect the cost bound, there’s flexibility in how we use it. A new org can get more conversions upfront to explore the platform, and we absorb that cost in exchange for learning their usage patterns and locking in the right price sensitivity before they commit to a plan. An org scaling up mid-month can get a higher limit without renegotiating. Operators can set conversion counts that make sense for their market’s expectations around unit pricing. The margin guarantee is structural. It follows from TP, and TP is set once per org.