How to Monetize a VS Code Extension: Licences, Fees and Pricing

How to monetize a VS Code extension, in short: keep a useful free version on the Visual Studio Marketplace, sell a paid tier, a hosted service or team seats on your own site through a payment provider, and have the extension check a licence key or a signed-in account. The Marketplace will not take the money for you. Its publisher agreement says all fees must be "billed and collected outside of the Marketplace", so the real decisions are what to charge for, who handles tax, and how much licence checking is worth.

Disclosure: ZeroRaised publishes this guide and appears in the final section. Terms, fees and plans come from Microsoft, the Eclipse Foundation and each vendor's own pages as checked on 21 Oct 2026. Prices change, so check the live page before you pay. ZeroRaised has no affiliate deal with any provider or extension named here, and this guide makes no promise of installs, sales or revenue.

TL;DR#

There is no in-Marketplace purchase. The VS Code publishing guide gives you a pricing label (Free or Trial) and a sponsor link. Checkout, receipts, refunds, sales tax and licence keys all happen somewhere else.

The gap shows up in recent launches. On 20 October 2026 a maker posted a Show HN for BodyCommit, an extension with Free and Pro tiers already built and a listing that says "There is no checkout." This guide is the missing half: where the money goes, and how the extension knows who paid.

Publishing mechanics are in how to publish a VS Code extension; this guide is about earning from it.

What happened: a Free and Pro extension with no checkout, 20 October 2026#

Hacker News user triandyg posted Show HN: BodyCommit, movement breaks in VS Code while your agent works (title lightly edited). The item page shows a relative age; the HN item API gives 20 October 2026 at 15:47:38 UTC, which is 16:47 BST. It had 1 point and no discussion when checked on 21 Oct 2026, so it says nothing about what the market will pay. It is here because it shows, in public, where many extension makers get stuck.

The BodyCommit Marketplace listing describes a "Free and Pro scaffold". Free "includes two routines in each category"; Pro adds the full library and custom programs. Then: "There is no checkout." To try Pro, you set bodycommit.licenseKey to a fixed test key that works "on this machine only". The pricing label reads Free, and the Marketplace's own data shows version 0.3.2 first published on 17 October 2026.

The product half of freemium is done: a free and paid split, and a setting for a key. Missing are a place to pay, a key nobody can guess, a check that cannot be bypassed with one setting, and a price.

A bigger extension moved its paywall the same week. The GitLens v19.4.0 release, published on 15 October 2026, stopped requiring an account for the Commit Graph "on public and local repos", gave private repos "one continuous 3-day window" of preview, and made a conflicts check one that "now requires a trial or Pro subscription". GitLens comes from GitKraken, a company, but the lesson carries: you will keep moving the free and paid line, and that is easier when the check lives on your server.

What the Visual Studio Marketplace does and does not do for paid extensions#

The Marketplace is a listing and a download, not a shop. Our Visual Studio Marketplace launch page covers cost, link type and review; this section is only about money.

Two money fields in package.json#

The VS Code publishing guide offers a pricing label "to indicate that it is Free or Free Trial". It says "Allowed values are: Free and Trial (case-sensitive)", Free is the default, and you need vsce 2.10.0 or later. The extension manifest reference lists the same two values. There is no Paid value and no price field.

The label is a hint, not a billing setting. The Thunder Client listing shows Free Trial; BodyCommit shows Free despite its Pro tier. If the extension stops working after a trial, Trial is clearer.

The second field is a sponsor link: "You can opt-in to sponsorship to give your users a way to support your work." With vsce 2.9.1 or later, the guide says the link appears on your Marketplace page and in the extension details header in VS Code.

No checkout, no in-app purchase API, no payout.

What the publisher agreement says about charging#

The Visual Studio Marketplace Publisher Agreement (the PDF shows "EFFECTIVE DATE: JUNE 2021") is what you accept when you publish. The parts that matter:

