Refer idle code. Earn 15% of what they make.
Your network is sitting on code that AI labs pay to license. Introduce those owners through your referral link and you earn 15% of everything they're paid, at no cost to you or them. This guide covers both halves: what you earn, and how to brief the people you refer.
The figures an owner sees (roughly $100 per million tokens of source code and $40 per million tokens of git history) are indicative, deliberately conservative estimates, not guaranteed payouts. Your 15% is a share of what they're eventually paid, so the final figure depends on the sale and buyer demand.
Real-world code is the scarce ingredient.
Frontier AI labs train and evaluate their coding models against genuine production code: the source and the git history behind it, how features were built, how bugs were fixed, how a project evolved over time. That kind of verified, real-world code is what's in short supply, and demand for it is high right now. The projects the owners in your network have already delivered are exactly that.
Genuine, verified production code is the ingredient labs are short on, and it can't be synthesised.
Buyers are actively acquiring real-world codebases to train and test their models, and that appetite is growing.
Commits, tickets, and fixes carry real signal, so owners are paid for the history too, not just the final source.
From your link to your payout.
Get your tracked links
We set you up with two referral links, one per audience. Every sign-up through them is attributed to you.
Refer a code owner
Share the right link with someone who owns idle private code. That's the whole ask of you.
We handle the process
Valuation, legal, buyers, and the sale are all run for you. You never touch the process.
You earn 15%
When the owner is paid, you're paid 15% of it within 15 days. If their code is licensed again, you earn again.
Revenue from work they've already delivered.
Found money
Owners monetize projects that are already built and paid for.
Paid per licence
A codebase can be licensed more than once, and the owner earns on each licence.
Zero cost, zero lift
No fees; our partner handles valuation, legal, and the sale.
Owners choose what's shared
Only the repos they pick are licensed; nothing else is touched.
Two kinds of owner. Two links to share.
You get two tracked referral links, one per audience, so you send the right one and every sign-up is attributed to you. Same 15% on both, paid each time a codebase is licensed.
Dev agencies
Agencies sit on years of delivered projects, R&D, and internal tools that go idle the moment an engagement ends. That private code, and its full commit history, is exactly what labs license. They license only repos they own and choose, so client work and NDAs stay out, and they keep full ownership and internal use.
Individuals & companies
Freelancers, founders of wound-down startups, fractional CTOs, and companies with shelved internal tools all own idle code. A dead project or a retired internal tool can still pay, and you're paid for connecting them. They redact anything sensitive before submitting.
A low-key way to raise it.
You don't need a hard pitch. Anyone who owns dormant, private code they built is a fit. Here's a simple way to open the conversation; the detail is in this guide, and we handle everything once they sign up through your referral link.
"Do you have codebases sitting idle since a project wrapped? There's a way to earn from them."
"AI labs pay to license real-world private code. A partner values it, handles the legal, and sells it, and you're paid for each licence, which can happen more than once."
"It's free, you keep ownership and full use, and you choose which repos. Want me to send you my referral link?"
Your 15%, and how it works.
Your whole side of the deal in one place, so you never have to leave the guide: how the fee is worked out, when you're paid, and how referrals are tracked to you.
The people you refer are paid roughly $100 for every million tokens of source code and $40 for every million tokens of git history, and you earn 15% of whatever they're paid. Here's exactly how that works.
The rules, in short
| Term | What it means for you |
|---|---|
| 15% of what the owner is paid | For each codebase transaction (a licence or sale, exclusive or non-exclusive) involving an owner you referred, you're paid 15% of the amount that owner receives. |
| Paid on top, nothing deducted | The owner keeps their full share. Your 15% doesn't come out of their pocket, and it's free to become a partner. |
| Paid on every licence | You're paid on every licence of a referred codebase, not just the first. A codebase can be licensed more than once, but the number of licences is never guaranteed. |
| Paid within 15 days | You're paid within 15 days of the referral fees being paid out, in USD, into the payout account you set up. Fees are only ever paid from amounts actually collected. |
| Two tracked links | You get two unique referral links, one per audience. Attribution is by link only, so there's no shared tracker to maintain. |
| Survives termination | Either side can end the partnership on 30 days' notice, but your right to fees on codebases you already referred continues on any future licences of them. |
What your referrals could pay you
A quick, illustrative ballpark of your earnings: 15% of what the owners you refer are paid. Real figures depend on each codebase and buyer demand.
Your referrals
People or companies you refer, times the repos each licenses, at a typical codebase depth. You take 15% of what the owners earn.
Owner earns per repo: Light $700–$1,000 · Typical $1,000–$1,500 · Deep $1,500–$2,000. You earn 15% of that.
Often more than once. A codebase can be licensed again, and each licence pays you again, though the number of licences is never guaranteed.
Pangea has already paid $600,000 to code owners across the network. A partner who had referred those owners would have earned 15% of that, and would earn again on any of those 380 codebases that are licensed more than once.
How a referral is tracked to you
An owner counts as yours when they first engage the program through your link and weren't already an active Pangea customer or in the documented pipeline. If you're ever unsure whether someone will be attributed to you, check with jazlin@pangea.ai before they sign up.
| Rule | Detail |
|---|---|
| 10-business-day flag | Once someone signs up through your link, Pangea has 10 business days to flag a pre-existing relationship or documented pipeline entry. If it isn't flagged in that window, the referral is conclusively yours, absent fraud. |
| 6-month activity window | Attribution through your link lapses if the owner hasn't engaged the program within 6 months of first using it. If they return through your link later, attribution starts again. |
| Refer in good faith | Stick to materials Pangea provides or approves, and don't present value estimates as guaranteed payouts. You and Pangea are independent parties; a referral doesn't make you an agent or employee. |
Your fee, answered
How much do I earn, exactly?+
15% of whatever the people you refer are paid, on every deal. As a rough basis, owners are paid about $100 per million tokens of source code and $40 per million tokens of git history. The owner keeps their full share; your 15% is paid on top and doesn't come out of their pocket.
Can I earn more than once from the same referral?+
Often, yes. Because licences are non-exclusive, a referred codebase can be licensed more than once, and in practice repos are frequently licensed two or three times or more. You earn your 15% on each licence, not just the first. That said, the number of licences is never guaranteed and depends entirely on buyer demand.
When and how do I get paid?+
Within 15 days of the referral fees being paid out, in USD, into the payout account you set up. Fees are only ever paid out of amounts actually collected, but every collected deal on a referred codebase pays you.
Does it cost anything, for me or the people I refer?+
No. It's free to become a partner, free to share your links, and nothing is deducted from what the owner takes home. Your 15% is paid on top.
How long does the arrangement last?+
Either side can end the partnership on 30 days' notice, but your right to fees on codebases you already referred survives termination. You keep earning on any future licences of them.
What makes a repository eligible.
What makes a codebase a fit for licensing, and what rules one out, so you know before you submit.
Eligibility is separate from grade. A repository can be perfectly eligible and still score poorly; the grade affects what it sells for, not whether it can be taken.
It must be private, and never have been public
This is the one hard rule. Buyers pay specifically for code that isn't already in a public training corpus, so anything ever published is worth nothing to them, whatever it scores.
Screened in about two seconds, before analysis
The check runs on metadata and a handful of HTTP requests at submission, so nobody waits on a full analysis to find out a repository was never eligible.
What rules a repository out
Each of these is an automatic decline, and each is evidence you can verify from a link:
| Reason | What it means |
|---|---|
| Publicly readable today | The repository page loads for a signed-out visitor. This is by far the most common reason. |
| Public at some point in the past | The Internet Archive holds a crawl of the repository page. Their crawler isn't logged in, so a snapshot proves it was public on that date. Making it private now doesn't undo this. |
| A fork of someone else's project | The upstream code isn't yours to license. |
| Published as a package | Shipped on npm, PyPI or similar. The source is already distributed. |
A repository is never declined because of a network problem on our side. Every probe fails open: an archive.org outage, a rate limit, or an expired token produces "inconclusive", never a rejection. Softer signals, such as an open-source licence file on a repository that was never actually published, are flagged for a human rather than declined automatically.
What counts toward the valuation
Value is calculated from two numbers: the source code at the current head of the repository, and the additional code that exists only in its git history. Both count only real source and code-adjacent files.
| Counted | Not counted |
|---|---|
| Application source in any mainstream language, plus shell scripts, SQL, schema files (GraphQL, Protobuf), web markup and styles, and project files such as YAML, TOML, JSON, XML and Markdown. | Dependency and build directories (node_modules, vendor, dist, build, target, Pods and similar), and any non-code file: archives, binaries, images, video, fonts, model weights, data dumps and logs. |
This matters more than it sounds. A repository can look substantial on disk and value low because most of its weight is a vendored library, a committed build output, or a large archive. None of that is code a buyer can train on, so none of it is counted as source.
There's one proportion rule worth knowing. Markup, data, config and docs count up to 10× the code beside them: enough that a well-documented, well-configured project is paid for that work, without a repository of mostly data pricing like a repository of mostly code. Where real data or docs sit beyond that line, the row is flagged and may be priced in full, so the count only ever rises from there.
Git history is counted per file, capped so a machine-generated file re-committed hundreds of times can't dominate a valuation. Ordinary hand-written history is counted in full; the revisions of real source are a meaningful part of what a buyer receives.
Ownership
Ownership remains with the code repository owner uploading the repository. They must confirm that they own the code, or otherwise have the legal right to license it, and we rely on that confirmation and the warranty in the signed agreement.
We do not require supporting documents upfront and cannot independently verify ownership simply because someone has access to a repository. If the uploader confirms contractually that the code is theirs and can be licensed, we accept that representation and proceed accordingly.
Where the code belongs to a client, is jointly owned, or includes another party’s intellectual property, the uploader must have permission to license it. In practice, supporting documents are usually only asked for if a buyer’s due diligence calls for them, though §5 of the agreement lets our partner request redacted chain-of-title documentation (IP assignments, asset purchase agreements, prior licences) on reasonable request at any point, and you can redact whatever isn’t needed to confirm ownership.
Open-source & third-party disclosure
Every repository has an "Open-source & third-party disclosure" field in the product. It's required before a repository is approved for listing, and it gates listing rather than signature, so it never holds up signing an agreement.
What matters most is copyleft, GPL, AGPL and LGPL especially. AI buyers warrant hard against it, and an undisclosed copyleft dependency can unwind a deal after it has closed. Anything works as a format: type it into the box, or attach an SBOM (CycloneDX or SPDX), a lockfile, or a CSV listing component, version, licence, and whether attribution, source-disclosure, copyleft or redistribution obligations apply.
Grade is commercial, not eligibility
A low grade never makes a codebase ineligible, and it doesn't take it off the table either. Our partner shops every repo around whatever its score, and a higher score simply makes it more desirable to the labs. The largest lever on almost every repository is real tests wired into CI, followed by a runnable README with an environment example, a CI pipeline running lint, type-check and tests on every pull request, tidy code, and a committed lockfile. Those are the gaps our partner's upgrade pass closes on its own copy, so a low grade costs you nothing, though it's still worth understanding. See How We Grade for the full rubric.
None of that is work for you to do. Where a repository grades below the bar, our partner runs an upgrade pass over its own working copy and adds what's missing, then re-grades it. Your original is never written to, and you get the full list of what was added.
A quick self-check before you submit
| Ask | Why it matters |
|---|---|
| Is the code private, and has it always been? | If any of it was ever on a public repository, published as a package, or forked from an upstream project, that part isn't licensable. |
| Do you own it outright? | If a client does, or co-owns it, flag it early so the sign-off can be arranged. |
| Is it real application code? | Repositories that are mostly assets, archives or vendored dependencies value far lower than their size suggests. |
| Do you know what open-source you depend on? | Particularly anything copyleft. |
Monetize your agency's codebases.
The full flow, step by step. Brought to you by Pangea.ai.
Overview
Pangea.ai works with a specialist partner to help the agencies in our network turn code that is otherwise gathering dust into revenue. AI labs and other buyers are actively paying to license real-world source code, and our partner handles the entire sale. This guide walks you through the whole flow: open your Pangea.ai link, sign one short agreement, connect your Git providers, pick the repos you want to license, and add a little context for each one. Our partner's team reviews and sells from there, and you are paid on each licence of your code, and a codebase can be licensed more than once.
Step by step
The standing rates
As you select repos, you'll see the estimated value of each one and a running total, so you know what a repo is worth before you submit it. The rates above are your side of a sale: nothing is deducted from them, and they aren't a gross figure someone takes a cut of. They set the basis a deal is priced on, not the amount that lands. And because a codebase can be licensed more than once, that basis applies on each licence, though repeat licences aren’t guaranteed.
These figures are estimates only, not guaranteed payouts. Token counts and final value are subject to our partner's analysis, which determines what is counted and may exclude files or data. Final value also depends on buyer demand.
Quick reference
| Action | Where |
|---|---|
| Get started | Your Pangea.ai referral link |
| Open the licensing flow | Sidebar → Code Licensing |
| Sign / download the agreement | Code Licensing → Codebase Agreement card |
| Add more repos later | Code Licensing → Submit for Analysis |
| Edit any field | Expand a repo → type in the field → auto-saves |
| Questions | Reach out to your Pangea.ai contact |
How we grade codebases.
Every codebase you submit is scored against the same fixed rubric, so you can see exactly where it stands and what a buyer sees. Lifting a repo that falls short is our partner's job, not yours.
A grade is a commercial signal, not a gate. A higher grade makes a codebase more desirable to the labs, not eligible: the score is a commercial signal, never a gate. Where a repo grades below B, our partner upgrades its own working copy first and re-grades it, so there's no remediation work on your side either way.
Scored on a clear, consistent rubric
Every repository is graded the same way, against a fixed rubric, across eight dimensions: architecture, test coverage, docs, security hygiene, code cleanliness, history and maintenance, dependency health and CI/CD. You see the score for each dimension and the evidence behind it, so a grade is never a black box.
Our partner does the lifting, not you
Where a repository grades below the bar, our partner runs an automatic upgrade pass over its own copy and adds what's missing. You submit the repo as it is; nothing is asked of your team, and your original is never written to.
What buyers filter on first.
Before the rubric, buyers screen for a handful of numbers that only a real, team-built project tends to carry.
Rough thresholds, not hard gates. Smaller and solo repos are presented too, and what each lab wants shifts month to month, so the best move is to have more of your work in the catalogue, not to pre-filter it.
Five things that make a repository strong.
Roughly in the order they ask them.
Production reality
Built for a company, a client or a product, with real users. Commercial applications, client systems, internal tools and backend services beat tutorials, templates and experiments.
Completeness
A whole project, not snippets: source with its tests, docs, configuration and dependencies. Context is what teaches a model how software fits together.
Development history
Years of commits, branches, merged pull requests and fixes. History shows the before and after of every change, which is exactly what coding models train on.
Engineering quality
Clean architecture, real tests, CI, consistent practice, meaningful commit messages. A mature production repo beats a freshly generated one holding the same amount of code.
Scarcity
Code the public datasets do not contain: enterprise systems, specialised industries, less common languages, legacy stacks and multi-service architectures. Rarity is the one dimension that cannot be manufactured after the fact.
What drags a repository down.
Forks and mirrors
If the base is public, models have already trained on it; only original work carries value.
Tutorials & boilerplate
Coursework, templates and scaffolding are the most duplicated code on earth.
Generated bulk
Generated files, vendored dependencies and binaries are excluded from the count, so bloat doesn't help.
Thin history
One contributor and a few commits gives a buyer less to learn from, however clean the code. Still submitted, still presented, just worth less.
Third-party weight
A repo that is mostly someone else's open source is someone else's code.
How grading works
We classify each repository by what it is, score the dimensions that apply to that kind of code, weight them, and produce a 0–100 score and a letter grade. Dimensions that don't apply are dropped entirely, never scored zero, so a Terraform repo is never marked down for having no unit tests, and a data pipeline isn't judged on UI.
Grades
| Grade | Score | What it means |
|---|---|---|
| A | 85–100 | Exemplary: code you would hold up as a model. |
| B | 70–84 | Strong. Goes out as submitted, and reads well to a lab. |
| C | 55–69 | Solid. Goes out too; the upgrade pass usually lifts it first. |
| D | 40–54 | Thin as submitted. Goes through the upgrade pass, then out with everything else. |
| F | below 40 | A long way down, and still worth submitting. Upgraded automatically, then shopped. |
What we look for, and what lifts it
| Dimension | What we look for | What lifts it |
|---|---|---|
| Architecture & Robustness | Clear layering, deliberate error handling, validated input, config injected not hardcoded. | Business logic separated from I/O and HTTP, input validated at boundaries, and errors handled deliberately rather than swallowed. |
| Test Coverage | Real tests over real behaviour, run in CI, not snapshots or assertion-free stubs. | A test runner covering the core logic with real assertions, wired into CI. Roughly one test file per ten source files is a healthy shape. |
| Docs & Onboarding | A README a new engineer can clone and run from today. | A README covering install, run, test, config and architecture, with a .env.example and a Dockerfile so setup is reproducible. |
| Security Hygiene | No committed secrets, validated input, parameterised queries, authorization enforced per route. | No secrets in the repo, a dependency audit in CI, and authorization enforced on every sensitive route. |
| Code Cleanliness | Consistent style, no dead code or duplication, a linter & formatter enforced in CI. | A linter and formatter enforced in CI, no dead or commented-out code, and files kept below roughly 500 lines. |
| History & Maintenance | Conventional commits, tagged releases, an active repo, more than one real contributor. | Meaningful commit messages, tagged releases, and a repository that shows real activity over time. |
| Dependency Health | A committed lockfile, lean dependencies, a clean dev/prod split, automated updates. | A committed lockfile, a lean dependency count, and dependencies kept current. |
| CI/CD Maturity | CI on every pull request running lint, type-check and tests, plus deploy automation. | CI running lint, type-check and tests on every pull request. |
Extra dimensions, by repo type
Scored only for the kind of repository they fit, never applied to others.
| Dimension | What we look for | What lifts it |
|---|---|---|
| Experiment Reproducibility ML / AI Research | Pinned seeds, tracked experiments, results reproducible from committed analysis. | Pinned seeds and dependency versions, tracked runs (W&B / MLflow), and the analysis behind each result committed. |
| Pipeline & Data Quality Data Engineering | Declared schemas, data validation, idempotent and retryable steps. | Declared schemas, validated data, and pipeline steps that are idempotent and safe to retry. |
| IaC Quality Infra | Pinned providers, remote state, fmt/validate and policy scanning in CI. | Pinned provider versions, a remote state backend, and fmt/validate plus policy scanning (tfsec / checkov) in CI. |
| Secrets & Threat Modeling Security | Secrets in a manager, a SECURITY.md, a documented threat model, least privilege. | Secrets held in a manager (Vault / SOPS / KMS), a SECURITY.md, and a documented threat model. |
Falling short is not a rejection
You don't have to lift a repository yourself, and a low grade doesn't take a repo off the table. Where one grades below B, our partner runs a pass over its own working copy and adds what's missing before it goes out.
How long each stage takes.
An estimate is instant: you can run the counter from your own terminal, or see one per repo the moment you connect Git. Grading is the slower part, and our partner does all of it. After that the labs move on their own schedule, and they are opaque with our partner too, so your dashboard is the honest view of where a repo sits.
What this means in practice
Submit what you own and leave the rest. You get a value straight away, the grade follows and tells you and the buyer what's there, and anything below the bar is lifted on our partner's side before it goes out. There's no fix list to work through and no engineering time to budget for. The only work on your side is choosing which repositories to include.
Where your code goes, and doesn't.
How our partner handles a codebase you submit for licensing: where it goes, who can see it, what is and isn't done with it, and how it's removed. This sits on top of the protections in your signed agreement: mutual confidentiality, no competing use, and return or destruction on request.
Scrubbed before anything leaves
Secrets, credentials and personal detail are stripped from the code and the full git history, and contributor identities pseudonymised. Nothing reaches a lab until that pass has run and been verified.
Your code is never run to grade it
Grading installs nothing, builds nothing and runs nothing. The one exception is the upgrade pass on a below-bar repo, which runs our partner's own copy in an isolated sandbox, never your original.
Graded on our partner's own infrastructure
A model reads the code to score it against a fixed rubric. It runs on our partner's infrastructure, under a commercial agreement with the AI provider, who does not train on what's sent.
In transit and at rest
Code is transferred over TLS (encrypted in transit) when you connect a provider, and stored encrypted at rest on every system that holds it. Connections to your Git provider use a token scoped to only the repositories you select; nothing else in your account is accessed.
Who can access it
In practice, submitted code is accessed by our partner's internal team, through an internal review tool. Buyers are shown code only after a deal, and only under a confidentiality obligation or licence. The existence and terms of your relationship with our partner are not disclosed publicly without your consent.
The agreement draws the circle slightly wider than the internal team, and it's worth knowing where it lands. Beyond staff and contractors with a need to know, §3.3 permits disclosure to our partner's affiliates and sublicensees; to financing sources and potential acquirers or investors in connection with a corporate transaction; to platform and infrastructure providers; to bona fide prospective buyers, limited to the minimum reasonably necessary and only once they are under a written confidentiality obligation or licence; and to data rooms, repository access tools and secure file-sharing providers, solely to provide those services. In every case they must be bound by confidentiality obligations at least as protective as your own. §3.7 also lets either side's people use general ideas, concepts and know-how retained in their unaided memory, which does not extend to reproducing source code or documentation.
How your code is used
Valuation runs on git metadata and static file analysis. Grading goes further: a model reads the code to score it against a fixed rubric, so the assessment reflects what's actually there rather than what the file names suggest. That runs on our partner's own infrastructure, and the AI provider operates under a commercial agreement and does not train on the data sent to it. Before any of that reaches a lab, the scrubbing pass has already stripped secrets, credentials and personal detail from the code and the full git history and pseudonymised contributor identities.
Grading never installs, builds or executes your code. The one exception is the upgrade pass on a repository that grades below the bar, where our partner installs and runs its own working copy in an isolated sandbox to check that the tests it added actually exercise the code. It may add development dependencies, such as a test runner, so the suite installs from your manifest. It never changes what your application does, never rewrites, renames or deletes your code, and never writes to your Git provider. Your original is kept exactly as it arrived alongside the improved copy, you're emailed the full list of what was added and anything found that only you can fix, and our partner will remove the whole pass if you'd rather it hadn't run.
Retention and deletion
Repositories you don't select are never copied. For a repo you do submit, one encrypted copy is kept so it can be valued, re-graded, and offered to buyers over time. Because a codebase can be licensed to more than one buyer, accepted submissions stay in the pipeline while they're listed. Temporary working copies created during analysis are wiped after each run.
You stay in control the entire time. You can hard-delete any codebase yourself, in the product, at any point before it's licensed; it removes the stored copy and is fail-closed, so if it can't be deleted the removal is refused and you're told, rather than a deletion being reported that didn't happen. Contractually you can also withdraw a codebase from future listing on 30 days' notice, and on written request our partner returns or destroys your codebase and the copies it holds, excepting what it must keep by law, what sits in routine archival or backup, what it needs to administer buyer licences already granted, and anything it has licensed or acquired under §6.5. What can't be unwound either way is a deal that has already closed.
Subprocessors
A small set of established infrastructure providers, each under their standard data-processing terms.
| Purpose | Provider |
|---|---|
| Source connection (repos you select) | GitHub, GitLab, Bitbucket |
| Compute / processing | Render |
| Encrypted storage | Amazon Web Services (S3), Cloudflare (R2) |
| Database (metadata) | MongoDB Atlas |
| AI grading and classification (under commercial terms, no training on the data) | Anthropic (OpenAI as failover) |
Legal backing
- Mutual confidentiality, with obligations running five years (longer for trade secrets), and written notice within 72 hours of any unauthorised access or disclosure.
- Non-exclusive licence to market and sell; any buyer is bound by confidentiality or licence before seeing code.
- Return or destruction of materials on written request, excepting what our partner must keep by law, holds in routine backup, needs to administer buyer licences already granted, or has licensed or acquired under §6.5.
Turning dormant code into revenue.
Everything your referrals could ask, answered.
The opportunity
What is this?+
Frontier AI labs are paying real money for real-world codebases to train their coding models. Pangea.ai works with a specialist partner, who handle valuation, legal, and the sale end to end, so agencies in our network can turn dormant code into revenue. You're paid for every codebase that sells, at no cost to you.
Why is old code suddenly worth money?+
Frontier AI labs train and evaluate their coding models against genuine production code: the source and the git history behind it, how features were built, how bugs were fixed, how a project evolved over time. That kind of verified, real-world code is what's in short supply, and demand for it is high right now. The projects your agency has already delivered are exactly that, and because the history carries value too, you're paid for it, not just the final source.
Who's the buyer?+
Frontier AI labs and similar data buyers, all under confidentiality. Our partner packages and sells to them, so you never deal with the buyer directly, and specific buyers aren't disclosed.
What can a buyer do with the code?+
Buyers license codebases to train, fine-tune, evaluate and benchmark their coding models, and to research and improve those models and the systems around them. They can modify the code and create derivative works for that work.
Our partner sets the terms of each buyer licence and negotiates them per deal (§6.3, §7.1), so the precise scope of any one licence is a commercial matter between our partner and that buyer, and its terms are confidential. Worth knowing: once a deal has closed, a buyer licence is perpetual and irrevocable on its own terms, and it isn't something you can revoke or unwind afterwards (§6.1, §7.3). Your warranties are passed through to buyers in substance, and they rely on them (§7.2).
How it works
What happens once we have a repo to sell?+
You sign the agreement, connect GitHub, GitLab, or Bitbucket, and select the private repos you want assessed. Our partner checks, values, and grades each one. Every repo is then presented to the labs it fits, whatever it scored; anything below B goes through the upgrade pass first. If a lab makes an offer, our partner concludes it on your behalf under the standing authorisation in §13.3, at the standing rates, and notifies you that your codebase is in a deal. The lab then raises a PO, typically on 60-day payment terms, and you're paid on Net 15 once the funds reach our partner.
What happens once a repo is graded?+
It goes out to the labs, and you don’t have to do anything to push it. A repo goes out whatever it scored: a higher grade makes it more desirable, it isn’t a threshold to clear. Where a repo grades below B, the upgrade pass runs over our partner’s copy first and it’s re-graded before going out.
In the dashboard, you’ll see a status of “in data review” next to a repo. That means a buyer is looking at that repo’s metadata (token counts, size, descriptions — never the code) to decide whether to license it.
The honest caveat: a good grade doesn’t put a repo into data review automatically or immediately. That depends on buyer demand, and what each lab wants shifts month to month. A buyer picking a repo up is a separate step, and we don’t control the timing.
What you're signing
What is the agreement?+
A single agreement covering two things: (1) confidentiality between you and our partner, and (2) a non-exclusive licence for our partner to access, package, market, license and sell your codebases to buyers. You sign once; our partner has already countersigned. It's governed by Delaware law, with any dispute heard in the Delaware courts.
Your signature is also your standing authorisation for each individual non-exclusive buyer licence our partner grants (§13.3), so no per-deal signature is needed. Two things do need your separate written agreement: an exclusive licence to one buyer, and any deal that would restrict the rights you keep under §6.2 (§13.4).
You can read the whole thing before you sign: download the redacted Codebase Agreement (PDF). It is the same document the signing page shows.
Do we keep ownership of our code?+
Yes. You keep ownership, keep using the code, and keep shipping it to clients. You grant our partner a non-exclusive licence to access, package, market, license and sell the codebase to buyers, and you keep ownership of the code itself throughout (§6.2, §6.4). The licence is irrevocable while the agreement runs, and the one way to take a codebase off the table for future deals is the withdrawal right in §10.2 (see "Can we change our mind or pull a codebase?").
Two things sit outside that. If our partner acquires a codebase for its own account, or takes a licence to it for its own use, the position changes. See "Licence vs. buyout" below.
Is the licence exclusive?+
No. The licence you grant our partner is non-exclusive (§6.1), and §6.2 preserves your right to license, sell or transfer the codebase as a standalone asset yourself. In practice most agencies route everything through our partner, since that's where the buyer relationships and the packaging work sit.
There is one limit worth knowing. Under §11 you can't go around our partner to close a deal with a buyer our partner introduced you to, during the agreement or for twelve months after it ends, unless you can show you were already in documented discussions with that buyer beforehand. If you do, our partner is owed the full payment it would have earned. Buyers you found yourself are unaffected.
Can we keep using the code ourselves?+
Yes. You keep the right to use, modify, and operate the codebase internally, and to keep using, maintaining, supporting, and deploying it for your existing and ongoing client engagements (§6.2). Nothing in the licence touches your own use of the code.
One thing to be aware of on our partner's side: to market and deliver a codebase, our partner may refine, correct, annotate and modify its own copy, and prepare packaged, redacted or white-labelled versions for sale (§6.1(a), §8). Your repositories are never written to; that work happens on our partner's copy.
What happens to the agreement if our company is acquired or changes control?+
The agreement already covers it. Under §12.2 you can assign the agreement to a successor in a merger, acquisition, or sale of substantially all assets, without our partner's consent; §10.1 then lets that successor terminate on 30 days' notice. So an acquirer can exit, and inherits nothing it can't walk away from. (our partner can assign the agreement without your consent, and can sublicense and use subcontractors to exercise its rights.)
The licence travels with the agreement on a change of control, and ends whenever the successor chooses to terminate, on the same 30 days that applies to both sides. Two things survive that regardless: any buyer licence already granted, and anything our partner has licensed or acquired for its own account under §6.5.
On buyer licences specifically: one already granted survives on its own terms in every scenario, change of control or not. Where a buyer has licensed a codebase to train a model, that model is theirs. A deal already in the pipeline at the moment of the change of control can also still complete, and you're paid on it (§10.3).
What are we on the hook for if something goes wrong?+
Your side of the bargain is the ownership warranties, and they carry real weight, so it's worth reading §5 and §9 before you sign rather than after.
§5 asks you to warrant eight things about each codebase you submit: that you own it or hold sufficient rights to license it; that every founder, employee and contractor who touched it has assigned their IP to you; that no client or third party holds a conflicting right or is owed payment on a sale; that no third-party consent is needed; that it complies with its open-source and third-party licence terms, with no undisclosed copyleft or source-disclosure obligation; that it contains no malware; that it contains no personal data, third-party trade secrets, credentials or API keys except as disclosed; and that neither you nor it is caught by export controls or sanctions. Those warranties are treated as re-made every time one of your codebases goes into a deal (§13.9), you have a continuing duty to tell our partner promptly if any of them stops being accurate, and on reasonable request you'll provide redacted supporting documents (IP assignments, asset purchase agreements, prior licences) to evidence chain of title.
If a warranty turns out to be wrong, you indemnify our partner and, where warranties were passed through, its buyers, for the resulting claims and costs. On an infringement claim you'd be asked, at our partner's option and your expense, to secure the rights, replace or modify the affected code, or accept its removal and refund payments already received on affected licences (§9.3).
The asymmetry is worth naming. Your indemnity under §9.1 is not capped. Our partner's liability to you is: consequential and indirect losses are excluded, and its total liability is limited to what it actually paid you in the twelve months before the claim (§9.4). The platform, and every valuation, grade, score, token count and estimate on it, is provided as is (§9.5).
In practice this is why the guidance throughout is to submit only code you fully own, disclose your open-source position honestly, and flag anything client-owned or jointly owned early. The warranties are the part of this agreement with teeth.
Licence vs. buyout
What could a deal look like in practice?+
There are four:
- Non-exclusive licences (the usual model). our partner licenses your codebase to buyers non-exclusively, so the same repo can be licensed to more than one lab and you're paid each time, recurring, not one-off. These need no further signature from you: our partner negotiates and signs as principal under the authorisation in §13.3.
- Exclusive licence. One lab pays a premium for exclusivity on that codebase. This one does need your separate signed confirmation, and so does any deal that would cut into the rights you keep under §6.2 (§13.4).
- Our partner takes a licence for its own use (§6.5(a)). Distinct from the above, and worth reading properly. Our partner can take a perpetual non-exclusive licence to a codebase for its own account, by giving you notice and paying at the standing rates in force on the date of that notice, and it doesn't need your consent to do it. It can then build the code into its own products, services and datasets, use it to train and evaluate its own models, and create and commercialise derived data as its own property, with no further payment to you. That payment is full and final for those rights, and they survive termination of the agreement.
- Buyout, or exclusive acquisition (§6.5(b)). our partner may offer to acquire a codebase outright, or take an exclusive licence to it, for a one-time payment negotiated in good faith. This one is entirely your call: it only happens at an amount you agree in writing. There's no further revenue share on that codebase afterwards, and you'd sign a short confirmation of the assignment so our partner can evidence chain of title.
The dividing line: for standard non-exclusive deals, our partner handles and concludes the commercial terms on your behalf without coming back to you. For an exclusive deal or an outright acquisition, nothing happens without your signature.
How often does a repo get licensed?+
It's still too early to give a reliable average; it depends on the quality, size, domain, history, and buyer demand for a codebase. The standard model is non-exclusive, so the same repo can be licensed to multiple labs and paid for several times. Labs occasionally want exclusivity on a codebase, which pays a premium; you keep ownership either way.
Each sale is a licence fee for that licence, not an ongoing royalty on how the buyer uses the code afterwards. You're paid again when the repo is licensed again, not per use.
What qualifies
What kind of code qualifies, and which repos should we submit?+
Anything dormant or deprecated that you own: projects that have wound down, been rebuilt from scratch, or are simply sitting unused. Commit history, tickets, and documentation all add value.
In practice that means dormant client work you fully own, internal tools, and projects you rebuilt and left behind. Team-built repos with real history (multiple contributors, pull requests, tests) are worth the most. Skip client-owned IP, forks, and single-file scripts.
Not sure about a repo? Submit it. Grading is free and private, and nothing enters the pipeline unless you submit it. Choosing what to submit is where your control sits.
What do we need to disclose about each repo?+
Two things, and both have a dedicated field in the submission flow: (1) any open-source or third-party components, especially copyleft (GPL/AGPL/LGPL), which buyers warrant hard against; and (2) whether the repo has ever been public. That one is an eligibility check rather than a pricing input: buyers pay specifically for code that isn't already in a public training set, so a repo that is or was public can't be licensed, and flagging it early saves you submitting something that will be declined. Type or paste these in, or attach an SBOM. This gates listing, not signing; you can sign first and fill it in as you connect repos.
Do we need to own the IP?+
Yes. Only submit code you fully own, with no client claim, NDA restriction, or contributor owed payment on it. You pick exactly which repos are included, and the ownership warranties you make are set out in §5 of your agreement: eight of them, re-made each time a codebase goes into a deal, and backed by an uncapped indemnity. See "What are we on the hook for if something goes wrong?" above before you submit.
Do we need to clean a repo before submitting it?+
No. Our partner does it for you. Every secret, credential and personal detail is scrubbed from the code and the full git history, contributor identities are pseudonymised, and nothing reaches a lab until that pass has run and been verified.
So submit what you own as it is. The source is what's valued, and stripping code out yourself only lowers the number.
One thing to keep in mind: §5 of the agreement still asks you to warrant that a codebase contains no personal data, third-party trade secrets, credentials or API keys except as expressly disclosed. The scrubbing pass is our partner's process, not a substitute for that warranty, so if you know something sensitive is in there, disclose it rather than relying on the pass to catch it.
Do you accept repos that have been public?+
No, and this is the one hard disqualifier. Buyers pay specifically for code that isn't already in a public training set, so a repository that is public today is an automatic decline, and so is one that was public at any point in the past, even if it's private now. An Internet Archive crawl of the repo page proves it was public on that date, and making it private afterwards doesn't undo that.
Forks of someone else's project and code already shipped as a package (npm, PyPI or similar) are out for the same reason. Everything else you own and kept private is fair game. See the Eligibility tab for the full list and how each one is checked.
What if a repo grades below the bar?+
Falling short isn't a rejection, and you don't have to fix it yourself. Our partner runs an automatic pass over its own working copy and adds what's missing: a README, CI, a Dockerfile, an environment example, tests.
The upgraded copy is then installed and run in an isolated sandbox to prove those tests. Anything that fails, or passes without exercising your code, is discarded. Your original is kept exactly as it arrived, your repositories are never written to, and you're emailed the full list of what was added, plus anything found that only you can fix. If you'd rather the additions weren't there, the whole pass comes off on request.
Does it matter if our git history is squashed?+
Yes, and it costs real money. History is priced in full and often carries the larger half of the value, so a squashed, shallow or freshly re-initialised copy throws those tokens away. Submit the original repository, not an export of it.
Can we get a number before connecting anything?+
Yes. There's a downloadable estimator you can run against any repository on your own machine, before you connect a provider or sign anything. It's the same counter the pipeline uses, and nothing leaves your machine. The command is on the How We Grade tab.
It prices at the standing rates and prints an estimate, not an offer. Pass several repos, or a folder of them, for a row per repo and a total; it also prints the counting rule and the text it left out under each one, so a small number explains itself. The pipeline computes the same numbers once you submit.
Which Git providers are supported?+
GitHub, GitLab, and Bitbucket; you can connect more than one.
How much access do we have to give?+
As little as you want to give, and read-only. You choose which repositories: connecting GitHub installs our partner's app on the repos you select, with permission to read code and nothing else. You can change that list, or remove our partner entirely, from your GitHub settings at any time.
Our partner copies what you submit so it can be scrubbed, valued and graded, reads the code and history to package it, and never writes to your repositories. Nothing you don't select is touched. The same applies on GitLab and Bitbucket: access is scoped to the repos you pick, and revocable at your provider any time.
One thing to be clear about: revoking stops future access, but it doesn't pull back copies already taken or licences already granted. Removing a codebase in the product before it's licensed, or the withdrawal right in §10.2, is what covers those.
How long does it take to set up?+
A few minutes to connect and see estimates. You can submit several repos at once and add more any time.
How long until we actually see money?+
Set expectations in weeks, not days. Scrubbing and grading takes hours for a small repo, up to 2–4 weeks for a large history or a busy queue, and our partner does all of it. A graded repo then goes out to the labs in batches, 2 to 16 weeks from when it's ready. Labs take 4 to 12 weeks to decide, and they're opaque with our partner too.
From there it depends on buyer demand; our partner sets pricing and only sells when there's a fit, so there's no guaranteed timeline. Once a deal lands, the lab raises a PO on roughly 60-day terms and you're paid Net 15 after the funds clear. Your dashboard moves the moment there's news, and we'll keep you posted on status.
What if a repo is rejected?+
First, a low grade isn't a rejection and doesn't stop a repo going out: a repo below the bar goes through our partner's upgrade pass and is then shopped like any other. An outright decline is a different thing, and it's almost always about rights or provenance: a repo that is or was public, a fork, code already shipped as a package, or third-party and client-owned code. A decline never affects your other submissions, and where reasonable our partner explains the reason.
Two things to be straight about. Our partner is under no obligation to accept, list, market or sell any codebase, and can decline, defer, remove or discontinue one at its own discretion (§4, §13.10). There's no minimum number of deals, no minimum revenue and no guaranteed listing period. It can also suspend or remove a codebase immediately where it reasonably judges there's an infringement, malware, undisclosed personal data or credentials, a legal, security or reputational risk, or a third-party claim; you get prompt notice and, where practicable, a chance to fix it.
Who handles the legal?+
Our partner. The NDA and licence are one combined agreement, already countersigned; you sign once, and can download your copy any time.
You can also read it in full before you sign anything, and share it with whoever needs to review it. The signing page shows the same document, and your signed copy sits on that page afterwards.
Can several people from our team take part?+
Yes. Your team joins under one organization, everyone connects their own Git accounts, and repos and payouts roll up in one place. No duplicate accounts needed. Each person still chooses the repositories they submit.
How do you decide which repos get acquired?+
Each repo is assessed across the same eight dimensions used throughout: architecture and robustness, test coverage, docs and onboarding, security hygiene, code cleanliness, history and maintenance, dependency health, and CI/CD maturity, then given a score from 0 to 100 and a letter grade. The grade decides how desirable a repo looks to a lab, not whether it goes out. A repo is never built or run to be graded, though a model does read the code to score it.
Valuation counts genuine source code at the current head plus useful code in the git history. Markup, data, config and docs count up to 10× the code beside them; beyond that line a row is flagged and may be priced in full, so the count only rises from there. Generated files, vendored dependencies, build folders, binaries, images, archives, and other third-party or non-code files aren't counted as source, so padding a repo doesn't lift its number.
How are multiple branches or contributors handled?+
The whole repo is assessed as one codebase, including its genuine source and full git history. If several people contributed to the same project, their combined work and history are assessed together. Team-built projects are generally more attractive to labs than solo ones, because they carry richer collaboration signals: multiple contributors, pull requests, reviews, bug fixes, and a more meaningful development history. Individual repos can still be submitted, but genuine team projects are more likely to attract buyer interest. If important code lives only on separate, unmerged branches, confirm with your Pangea.ai contact how those branches will be handled before submitting.
Control & security
What gets shared, and who sees our code?+
Only the repos you choose. Repos you don't pick are never copied, and you can revoke access at your provider any time.
What you do submit is seen by our partner's internal review team, and by prospective buyers and buyers under written confidentiality obligations. The agreement also permits disclosure to a defined set of others: affiliates and sublicensees, infrastructure and data-room providers, financing sources in a corporate transaction, and vetted prospective buyers, each bound by confidentiality at least as protective as your own. The Code Handling & Security tab sets out the full list.
Is our code kept confidential?+
Yes. Both sides are under mutual confidentiality; access is limited to people with a need to know who are bound by equivalent terms, and our partner won't expose your code publicly except as needed to market or deliver it to a buyer under confidentiality or licence. Confidentiality obligations run for five years from disclosure (longer for trade secrets, which stay protected as long as they remain trade secrets). If either side becomes aware of unauthorised access or disclosure, it must notify the other in writing within 72 hours and cooperate on investigating and remediating it.
Could our code be traced back to us?+
The existence and terms of the relationship aren't disclosed publicly without your consent, and any buyer is bound by a confidentiality obligation or licence before seeing the code. The scrubbing pass also pseudonymises contributor identities across the code and the git history, so the commit trail doesn't carry your team's names to a lab.
Can we change our mind or pull a codebase?+
Yes, on two levels. In the product, you can remove any codebase yourself, at any point before it's licensed; it hard-deletes the stored copy, with no notice needed. Contractually, §10.2 gives you a withdrawal right on 30 days' written notice, and either party can end the whole agreement on 30 days' notice (§10.1).
What withdrawal doesn't reach, so there are no surprises: a buyer licence already granted; an active, documented buyer transaction or negotiation already in progress when you give notice, or that starts during the 30 days (a "Pipeline Transaction"); our partner's right to keep administering licences already out there; and anything our partner has licensed or acquired for its own account under §6.5. For 90 days after termination or withdrawal (the "Tail Period"), our partner can still close those pipeline deals, and you're paid on them on the normal terms. During that window you agree not to approach the buyers involved directly (§10.3).
On written request, our partner returns or destroys your codebase and related confidential information. That's subject to what it must keep by law, what sits in routine archival or backup, what it needs to honour buyer licences already granted, and anything under §6.5, all of which stays covered by the confidentiality terms (§10.5).
How do you stop someone simply extracting the code?+
To be straight about what grading involves: a model does read the code to score it against a fixed rubric. That runs on our partner's own infrastructure, and the AI provider is under a commercial agreement and does not train on the data sent to it. The code is never installed, built or executed to grade it. The one exception is the upgrade pass on a below-bar repo, where our partner installs and runs its own working copy in an isolated sandbox to prove the tests it added; your original is never written to, and the whole pass can be removed on request.
Around that: secrets, credentials and personal detail are scrubbed from the code and the full git history and contributor identities pseudonymised before anything reaches a lab. Connections are limited to the repos you select and are read-only, code is encrypted in transit and at rest, and access on our partner's side runs through an internal review tool. Buyers receive code only after a deal, and under the confidentiality and licence terms our partner agrees with them.
Can we keep the arrangement private, even if we sell the company later?+
Yes, it can stay completely non-public. The relationship, your identity as the code owner, and the commercial terms aren't disclosed publicly, and buyers are bound by confidentiality before they receive any code. You keep ownership under a standard licence and can carry on using, modifying, and deploying the code. If the codebase or the company behind it is later sold, existing licences may need to be disclosed privately during legal due diligence, but they never have to be announced publicly.
Payment & reporting
How is the amount set, and what commits our partner to it?+
The rates are written into the agreement itself. §13.2 sets standing rates of $100 per million source tokens and $40 per million git-history tokens, and states that's the basis on which our partner expects to pay for a standard non-exclusive licence. Our partner can change them on 30 days' notice, and a change never affects a licence already granted; a deal is paid at the rate in force when it was granted.
Two honest caveats. The standing rates are not a fixed price, a minimum, or a guarantee for any particular deal: where a transaction's terms differ from a standard non-exclusive licence, our partner may set a different amount, acting reasonably and in good faith, and will tell you that amount at or before payment. And the token count the rate is applied to is determined by our partner's own analysis (§4), which decides what's counted and what's excluded.
There is no per-deal sign-off on a standard licence. Your signature on the agreement is standing authorisation for each non-exclusive buyer licence our partner grants (§13.3); you're notified on the platform or by email when one of your codebases is included in a deal (§13.9). A separate signed confirmation is required only for an exclusive licence, a deal that would restrict the rights you keep under §6.2, or (at our partner's option) a deal priced off the standing rates (§13.4). Your control over whether a codebase is offered at all is the withdrawal right in §10.2.
Payment is owed once a deal closes: the buyer licence is signed and our partner has the first cleared, non-refundable funds in hand (§13.5). It's paid out of what our partner actually receives for that deal and never more than that. If a buyer's payment is later refunded, charged back or clawed back, our partner can recover the proportionate amount from future payments, and it can net off anything you owe it under the agreement.
What does it cost?+
Nothing. Connecting and grading are free, there's no obligation to submit anything, and the rates above are your side, not a gross figure someone takes a cut of. Pangea.ai is compensated separately by our partner, so nothing is deducted from your side.
When and how do we get paid?+
You're paid on Net 15 terms: within 15 days of our partner receiving payment from the buyer. Labs typically raise a PO on around 60-day terms, so that's the wait before funds reach our partner; once they do, your Net 15 clock starts. Where a buyer pays in instalments, a proportionate part of your payment accrues as each one lands. Payout details go in your dashboard, and you're paid in US dollars by ACH or wire to the account you designate and verify there.
Two practical conditions. Our partner needs your tax documentation on file (a W-9, or a W-8BEN / W-8BEN-E if you're outside the US) along with a verified payout account, and can hold payment until both are in place (§13.7). Where law requires tax to be withheld, it's withheld and remitted, and you get the form showing it. Receiving-bank and currency-conversion charges are yours. Otherwise nothing is deducted: it's paid to your business as income.
How do we set up our payout details?+
When a repo or set of repos reaches the final stage of being licensed, our partner asks for the banking details it needs to process the payment. You don't have to have them in place before that.
Payments are handled through Mercury. You'll get an invite from hello@mercury.com asking for your banking details and your tax form. You can also do it yourself at any point without waiting for the email: open Payout details in your dashboard and it takes you through to Mercury.
Both routes end up in the same place, so if you'd rather not act on an emailed link, go in through the dashboard.
What reporting do we get?+
Your dashboard carries a record for every buyer licence covering one of your codebases: the codebases included, the licence type, the amount you're paid, and the date paid (§13.8), plus funnel status and your total earned.
Two things are outside it. The buyer's identity and the terms of their licence are confidential, and you're not entitled to an accounting of what our partner received from the buyer, so the record shows your payment, not the deal's economics. Where a single deal covers codebases from more than one owner, or is priced as one figure across several codebases, the consideration is split across them in proportion to their total token counts (§13.5).