Praxis is building a cloud system for the age of agents: a place where agents are born, grow and serve others. No single company can build such a system alone. It is assembled from components into a closed loop, and partners are one link that cannot be skipped. Like the resource layer, the runtime and the Praxis App, they are a necessary part of what makes the whole system run. This page explains how Praxis sees partners: which ones it needs, why, and how it treats them.

Why partners

Praxis spends its effort on the system itself: building, completing and maintaining the mechanisms that construct, run, release and operate agents. What lies outside the system, Praxis does not do by hiring more people. It does it through mechanisms and partners. That is not expedience; it is the model. No advertising, no sales force, no model training, no fight for the end market. The money and effort saved go back into the system and are shared with the people who help build it. The stronger the partner at each link, the more smoothly the loop turns.

Which partners

Following the Praxis model downward, six links in the loop need partners.

The six are not parallel slogans. Each matches an assumption in the business plan: supply partners decide whether the procurement advantage lasts, marketing partners decide whether growth without advertising works, service and industry partners decide whether the bet on specialisation is proven, and channels and community decide whether agents reach more people.

How Praxis treats partners

The Praxis attitude to partners comes down to three commitments, each backed by a mechanism.

First, the rules are written down and published. A partner never has to guess from relationships what the platform will do: how the share is computed, how attribution is decided and how parameters change are all on public pages, changes come with notice, and existing business keeps the old rules.

Second, the margin given up is really given up. The marketing spend saved does not go into the platform's pocket; it is shared with those who bring the workload. Discounts from supply partners become a Praxis price below list, and customers and partners both benefit.

Third, one standard for everyone. Praxis tells customers the truth, probes suppliers and compensates when they cut corners; it treats partners the same way, and the compliance and quality requirements in the clauses bind the platform as well.

Where to start

• To bring customers to Praxis, read Rising Tide: rules, examples, clauses, statements and how to join are all in that chapter.
• To become a supply, industry, channel or community partner, write to contact@deepractice.ai and say which link you are in and what you bring.

Rising Tide is the incentive plan of the Praxis Partner Program. This page runs from the intent to the split in one line, so every rule shows where it comes from.

The intent

Praxis wants to spend its effort on one thing: building, completing and maintaining the system, and giving the market a platform where agents work continuously in the cloud. Marketing and selling are not part of that. Praxis has no advertising budget and no sales force. The money that would have been spent there is kept and shared with the partners who build the ecosystem together. That is where Rising Tide starts, and every rule below follows from it.

The business itself

The Praxis business is simple: buy models, sandboxes, search and compute upstream, and sell them to customers by usage. Prices sit under an umbrella. The top is the vendor's list price, and the Praxis price is always below it. A partner who could only sell at the Praxis price would have no reason to exist, so partners set their own prices, with one limit: never above the Praxis price. Top to bottom it is one chain: the list price is above the Praxis price, and the Praxis price is at or above the partner's price. The share comes out of the platform's procurement margin, not the customer's price; a customer never pays more through you than directly, and any further discount comes out of your share.

What upstream looks like

A model passes through three layers before it reaches a customer. At the top is the model vendor, which trains the model and serves inference. In the middle is MaaS, model as a service: the vendor's own API or a cloud platform, supplying compute and an interface. Praxis is the third layer, the router: one address for every model, one routing layer, one bill. Praxis's upstream is MaaS.

Upstream prices to Praxis are not one uniform discount. They differ by model and by volume, and are often negotiated model by model. So every model has its own margin, and that is where "thin" and "thick" come from.

From margin to pool

The customer's usage revenue at the Praxis price, minus upstream cost, is the margin. The margin cannot all be shared. Praxis first deducts the losses of that business: taxes, payment fees, chargebacks and refunds, foreign exchange, retries. What remains is the contribution margin in accounting terms; Rising Tide calls it the pool. There is one pool per customer, per model, per month. The platform keeps one floor: the pool must not be negative. A negative model is not sold at the uniform discount; it is sold at list, renegotiated upstream or withdrawn, and no other model subsidises it.

Why pools are thin or thick

Upstream decides the thickness. Models with scarce, heavy compute get shallow upstream discounts, so their pools are thin. Open-source models and models in ample supply get deep discounts, so their pools are thick. Within one customer's month, both kinds usually appear together.

How the pool is split, and why

The rule follows the thickness. Thin pool: all of it is yours and Praxis keeps nothing; any pool below 5% of usage revenue is thin. Thick pool: you and Praxis take half each; any pool above 10% of usage revenue is thick. In between, you receive a fixed 5% of usage revenue.

