About the ABLX Directory

Ableton introduced Extensions — small TypeScript/Node tools that run inside Live — with the Live 12.4.5 Suite beta in June 2026. There is no official store; extensions are shared as .ablx files via Discord threads, GitHub releases and blog posts. This directory exists to close that gap: an open, automatically maintained index with search, categories, attribution, community ratings and a way for developers to claim their work.

It is run by the community and is not affiliated with Ableton AG.

How discovery works

Every day a crawler queries GitHub from several angles and unions the results:

• Code search for package.json files depending on @ableton-extensions/sdk — the strongest signal.
• Topics such as ableton-extensions, ableton-extension, extensions-sdk.
• Keyword searches (“ableton extension”, “ablx”, …).
• Committed .ablx files and release assets ending in .ablx.
• Community submissions from the submit page, and open registries we seed from (we re-verify everything ourselves).

Each candidate repo is then crawled in depth: we read its file tree, every package.json and manifest.json, the README, and its releases. A repo is listed only if it contains at least one SDK project (SDK dependency or an Ableton-shaped manifest) or ships a .ablx — vendored SDK examples, Stardew mods with a similar manifest, and pirate “Live 12 free download” repos are rejected automatically. Monorepos produce one listing per extension folder. If a repo disappears from GitHub its listings are marked removed.

Categories & metadata

Categories and tags are assigned by a transparent keyword classifier over the name, description, topics and README (name and description weigh far more than the README). It is good, not perfect — which is why verified developers and moderators can override categories, name, summary, install notes and links for any listing.

Download counts come from GitHub release-asset statistics; stars, forks, licence and activity come from the repository. A confidence score (0–100) reflects how many independent signals the crawler saw (SDK dependency, manifest, packaged .ablx).

Claiming your extension

Claiming proves you are the developer and unlocks a verified badge, listing edits, a “developer” tag on your comments and an editable profile. Three methods, all free:

1. Owner sign-in — connect the GitHub account that owns the repo (from your account page or the claim page). Instant.
2. Organisation membership — for org-owned repos we ask GitHub (scope read:org) whether you are an active member.
3. Verification file — we give you a code; commit it as .ablx-claim in the repo root. The next crawl (or the “Check now” button) verifies it. You may delete the file afterwards.

We only ever request read scopes. We never ask for write access to your repositories.

Community rules

• Sign in with Google, Facebook, Discord or GitHub. One rating per account per extension; GitHub accounts must be at least 7 days old to rate or comment, everything is rate-limited.
• Comments are plain text, one level of replies, and can be reported. Moderators can hide content and suspend accounts; every moderation action is audit-logged.
• Leaderboards use GitHub numbers refreshed daily plus live community numbers. The “top rated” board uses a Bayesian average so a single 5-star vote doesn’t top it.

Safety

Extensions execute code inside Live. We do not scan binaries. Listings from new repos with little activity and no verified developer carry an unverified warning. Read the source, check the author, and report anything suspicious with the report button — reports go straight to moderators.

Open data

The whole catalogue is available as JSON under a CC0 licence: see the API docs, registry.json, RSS and llms.txt.

Contact

Wrong attribution, a claim dispute, or a takedown request? Open an issue on the directory’s GitHub repository or reach a moderator via the report button on any page.