• Billing is yours. Section 7(a): "You are solely responsible for providing Customers with pricing information and for charging or invoicing Customers".
• So are refunds and tax. Section 7(b) covers "returns, and chargebacks of your Offering", and 7(c) says "Microsoft is not responsible for collecting and remitting telecommunications taxes or any similar taxes".
• Licence keys are a recognised model. A "Bring-Your-Own-License (BYOL) Offering" is one "for which Customers have obtained, outside of the Marketplace, the right to access or use the Offering."
• Disclose paid features. Listing information "may include your full contact information and information about in-Offering purchases available in an Offering", and notices must be "sufficiently prominent as is required by local law."
• Support paid users. "You are responsible for supporting your Offerings that are paid-for and fully available".
• Give notice before pulling a paid extension. You must give "thirty (30) days' notice before removing a paid Offering", and existing customers "will be able to continue to use the Offering to the same extent as prior to the removal."
• Microsoft can still remove you "for any reason or no reason and at any time."

In practice: put the price and what is paid near the top of the listing, and remember that billing, refunds and tax sit with you, so your checkout provider's terms and your refund policy are what customers rely on. Publisher setup and the 1 December 2026 token change are in Microsoft's publishing guide.

Open VSX: the same rule, and a licence trap#

Open VSX is a second registry, hosted at the Eclipse Foundation, and for charging it works like the Marketplace. The Open VSX FAQ says "There are no fees associated with publishing or consuming content from the Open VSX Registry." The Open VSX Publisher Agreement (Version 1.1, September 2025) says payment is "collected directly between you and such licensee or end-user and shall not be identified, processed, executed or in any way facilitated through the Registry or by Eclipse."

Three licence points matter if you charge:

1. A licence is required, but not an open source one. The FAQ says "Yes, all extensions must be licensed", and "No, you may use a license that is not recognized as an open source license by the Open Source Initiative".
2. The published licence can differ from the repository's. "You can have one license for your source code, e.g. in your GitHub repository, and a different license specified in your package.json manifest for publishing."
3. Forget it and you get MIT. If you do not specify a licence, the agreement says the offering "will be made available under the MIT license". Set the license field on purpose.

BodyCommit's VSIX installs "in VS Code, Cursor, and any editor that accepts Open VSX packages". Your licence check should work the same whichever registry the user came from, so tie it to your own server or accounts.

How to monetize a VS Code extension: six models that work#

Every model answers one question: what does a paying user get that a free user does not, and where is that enforced?

1. Freemium: a free core and a paid tier#

This is what BodyCommit has scaffolded and what Quokka and GitLens use. The free version must be good enough to keep; the paid tier adds depth for people who use it all day. Quokka.js draws the line inside a feature: Value Explorer is in both editions, but "in Community edition only 2 levels of the explorer's tree can be expanded."

Good splits share traits: the free tier solves a real problem alone, the paid line follows heavier use (more items, larger projects, team features), and the upgrade prompt appears where the limit is hit, not on every launch.

2. A paid hosted service behind the extension#

If the extension calls something you run, such as an AI model, sync or a hosted API, charge for that service. This is the hardest model to bypass, because the paid work happens on your server. It also matches your costs: a flat one-off price on an extension that sends requests to a paid model can lose money as it grows. Polar's licence keys support "Usage quotas per license key" for "OpenAI tokens or anything else with a variable usage cost".

The alternative is letting users bring their own model key, so their provider bills them. Your costs stay at zero, but so does the service you could sell.

3. Per-seat team licences#

Companies buy seats. Thunder Client's pricing shows Free at $0, then Starter at $3, Business at $7 and Enterprise at $16 "/ user / month", billed annually. Starter is an "Individual license (1 user)"; Business adds "Centralized billing" and "Payment by invoice". Quokka's Pro licences split the same way: Personal Pro "May not be purchased or reimbursed by companies", while Company Pro licences "are issued to the organisation. Each license may be used by one employee at a time."