A thin pool goes entirely to you because a thin pool means Praxis has no volume on that model yet and no bargaining power with the supplier. What the platform needs most then is volume, so it gives the whole pool to whoever brings it and takes nothing: zero margin in exchange for volume. A thick pool is split because a thick pool means the discount has been negotiated, and that is what volume bought. The platform then takes the share it is due, to build and maintain the system, so the pool is halved. The 5% floor in between keeps your income from dropping as a model moves from one state to the other. Two faces of one rule: the platform yields until there is volume, and everyone shares once there is.

The 5% floor is set at the industry's resale margin: pure cloud resale earns high single digits, and double-digit margins come from value-added services¹; the model aggregator OpenRouter passes vendor prices through and charges 5.5% only on top-ups². What differs in Rising Tide is that on a thin pool the 5% is all yours, and on a thick pool you take half.

In the figure, the horizontal axis is the pool as a share of usage revenue and the vertical axis is what you receive. The left segment follows the pool one for one, the middle is flat at 5%, and the right rises at half slope. The curve never falls: a thicker pool never lowers your share.

More volume, thicker pools

The volume you bring lets Praxis negotiate deeper upstream discounts, discounts thicken the pool, and a thick pool is split in half with you. That is the rising tide that lifts every boat. Tiers are designed and not yet enabled: once they are, a higher share applies to the part of your monthly consumed revenue above each threshold, with 90 days' notice.

Why everything is public

Margins at the resale layer are thin and reasonable across the whole industry, as the numbers above show. Praxis never planned to earn much at this layer; the platform's profit comes from the agent layer above it. With nothing in the books worth hiding, opening them costs nothing and buys trust: you need not guess what the platform keeps, and customers know that buying through you costs nothing extra. Research reaches the same conclusion: a seller that discloses its cost structure gains trust when the margin is seen as reasonable³, and in long-term relationships where the other side can help cut costs, open books work better than secrecy⁴. When you see that a model's pool is thin, you know Praxis has no bargaining power on that channel; if you have a better one, you bring it, and a thicker pool pays you more too.

Transparency has a boundary. Real models' pools appear only on your statement after signing, for your own customers, under the confidentiality clause of the agreement; the public pages carry rules and illustrative numbers only. Signed partners are covered by parameter-change protection: any change to the floor, the split or the tier thresholds comes with 90 days' written notice, and existing customers settle on the old parameters for 12 months.

The next page turns this line into money across four illustrative months: Earnings examples.

References

This page does one thing: it turns the three sentences of At a glance into numbers. All amounts are illustrative US dollars. Models are lettered and do not correspond to any real upstream discount. Parameters are the current values: 5% floor, 50% split, 3% loss provision.

Each case first computes the pool, then applies one formula:

pool       = usage revenue − upstream cost − usage revenue × 3%
floor      = usage revenue × 5%
your share = min(pool, max(floor, 50% × pool))     when pool > 0
           = 0                                     when pool ≤ 0

Case 1: thin pool, all yours

Model A's upstream discount is still shallow, so the margin is thin. The customer consumes 1,000 dollars this month.

The pool of 30 is thinner than the floor of 50, so the whole pool goes to you and Praxis earns nothing. A thin-pool model is sold at zero margin: volume first, upstream discount once volume arrives.

Case 2: thick pool, split evenly

Model B's discount has been negotiated, so the margin is thick. The same customer consumes the same 1,000 dollars.

The pool of 170 exceeds 10% of usage revenue, so it is split 50/50 and you receive 85. On the same 1,000 dollars of usage, the thick-pool model pays you almost three times as much. The platform negotiated the discount; the even split is what you earned.

Case 3: one customer, four models, a full month

A real month mixes models. The customer consumes 9,000 dollars across four models.

Three things to read. First, each model has its own pool. Model D's negative pool pays no share, and no other model's positive pool fills it. A model like D is repriced or withdrawn. Second, model C sits in the middle band, with a pool of 120 between 5% (75) and 10% (150) of its usage revenue, so you take the floor of 75 and Praxis keeps 45. Third, the total of 560 is your share for the month, 6.2% of the customer's consumption.

Settlement holds back 10%:

Case 4: you discount for the customer

To win model B, you promise the customer another 5% off. The discount comes out of your share; the pool is unchanged.

This rule protects the price chain: the customer pays the same Praxis price through any channel. A discount is your business decision, and its cost is yours.

Four cases later, every rule has a number. The rules themselves are on the next page: Rules.

This page is the rules themselves, without explanation or examples. Explanation is in At a glance; examples are in Earnings examples. When the agreement's annex cites this page, the current version governs; the version date is in the footer.

Terms

Prices are per model and per token type (input, output, cache write, cache read), in US dollars per million tokens, before tax.

