What every applicant to Anthropic's New Markets & Monetization team should know

An unofficial technical cheat sheet for the four ownership areas inside one job description.

This is Lago's independent reading of Anthropic's public job description and documentation, informed by our experience building billing infrastructure. Anthropic did not brief us, review this article or endorse its conclusions. We focus on the systems and commercial decisions specific to this role, not general PM skills or culture fit.

Anthropic's Product Manager, New Markets and Monetization posting is really several founding PM roles. The four briefs are partner and platform billing; enterprise spend controls; one account and wallet across the API and Claude subscriptions; and a vertical.

This guide focuses on the first three connected problems.

In 2022, before ChatGPT or Claude Code, Lago published Why billing systems are a nightmare for engineers. The Hacker News discussion added 359 comments' worth of edge cases. Our original observation was right: billing is product infrastructure, not payment plumbing.

AI kept the old problems and multiplied the consequences. Lago has since implemented monetization infrastructure for AI companies including Mistral AI and Groq, developer platforms including Laravel, and enterprises including Bosch and LCL. The patterns below come from that work.

If you interview tomorrow, remember three things

One wallet is an identity and governance problem. An employee launches a shared agent; the team owns its budget, the parent company funds the commitment, and a marketplace may send the invoice.

Partner billing follows two paths. With Amazon Bedrock or Google Vertex AI, the customer buys Claude usage as part of the cloud provider's service. With Claude Platform on AWS or Claude in Microsoft Foundry, Anthropic calculates the charge and AWS or Microsoft adds it to the customer's cloud bill.

Helping companies build businesses on Claude is a differentiation opportunity. A legal AI company may pay Anthropic per token but charge its customer per contract reviewed. Anthropic can make that cost attributable and controllable without sending the end-customer invoice.

What we'd actually look for

Five things separate a strong answer from a generic one: how sharply you frame the problem, how you reason about the underlying systems, how commercially fluent you are, how you think about governance, and the product judgment to know what not to build. The three problems below are where each of those actually gets tested.

1. Who can spend what?

What looks simple

Give each company one account and wallet across Claude products.

What breaks in production

The "user" isn't one thing, and neither is the money behind it:

• The "user" may be a human, an agent, a service account or an API key.
• The agent may serve several teams or outlive the employee who created it.
• A team may control the budget while a parent company funds the commitment.
• A subsidiary may sign the contract while a cloud marketplace sends the invoice.
• Twenty agents can begin work against the same remaining balance.

A company can also buy Claude through seats, included allowances, prepaid API credits, invoiced usage, enterprise commitments and cloud providers. Most API organizations prepay; others settle monthly.

Anthropic tested part of this boundary in May 2026. It proposed keeping interactive Claude and Claude Code inside subscription limits while moving Agent SDK usage, claude -p, GitHub Actions and third-party Agent SDK applications to a separate credit.

We called that "finger-based pricing": the same capability was included while a human was at the keyboard, then metered when software invoked it. Anthropic paused the change before it took effect, so it is not the current model. But it exposed the question: when does one person's subscription stop covering work performed by their agents?

What you need to prove

You can separate identity, entitlement, budget, contract and payer, and explain what happens when their rules collide.

Go deeper: account trees, agents and real-time enforcement

The six layers that should not become one object

A user is no longer necessarily a person. An agent performs the work; a human or organization remains accountable for creating it, granting access and funding it.

Give an agent a stable workload identity rather than making it an extension of one employee. Its record can point to an accountable owner, while its entitlement and budget come from the workspace or project sponsoring each run. If one agent serves several teams, each invocation needs an explicit billing scope.

A parent-child account tree is equally easy to oversimplify. A parent can fund the commitment and allocate capacity to subsidiaries. Usage is attributed to the child, then settled against the parent. But that model fails when subsidiaries sign separate contracts, use different currencies or need separate tax treatment. The financial hierarchy may not match the organization chart.

Rate limit, spending cap and credit limit are different

• A rate limit controls throughput.
• A spending cap controls consumption over a period.
• A credit limit controls financial exposure.

Each can exist at the key, agent, user, team, workspace or parent level. Every proposal needs precedence and inheritance rules.

"Real time" is four promises

Suppose twenty agents begin work with $100 left. A strict cap requires a reservation before each request starts. Actual usage later consumes that reservation and releases the remainder.

Reservation adds latency and makes authorization an availability dependency. Long-running agents may have no useful maximum cost. Alternatives include bounded overshoot, queuing, model downgrade, rate limits or allowing in-flight work to finish under an overdraft policy.

Lago has worked on both sides of this problem. In our high-volume metering architecture, events flow through Kafka into ClickHouse while invoices and credits remain in Postgres. But fast ingestion alone cannot govern the next request. Lago therefore designed a separate real-time wallet architecture: available credit changes as usage arrives while a durable financial record remains available for corrections and invoicing.

For Claude, a hard cap is checked as an API request is admitted, before it is sent to a model. If that decision depends on a synchronous outside provider, the provider's latency becomes Claude's latency and its downtime can stop requests.