4. Sponsorship#

Covered below. It suits open source extensions and is the only model with a built-in Marketplace field.

5. Paid support#

Some makers keep the extension free and sell time: priority fixes, setup help, a private channel. The publisher agreement already expects support for paid offerings, "included within the fees associated with the Offering, if any, or as a support offering that may be separately purchased". It caps out at your hours, so it works best as an add-on to team licences.

6. A channel for a product you already sell#

A free extension can pay its way through signups. GitLens ties into a GitKraken account; its v19.4.0 notes describe an integration that "connects through your GitKraken account like the other self-hosted integrations". For a small SaaS this can be a free extension that talks to your API, with a sign-in that creates an account. Your SaaS pricing does the rest; see how to price a SaaS product.

Licence checks: offline use, piracy and code people can read#

A VS Code extension runs on the user's machine, so the user has the code that performs your check. This is why BodyCommit's fixed test key is a placeholder rather than protection.

Where to keep the key, and how to check it#

Store keys and tokens in SecretStorage, not plain settings. The VS Code API reference says secrets "will be stored encrypted" and "will not be synced across machines", so expect users to enter a key once per machine. For sign-in instead of a key, the same reference lists two built-in authentication providers: "their providerId's are 'github' and 'microsoft'". Matching a GitHub account to a purchase on your server avoids copying keys around.

Merchants of record will issue and check keys for you. Lemon Squeezy lets you set a "License length" and an "Activation limit" per product. Polar supports "Limited number of user activations, e.g devices", and subscription keys "stay valid for as long as the subscription is active, and are revoked when it ends." Polar adds that "A revoked key fails validation", so check status rather than a date.

Offline use#

A check that fails closed when the network drops turns paying users into angry reviewers. Cache the last good validation, allow a grace period, then fall back to the free tier. For larger customers, offer activation without a connection: Thunder Client's pricing page lists "Offline Activation" and a "License Management API" among its Enterprise features.

Piracy#

Some people will patch the check. For a solo maker the sensible response is to accept it, make paying easy, and keep shipping updates people want. Quokka's terms are a fair middle ground: Pro licences "permit the perpetual use of the latest version of Quokka.js at the time of purchase, and all new versions released within 12 months of license purchase" (Quokka Pro). Renewing buys updates, not permission to keep working.

Open source code#

If the repository is public, so is your check. Three common answers: keep the free core open and put paid features in a closed module or on your server; publish under a licence that differs from the repository's, which Open VSX allows; or go fully open and earn through sponsorship, support or a hosted service. How to market an open source project covers the community side.

Payment providers and fees for a solo extension maker#

The big choice is whether to use a merchant of record: a company that is the legal seller, charges the customer, collects and pays sales tax and VAT, handles chargebacks and pays you the rest. Without one, you are the seller, and the publisher agreement's tax and refund clauses land on you. Lemon Squeezy's pricing page sums up the offer as "Global sales tax & compliance handled for you." The trade is a bigger cut per sale.

Reading the table:

• Percentages stack. Lemon Squeezy's fees page adds 1.5% outside the US and 0.5% for subscription payments, so a non-US subscriber costs more than the headline rate.
• Polar's paid plans are a volume bet. Its pricing page says Pro saves money above "~$1,379 /mo in sales". Below that, the free Starter plan is cheaper.
• Stripe alone is cheapest per sale and most work overall. You register for tax, file returns and handle disputes yourself. On Stripe's pricing page, the merchant of record option is Managed Payments, which includes "indirect tax compliance (sales tax, VAT, GST) and remittance in more than 75 countries".
• Things move. Lemon Squeezy's pricing page carries a banner reading "2026 Update: Lemon Squeezy + Stripe Managed Payments". Check a provider's current status before building your licence flow around it.

Payouts can cost extra too: for payouts via Stripe, Lemon Squeezy's fees page lists "1% per payout for bank accounts outside the US". The payout terms for nine providers in our US fees dataset show what each one publishes on schedules, minimums and payout fees. For one-off sales, refunds and the wider picture, see how to sell software online.