Three price levels

1. The list price is set by the vendor's pricing page; Praxis records the source and date.
2. The Praxis price is below the list price, published site-wide and identical for all customers; the four token types share one discount.
3. The partner price is not above the Praxis price. Any further discount a partner grants is deducted from the partner's share and does not enter the pool.

The pool

The pool is computed per (customer, model, settlement period), all in current-period amounts:

pool = usage revenue − upstream cost − usage revenue × loss rate

The four token types of one model are summed before the sign of the pool is determined. A negative pool is not offset against another model's positive pool.

The share formula

floor   = usage revenue × x
partner = 0                                     when pool ≤ 0
        = min(pool, max(floor, r × pool))       when pool > 0
Praxis  = pool − partner

The formula yields three bands. A pool not above the floor is thin: the whole pool goes to the partner. A pool not below twice the floor is thick: it is divided by r. Between the two, the partner receives the floor. The partner's amount never decreases as the pool thickens.

Order of computation

1. Usage is frozen on the third day after the settlement period ends.
2. Usage revenue and upstream cost are aggregated per (partner, customer, model).
3. r is determined from the partner's total consumed revenue for the period (once tiers are enabled).
4. The floor and the share are computed per (customer, model).
5. Related-party transactions are zeroed; refunds are reversed against the original period.
6. The holdback is deducted, the run is locked and the statement is issued.

Every usage event freezes the price version in force when it occurs; settlement only aggregates and never looks up current prices.

Parameters

Parameter changes follow clause 2 of Governance.

The rules say how money is divided; the clauses say how the rules hold. Each of the eleven has three columns: the clause text can go straight into the agreement, the plain reading says what it means day to day, and the reason says why the rules would fail without it. The first eight were set when the plan was designed; the last three stop a customer from building a shell to become its own partner.

Clauses

How the clauses work together

The eleven fall into three groups. Clauses 1 and 2 protect the partner: attribution and parameters both have protection periods. Clauses 3, 4, 6, 7 and 8 protect the formula: the basis, the holdback, discounts, price changes and negative pools each have a place to go, so the formula computes in any month. Clauses 5, 9, 10 and 11 keep both sides lawful and shell-free: related parties, matched identities and self-purchases earn nothing.

The clauses do not depend on any one country's law to hold. They state three floors that apply almost everywhere: paying a customer's employees or decision-makers is commercial bribery, prohibited in most jurisdictions¹²; disclosing a share arrangement to the customer is a standard consumer-protection requirement³; an intermediary relationship rests on a written agreement. Governing law and dispute resolution are set in the intermediary agreement, and partners also follow the anti-bribery and disclosure rules of their own jurisdiction.

Applied to each month's numbers, the clauses become the next page: Statement.

References

You receive one statement per settlement period. It is broken down by model, and every line can be recomputed from the formula in Rules. This page explains how the statement is produced, what it looks like and when the money arrives.

Monthly settlement

The settlement period is the calendar month. The process has eight fixed steps in a fixed order:

Once issued, a statement is locked and is not recomputed for later price changes; disputes are handled by an adjustment recorded in the next period.

Statement layout

The body of the statement is a single table broken down by model. Below is Case 3 from Earnings examples in statement form:

Four summary lines follow the table:

With several customers, the statement has one section per customer, each with its model table, followed by a total across all customers. A CSV with the same column headings accompanies every statement.

Holdback release timeline

Holdbacks roll period by period. Taking January's usage as the example:

At any moment roughly three periods of holdback are in transit. A refund before the release is deducted from the holdback; a refund after it is reversed against the current share, and a negative net carries forward.

Invoicing and payment

• You invoice Praxis for the payable amount on the statement; the share is tax-inclusive, and taxes follow the regulations of each party's jurisdiction.
• Settlement is in US dollars; Praxis pays within 15 working days of receiving a compliant invoice; the payment method is agreed in the intermediary agreement.
• A payable below 100 dollars is carried forward and paid together with the next period.
• Disputes are raised within 15 days of issue; after that the statement is deemed confirmed, and adjustments are recorded in the next period.
• A statement lists only the models your own customers used; the upstream costs and pools in it are covered by the confidentiality clause of the intermediary agreement and may not be disclosed to third parties.

Every number on the statement traces to a rule. What remains are usually situational questions, which are in FAQ.

Questions are in the order partners weigh them when deciding whether to join. Answers are short and link to the rule or clause they rest on.

If the customer bypasses me and goes to Praxis directly, do I still get a share

Yes. A customer is attributed to you for 6 months after registration and 24 months after the first purchase, whatever channel the customer orders through. See Governance, clause 1.

Does the customer know I receive a share

