AI Cost per Transaction: The Unit Economics Formula Every Marketplace Engineer Should Know

Engineers are good at measuring latency, error rates and throughput. We are usually much worse at answering a simpler question about the AI features we ship: does this thing make more money than it costs?

On a marketplace, that question has a precise answer, and you can compute it with data you probably already log. This post walks through the math as a small model you can implement, based on the Journeyhorizon guide to AI unit economics for marketplaces.

Pick the right unit

Unit economics is revenue per unit minus the direct cost of delivering that unit. The mistake most teams make with AI is picking the wrong unit. The monthly model bill is not a unit. A single API call isn't a useful one either.

For a marketplace, the natural unit is the completed transaction. You compare the commission or fees you earn on one transaction with the AI cost of every session it took to produce that transaction.

That framing explains why marketplaces differ from SaaS. In SaaS, AI often lowers support costs or improves retention. In a marketplace, AI often decides whether a transaction happens at all: search, matching, trust. And marketplaces fund AI out of the take rate, so you must benchmark AI spend against net revenue, not gross merchandise value.

The guide cites Andreessen Horowitz's essay "The New Business of AI", which reported many AI companies running gross margins of 50 to 60%, compared with 60 to 80% or more for comparable SaaS, because compute scales with usage. With a 10% take rate, a marketplace has even less room to absorb that.

The three formulas

cost_per_action      = input_tokens  * input_price
                     + output_tokens * output_price

ai_cost_per_txn      = cost_per_action * actions_per_completed_txn

ai_share_of_net_rev  = ai_cost_per_txn / (avg_order_value * take_rate)

As a function you can drop into a notebook:

def ai_share_of_net_revenue(in_tok, out_tok, in_price, out_price,
                            actions_per_txn, aov, take_rate):
    per_action = (in_tok * in_price + out_tok * out_price) / 1_000_000
    per_txn = per_action * actions_per_txn
    return per_txn / (aov * take_rate)

Prices are per million tokens. The October 2026 list prices quoted in the guide (input / output):

• Claude Sonnet 5.5: $2 / $10, cached input reads $0.10
• Claude Haiku 5.5: $0.10 / $0.50
• gpt-6.1-sol: $2 / $10
• gpt-6-luna: $0.10 / $0.50
• Gemini 3.8 Flash: $0.75 / $3.75
• Batch APIs: roughly 50% off for non-urgent work

Confirm these on the provider pages before you rely on them.

Example 1: an AI search assistant

The guide's illustrative services marketplace:

• Average order value $120, take rate 10% → $12 net revenue per booking
• Six turns per search session, ~4,000 input and ~300 output tokens per turn
• 4% of sessions convert → 25 sessions per booking

Run it through the model:

Scenario	Per turn	Per booking	Share of $12
Mid-tier model ($2 / $10)	~$0.011	~$1.65	~14%
+ caching 3,000 of 4,000 input tokens	~$0.005	~$0.80	~7% (before cache-write charges)
Simple turns routed to a $0.10 / $0.50 model	—	under $0.10	under 1%

Same feature: 14% of your take or under 1%. And note the other lever: doubling the conversion rate halves AI cost per transaction without touching the model at all. Product quality and cost efficiency are the same equation.

Example 2: AI listing descriptions

On the seller side, a description with 1,500 input and 400 output tokens costs about $0.007 on a $2 / $10 model, about $0.0035 through a batch API, and a fraction of a cent on a small model. It runs once per listing instead of once per buyer session, so it is usually easy to justify. Journeyhorizon offers an AI product description generator for Sharetribe for exactly this use case.

Costs your token math will miss

The model bill is only part of the fully loaded cost:

• Retrieval and embeddings scale with catalog size, not just traffic.
• Data preparation: cleaning, normalizing categories, labeling and pipeline maintenance, often needing dedicated engineering time.
• Monitoring and evaluation: quality drifts as sellers and buyer preferences change.
• Fallbacks and human review: review queues, dispute escalation, support time for wrong outputs.
• Power users: a small group of heavy users can drive a large share of cost, so track cost per active user by tier.

Three levers to pull

Lever 1: lower cost per action

• Route classification, tagging and short answers to small models.
• Cache system prompts and category data.
• Use batch APIs for listing enrichment and nightly re-ranking.
• Trim prompts and cap output.
• For self-hosted models, consider quantization and right-sized GPUs.

Lever 2: raise revenue per AI-driven action

• A/B test against a non-AI baseline so you measure incremental lift, not total conversions.
• Feed in marketplace signals: seller ratings, response times, past buyer behavior.
• Better matching raises conversion, which directly lowers AI cost per transaction.

Lever 3: scope AI to where value is

Prioritize search ranking, buyer-seller matching, fraud checks on larger transactions and listing quality. Use rules for low-value interactions. Broad "AI everywhere" deployments tend to grow cost with little measurable return.

Build the model in six steps

1. List every AI feature and define its unit (search session, generated listing, fraud check).
2. Pull 30 days of usage: actions, tokens per action, model used.
3. Compute fully loaded cost per action, including retrieval, infrastructure and human review.
4. Estimate actions per completed transaction and convert to AI cost per transaction.
5. Compare with net revenue per transaction (aov * take_rate) and your measured A/B lift.
6. Break it out by segment and usage tier to find unprofitable pockets.

Then stress-test it. What if lift is 2% instead of 5%? What if a provider raises prices or retires the model you depend on? Build buffers in. Review monthly while a feature is new and quarterly once it's stable. When predicted and observed results diverge, it often means the AI is solving the wrong problem.

Build, buy or partner?

The guide's illustrative case: 100,000 transactions per month, $80 average order value, 12% take rate, which gives $960,000 monthly net revenue. Allocate 3% to AI and you have about $28,800 a month. At that volume, buying a third-party API or plugin is the clear choice. At ten times the volume, the same 3% funds a dedicated team, and a custom system with even a small conversion lift can justify itself.

A middle path is bringing in specialists for an architecture review, so model, routing and data decisions are made before they harden into code.

Common traps

• Shipping AI because competitors have it, with no financial measurement.
• Treating data and quality work as a one-time cost.
• Over-optimizing quality: a frontier model that costs many times more for gains that don't move conversion, retention or savings.

The safer path is to start with one use case in a high-traffic flow, measure revenue impact against cost, and scale only while the ratio holds.

Takeaway

Put AI cost per transaction next to take-rate revenue in the same dashboard and you'll make better product calls almost automatically. If you want help designing that model or the architecture behind it, Journeyhorizon offers AI strategy and architecture for marketplace teams.