Short version: pick Qbox if you are starting a new roleplay server in 2026 and want the QBCore ecosystem with active maintenance and the ox stack built in. Pick ESX Legacy if you want the largest catalogue of scripts and a stable, slow-moving core. Pick QBCore only if you are inheriting an existing QBCore server or depend on paid scripts that have not been tested on Qbox. All three run the same game and use the same natives; the difference is the player object, the inventory model, and who is fixing bugs this year.
What the three frameworks are
ESX Legacy is the continuation of es_extended, the oldest of the three. It is maintained by the ESX Framework organisation on GitHub, releases tagged versions (1.9, 1.10, 1.11 and onwards), and has been the default for European roleplay servers for years. The player object is xPlayer, obtained with ESX.GetPlayerFromId(source).
QBCore started as a fork of an earlier “qb” framework and became the dominant choice for North American style servers around 2021 and 2022. The core is qb-core, and most of the ecosystem is qb-* resources (qb-inventory, qb-garages, qb-phone). The player object comes from QBCore.Functions.GetPlayer(source).
Qbox (qbx_core) is a hard fork of QBCore started in September 2022. It keeps the QBCore player data shape and adds a bridge layer so most correctly written qb scripts still run, but it replaces the qb-* base resources with Overextended’s: ox_lib, ox_inventory, ox_target and oxmysql. It targets Lua 5.4 throughout. The player object is available through exports.qbx_core:GetPlayer(source) and, through the bridge, the old QBCore.Functions.GetPlayer still works.
ESX vs QBCore vs Qbox comparison table
| Criteria | ESX Legacy | QBCore | Qbox |
|---|---|---|---|
| First released | 2017 (as es_extended) | 2021 (qb-core) | 2022 (qbx_core) |
| Maintenance in 2026 | Active, steady releases | Slowed considerably; community PRs, few core changes | Active, frequent releases |
| Ecosystem size | Largest, especially free scripts and older paid ones | Large; most Tebex roleplay scripts list “QB” support | Growing; most QB scripts run through the bridge |
| ox_lib and ox_inventory fit | Optional and widely used; official recipe supports ox_inventory | Optional; many servers swap qb-inventory for ox_inventory | Required; the framework is built on them |
| Database | oxmysql | oxmysql | oxmysql |
| Lua version | 5.4 in recent releases | Mixed; core is 5.4, many qb-* are not | 5.4 everywhere |
| Learning curve | Low; simplest API surface | Medium; many resources, inconsistent conventions | Medium to high; you must understand ox_lib and ox_inventory |
| Script compatibility | ESX scripts only (bridges exist but are patchy) | QB scripts | QB scripts via bridge, ox scripts natively |
| Default multi-character | Yes, in recent versions | Yes (qb-multicharacter) | Yes |
| Typical audience | European and Latin American RP, economy servers | North American RP, “serious RP” servers | New servers wanting QB style with modern tooling |
Two clarifications on the table. “Maintenance” is a judgement based on commit activity and release frequency on GitHub at the time of writing; check the repos yourself, since this changes. And “compatibility” means “runs without modification for scripts that used the documented API”. A qb script that pokes at qb-inventory internals will still need work on Qbox.
Who should pick ESX
Pick ESX Legacy if:
- Your community expects the ESX style of jobs, society accounts and the
esx_*resources. - You want the widest choice of free scripts. A decade of releases means most mechanics exist in some form.
- You want a framework that does not change much between versions. ESX 1.10 to 1.11 upgrades are usually uneventful.
- You are building an economy-heavy server rather than a “serious RP” one. ESX makes money, jobs and society accounts first-class.
Watch out for: legacy scripts written for ESX 1.1 or older. They call ESX.GetSharedObject through an event that no longer exists (esx:getSharedObject), and will need updating to ESX = exports['es_extended']:getSharedObject().
Who should pick QBCore
Pick QBCore only if:
- You already run a QBCore server and it works. There is no reason to migrate a stable server for its own sake.
- You depend on paid resources that explicitly test against qb-core and have not verified Qbox support.
- Your developers know the
qb-*resources well and you have no appetite for the ox stack.
Be honest with yourself about maintenance. When a game update breaks something in the core, you may be waiting on a community fork rather than an upstream release. Budget for that.
Who should pick Qbox
Pick Qbox if:
- You are starting a new server today and like the QBCore data model and script ecosystem.
- You want ox_inventory, ox_target and ox_lib from day one rather than swapping them in later.
- You want active upstream maintenance and a core that assumes Lua 5.4.
- You are fine reading documentation. Qbox and the ox resources are well documented but they assume you will read it.
Watch out for: scripts that say “QB compatible” but reach into qb-inventory or qb-target directly. Those need adapting, and the amount of adapting is the real cost of moving to Qbox.
Migration notes
QBCore to Qbox. The official Qbox docs describe the migration path. In practice: install the Qbox recipe fresh, migrate your players table (the JSON shape is compatible), then move resources one by one. Inventory is the hard part; qb-inventory item data and ox_inventory item data are stored differently, so you convert items rather than copy the column. Keep the old server running until every job and shop has been tested.
ESX to QBCore or Qbox. This is a rebuild, not a migration. The player identifiers, job structures and inventory formats are all different. If you are considering it, the honest advice is to start a fresh database and offer players a one-time transfer of money or vehicles through a script, not to try to convert the whole schema.
QBCore to ESX. Rare and equally a rebuild.
How AI assistants handle each framework
This matters more than it used to, because a lot of server owners now write scripts with Cursor, Claude Code or ChatGPT.
Language models confuse these three frameworks constantly. Ask for a Qbox script and you will get QBCore.Functions.GetPlayer with qb-inventory exports. Ask for ESX and you may get xPlayer.addInventoryItem (removed in favour of inventories like ox_inventory) or the old shared object event. The model has seen all three ecosystems, in all their versions, and treats them as one blurry “FiveM RP” API.
Skills fix this. A skill is a reference file the agent loads before writing code, so it uses the API from the reference rather than from memory. Our esx-framework skill covers xPlayer methods, jobs, society accounts and the ox_inventory integration. The qbcore-framework skill covers QBCore.Functions, PlayerData, items and the common qb-* exports, and calls out where Qbox differs. Pair either with the oxlib skill and the mixed-API problem mostly disappears. Our post on why ChatGPT writes broken FiveM scripts has the full list of mistakes to watch for.
Decision checklist
Answer these in order, and stop at the first one that decides it:
- Do you already run a working server? Stay on its framework. Migrations cost weeks.
- Do you own paid scripts that only support one framework? That framework, unless you are willing to replace them.
- Do you want the QBCore style (multi-character, gangs,
PlayerData)? Qbox for a new server. - Do you want the ESX style (society accounts,
esx_*jobs) or the largest free catalogue? ESX Legacy. - Do you or your developer already know one of them well? Weight that heavily. Framework familiarity beats framework features.
- Will you write scripts with an AI assistant? Any framework works, but install the matching skill before you start, or you will spend your evenings fixing mixed APIs.
Frequently asked questions
Is QBCore dead in 2026?
Not dead, but development has slowed a lot compared to 2022. Existing servers keep running and the community patches issues, but new features and fixes arrive faster in Qbox. For a new server it is hard to recommend QBCore over Qbox unless a specific paid script forces it.
Is Qbox compatible with QBCore scripts?
Mostly. Qbox ships a bridge that provides the qb-core export and QBCore.Functions API, so scripts written against the documented QBCore API usually run unchanged. Scripts that depend on qb-inventory, qb-target or qb-menu internals need adapting to ox_inventory, ox_target and ox_lib.
Which framework has the most free scripts?
ESX, by a wide margin, because of its age. QBCore is second and most of its ecosystem runs on Qbox. Quantity is not quality though; many old ESX releases need updating to the current es_extended API before they run.
Related FiveM skills
Add these skills to Cursor, VS Code or Claude Code so the AI knows the real APIs mentioned in this post.