Yes, but not the amount. The Praxis customer terms contain one general sentence: Praxis may have a revenue-share arrangement with the partner who introduced you, and it does not affect your price. Your specific share is not disclosed to the customer. See clause 5.

Can I sell above the Praxis price

No. The partner price is not above the Praxis price; that is part of the price chain. What you can do is discount from your own share. See the three price levels in Rules and clause 6.

Does the customer pay more through me than directly

No. The share comes out of the Praxis procurement margin and is not added to the customer's price. You may discount from your own share, so going around you costs the customer the same or more.

Why does a negative-pool model pay nothing

Because that model is selling at a loss. A pool at or below zero means upstream cost plus provision already exceeds revenue, so there is nothing to share. Such a model is repriced or withdrawn and does not persist. See clause 8.

Can the parameters change overnight

No. Changes to the floor, the split or the tier thresholds come with 90 days' written notice, and your existing customers settle on the old parameters for 12 months. See clause 2.

Why is the basis consumption rather than top-ups

Top-ups can be refunded; consumption cannot. On a top-up basis, one end-of-month deposit could reach a tier, and after a refund the share could not be reclaimed. See clause 4.

The customer got a refund; what happens to my share

The refund is reversed against the original consumption period. If that period's holdback has not yet been released, it is deducted from the holdback; if it has, it is reversed against the current share, and a negative net carries forward. See clause 3 and Statement.

Can my own company be a customer

No. A customer owned, controlled or operated by the partner, its employees, family members or related parties earns no share, and the system matches ID numbers, phones, emails, payment accounts and login origins. See clauses 5, 9, 10 and 11.

When will tiers be enabled

Once volume arrives. The tier structure is already in the rules, with provisional thresholds of 20,000 and 100,000 dollars of monthly consumed revenue, and the higher rate applies only above each threshold. Enabling them comes with 90 days' notice.

Three cautionary cases

Every clause answers a trap someone else has fallen into.

• Attribution is decided on the system record. Leading eBay affiliates collected commissions by stuffing tracking cookies; one of them took about 5.2 million dollars and was sentenced to 15 months in 2014 by a US federal court¹. If attribution records can be manufactured by participants, someone will manufacture them.
• Related-party dealings must be disclosed. In July 2026 the short seller Culper Research publicly challenged ADMA Biologics over disclosure of channel rebates paid to a related party; the company denied it the same day, and its shares fell almost 30% in one day². The allegation is unadjudicated; the market reaction alone shows that an undisclosed related-party arrangement is a risk. Rising Tide writes related-party exclusion into the clauses and requires an annual declaration.
• Direct selling over the channel's head is an old disease. A survey of channel solution providers found that only about four in ten trusted vendors to protect their registered deals, and about a third had been undercut by vendor direct sales³. Rising Tide answers with a 24-month attribution period.

If your question is not here, write to the partner team at the address in How to join.

References

The Rising Tide rules are public; membership is not automatic. Joining takes four steps, and a person looks at each one.

Why by application

Public rules do not mean public membership. Rising Tide runs on three gates, and the gates protect partners who play by the rules: bad partners cannot get in, the rules cannot be gamed, and money paid out can be recovered.

Four steps

Documents

• Entity: business licence or equivalent registration; individual applicants provide identification and a description of their business.
• Channel: who your customers are, which industry, how they use model capacity today, and the expected order of monthly consumption.
• Background: previous software, consulting or channel business, with cases or customer references if available.
• Related-party declaration: confirmation that you have no employment or family relationship with the decision-makers of the customers you intend to register, and that neither you nor your related parties will be customers.

What the review looks at

The review answers three questions: whether the entity is independent and real; whether the channel is real, meaning the customers exist or can be verified; and whether the applicant and the intended customers have any relationship excluded by clauses 5, 9 and 10 of Governance. All three must pass before signing. The review does not look at your size: the thin-pool logic holds for a small channel just as well.

How to register a customer

In the partner area, submit the customer's entity name and the email of the account to be opened. Registration takes effect immediately, timed by submission; that is the "first to register" rule of clause 1 of Governance. After the customer's first purchase, registration becomes a 24-month attribution.

After signing

• Partner area: register customers, check attribution, download statements.
• A monthly statement in the layout on the Statement page.
• Changes to rules and clauses notified under clause 2.
• Either party may terminate the intermediary agreement with 30 days' written notice; attribution and shares on customers already registered and converted continue to the end of their terms, and holdbacks are released on the original schedule.
• The intermediary agreement is governed by Hong Kong law, and disputes go to arbitration at the Hong Kong International Arbitration Centre.

Send applications to contact@deepractice.ai with the subject "Rising Tide application · entity name".