QBox (qbx_core) on FiveM — Compatibility, APIs, and Quasar Academy Coverage

What it is

QBox (technically qbx_core) is a 2023-era fork of QBCore that made breaking changes its core team considered overdue: ox_lib and ox_inventory became required dependencies rather than optional, the Player object API was tightened, and a number of legacy patterns were dropped to reduce surface area. The result is a leaner, more opinionated core at the cost of dropping compatibility with QBCore-only resources that haven't been ported.

The QBox stance is essentially: "the ecosystem already standardized on Overextended's libraries (ox_lib, ox_inventory, oxmysql, ox_target). Stop pretending those are optional. Build the core around them." That decision makes QBox feel cleaner to write against, but means a QBox server is best built with QBox-native or actively-ported scripts rather than vanilla QBCore stock.

For greenfield 2025–2026 servers with no legacy script catalog to drag along, QBox is a serious starting point. For servers with a substantial QBCore script library that hasn't been ported, the migration cost is real — see /compatibility/qbcore-vs-qbox.

When to choose QBox

• You're building a new server in 2025–2026 and want the most modern, opinionated base.
• You're already committed to ox_lib + ox_inventory + ox_target as your library stack and don't want a core that pretends otherwise.
• You value framework leanness over framework feature breadth (smaller surface = fewer footguns).
• Your script-buying decisions can be filtered to QBox-compatible or actively-ported titles only.

Version timeline

Signature code patterns

local Player = exports.qbx_core:GetPlayer(source)
if Player then
  Player.Functions.AddMoney('cash', 500, 'gift-from-admin')
  exports.qbx_core:Notify(source, 'You received $500', 'success')
end

lib.registerContext({
  id = 'shop_menu',
  title = 'Buy something',
  options = {
    { title = 'Bread', description = '$5', onSelect = function() buy('bread', 5) end },
    { title = 'Water', description = '$3', onSelect = function() buy('water', 3) end },
  },
})
lib.showContext('shop_menu')

Common pitfalls

Quasar Academy support for QBox

Common questions about QBox

Is QBox just QBCore with breaking changes?

Roughly, yes — that's the honest framing. QBox forked QBCore to enforce ox_lib + ox_inventory and drop a set of legacy patterns its maintainers considered debt. Whether the breakage is worth the leanness is the choice you're making.

Will my QBCore scripts run on QBox?

Some will, with minimal changes. Many won't without a port pass. Don't budget a QBCore → QBox migration as a one-day swap; budget per-script port time and assume your largest scripts take a multi-day refactor each.

Should new servers pick QBox over QBCore in 2026?

If you have no legacy script catalog and want the most modern base, yes. If you have a working QBCore catalog that meets your needs, the migration cost will outweigh the technical gains. See /compatibility/qbcore-vs-qbox.

Does Quasar Academy ship QBox-specific code review?

Yes. Elite weekly review covers QBox idioms (qbx_core entry points, ox_lib UI patterns, ox_inventory metadata schema). Tell us in onboarding that QBox is your target.

Can QBox and QBCore run on the same server?

No — both register a 'core' role. Pick one core. You can mix per-script library usage (a script can use ox_lib and qb-target side by side) but not two parallel cores.