The practical design has two paths:

• a fast control path close to Anthropic's API infrastructure;
• a durable financial path that records actual usage and contractual charges.

They will disagree. Reconciliation is part of the design.

Three useful precedents

• Databricks: Nested shared, user and override budgets. Enforcement uses a near-real-time estimate and lets an in-flight request finish.
• GitHub Copilot: Included credits and overage controls exist at user, cost-center, organization and enterprise levels. A user can be blocked while a parent still has money.
• Vercel: Team, project, key and user budgets depend on the credential used. The limits are soft caps.

Anthropic's own documentation shows the same hierarchy problem: workspaces can have spend and rate limits below an organization-wide limit, while Claude Code can use separate workspaces and per-user keys.

2. How does one request become the right partner charge?

What looks simple

Let customers buy Claude through the cloud provider they already use.

What breaks in production

Every handoff between Anthropic and a partner is a place two systems can disagree:

• Anthropic and its partner may record the same usage at different times.
• The operational estimate, rated charge and marketplace record may disagree.
• Catalog price, negotiated discount and marketplace conversion can all apply.
• Anthropic and the partner may close different accounting periods.
• Refunds, disputes and failed submissions must remain traceable.

There are two paths:

In plain English: in the first path, the customer buys Claude from AWS or Google. In the second, Anthropic calculates what the customer owes, but AWS or Microsoft puts that amount on the cloud bill and collects it. Both require reconciliation, but the ownership of pricing and usage records is different.

What you need to prove

You can trace one API call to cash: every identifier, price transformation, owner, failure state and correction.

Go deeper: marketplace billing, reconciliation and commercial terms

Take Claude Platform on AWS. AWS documents that Anthropic rates usage at the applicable model and feature price, applies any negotiated discount, converts the charge into Claude Consumption Units and meters those units hourly through AWS Marketplace. AWS invoices monthly and applies the account's tax settings.

Anthropic documents that spend can take about two hours to reflect recent usage. A customer can exceed a configured limit before requests fail, and that overshoot is billable. The Claude Console shows cost by model and workspace; AWS Cost Explorer shows an aggregated CCU line.

One request can therefore create five separate records:

Now add failure:

• The marketplace submission times out after Anthropic records the request.
• A discount takes effect mid-period.
• A refund is approved after one party has closed the period.
• The customer disputes a line nobody can reproduce from the original call.

A robust model needs versioned pricing inputs (model, feature, metric, tier, channel, currency, effective date and contractual override) and reconciliation states such as matched, pending, rejected, corrected and written off.

The role also includes commercial terms. "The partner receives 20%" is not executable. Twenty percent of list price, net revenue or collected cash? Before or after credits, refunds, tax and marketplace fees? At event time, invoice time or settlement?

The PM will not set these terms alone. The work is to form a position with Finance, Legal and Business Development, model the economics, then make the negotiated result repeatable in the product.

The contract is not operational when the PDF is signed. Billing and settlement still need versioned rules.

3. How could Anthropic help companies build businesses on Claude?

What looks simple

Give builders accurate token usage and let them handle the rest.

What breaks in production

A company building on Claude pays for model usage but may charge for an outcome: a resolved ticket, reviewed contract or completed workflow. One outcome can invoke several agents, models and tools. Retries repeat cost without adding customer value. Model routing can alter margin mid-month.

This is a longer-term differentiation opportunity, not necessarily a current burning problem. Anthropic does not need to invoice those companies' end customers. It could make downstream monetization easier with stable sub-account attribution, granular cost metadata, timely usage streams, correction semantics and controls at project or customer level.

The boundary should stay clear:

• Anthropic owns trustworthy model usage and economics.
• The company owns its customer, value metric, price, invoice and collections.
• A monetization platform translates that commercial model into charges and financial records.

Stripe describes six AI pricing models, while ICONIQ reports increasingly hybrid combinations of platform fees, usage, commitments and overages.

What you need to prove

You can identify the smallest useful primitive, the adoption signal that would justify expanding it and the boundary that prevents Anthropic from building a full billing suite.

The interview exercise we would use

Take-home

An enterprise buys Claude through a cloud partner. A parent funds the commitment, subsidiaries receive budgets, and humans can launch concurrent agents. Mid-month, a discount changes. One marketplace submission fails; a credit is issued after invoice close.

In no more than four pages:

• draw the identities, accounts and money flows;
• define the customer promise for spend controls;
• identify systems of record and reconciliation states;
• propose the smallest product surface that handles the case;
• state what you would not build.

Live follow-up

Change one assumption at a time:

• The subsidiary signs its own contract.
• The agent serves two teams.
• The control service is unavailable.
• The partner rejects a correction.
• The customer demands an exact cap with no added latency.

The strongest candidate will not preserve the original architecture at all costs. They will say which guarantee must change, who absorbs the consequence and what evidence the customer receives.

Before drawing the system, decide who owes whom what, when, under which contract, and which record can prove it.

If you're building this at Anthropic or anywhere else, we've spent years on exactly this infrastructure.