Sponsorships and donations#

The sponsor field is the one money feature the Marketplace builds in, so fill it even if you sell a paid tier. The publishing guide's own example points it at a GitHub Sponsors page.

GitHub Sponsors "does not charge any fees for sponsorships from personal accounts, so 100% of these sponsorships go to the sponsored developer or organization", and "charges a fee of up to 6% for sponsorships from organization accounts". If several maintainers want to share funds through a fiscal host, Open Source Collective "charges a fixed 10% host fee on incoming funds."

Sponsorship suits open source extensions where a paywall would invite a fork, and companies that depend on your tool and want an easy way to give back. It is not a predictable income: sponsors give when they choose and can stop. Treat it as a thank-you jar beside a paid tier, support or a hosted service, and ask in plain words in the README and changelog, not with pop-ups in the editor.

How to price a paid VS Code extension#

With no Marketplace price field, you set the price on your own site.

Per user or per machine. Price per user for anything a team might buy, as Thunder Client does with every plan. Per machine fits one-off purchases: Lemon Squeezy's licence docs use a "$9" product with an activation limit of 1 and a "$19" variant for up to 3 computers (Lemon Squeezy). Those are its example prices, not a recommendation.

Subscription or perpetual. A subscription suits anything with running costs or steady updates, and fits a hosted service. A perpetual licence with an update window, like Quokka's 12 months of new versions (Quokka Pro), is easier for individuals to accept, and nobody's editor breaks when a card expires.

Monthly or annual. A fixed part of each fee, such as the 50¢ in 5% + 50¢ (Paddle), weighs more on small monthly payments than on one yearly one. Thunder Client's paid plans are "Billed annually".

Where the free tier stops. Set the limit where casual users never hit it and heavy users hit it often. If you offer a time-limited trial, use the Trial label and say in the listing what happens when it ends.

None of these prices is a benchmark; they are what a few makers chose, as shown on their pages on 21 Oct 2026. For testing price points, how to price a SaaS product applies directly to a paid tier.

Before you turn on payments: a checklist#

1. Decide what is paid and where it is enforced. If the paid part is checked only in local code, accept leakage or move it to your server.
2. Pick the pricing label: Free for a permanent free tier, Trial if the extension stops after a trial (publishing guide).
3. Say it in the listing. Put what is paid, the price and a pricing link near the top of the README; the publisher agreement expects in-offering purchases to be disclosed.
4. Choose who sells: a merchant of record if you want tax handled, Stripe directly if you will register and file yourself.
5. Issue keys or accounts, through your provider or a GitHub sign-in, and store secrets in SecretStorage.
6. Design for offline with a cached check and a grace period.
7. Set the licence field on purpose, especially for Open VSX.
8. Publish a refund and support policy, because the agreement makes both your job.
9. Add the sponsor link anyway.
10. Plan the exit. Removing a paid extension needs 30 days' notice under the agreement, and existing customers keep using it, so keep your licence server running.

Then ship to both registries with the steps in how to publish a VS Code extension, and watch which free users hit the paid limit first. They are the people to email.

Where ZeroRaised fits once your paid tier is live#

A Marketplace listing reaches people already searching inside VS Code. It does not tell anyone outside the editor that a paid tier exists.

ZeroRaised is a free launch site for bootstrapped makers whose products have no institutional VC or accelerator equity. If your extension, or the product behind it, is live with a working free tier and a clear pricing page, you can submit it for review. The maker perks page lists separate offers for eligible makers, and the launch sites directory lists other venues by audience, including the Visual Studio Marketplace itself. None of them replaces a free tier people want and a checkout that works.

So, how to monetize a VS Code extension in one line: give away a version worth installing, sell the part that serves heavy or team use through a provider you trust, enforce it on your server where you can, and tell users plainly what they are paying for.