Why your inventory choice shapes the whole server
The inventory is not just a grid of items. On a roleplay server it is the contract every other script signs. A weapon shop, a drug-selling job, a vehicle trunk, a stash robbery, a crafting bench, and a police evidence locker all read and write through the same item system. If that system is slow, buggy, or hard to extend, every script you add inherits the problem.
That is why the inventory decision deserves more thought than picking the one with the prettiest screenshots. You are choosing a data model and an API that the rest of your build depends on. This article compares the four resources most servers actually run: ox_inventory, qb-inventory, qs-inventory, and codem-inventory. We focus on mechanism, not marketing.
The core concepts every inventory handles
Before comparing resources, it helps to name what they all do under the hood.
Items, metadata, and stacking
Every item has a name, a label, and a weight. The real divider is metadata. Metadata is per-item data attached to a single stack, like durability on a weapon, a registration plate on a vehicle key, or a serial number on a phone. Inventories that support rich metadata let two items with the same name behave differently, which is what makes registered weapons, marked bills, and crafted goods possible.
Slots versus weight
There are two limiting models. Slot based inventories cap how many distinct stacks you can hold. Weight based inventories cap the total kilograms you can carry. Most modern inventories use both at once: a fixed slot count plus a maximum weight. The interaction between them is where bugs hide, for example an item that stacks to 50 in one slot but weighs enough to block pickup before you ever fill the stack.
Shared state for stashes, drops, and shops
A stash, a ground drop, a vehicle glovebox, and a shop are all just inventories with different owners and access rules. A clean inventory exposes one consistent way to register and open any of them, so a developer writing a new job does not reinvent storage each time.
ox_inventory
ox_inventory is maintained by the Overextended team and is the de facto standard for new builds. It is open source under the GPL-3.0 license, which means you can read every line, fork it, and learn from it, provided you keep your modifications under the same license.
Mechanism
ox_inventory is built on top of ox_lib and is framework agnostic. It ships with first class bridges for ESX and QBCore, and it can run standalone. Items are defined in a single items.lua, and metadata is a first class concept used throughout, including for durability and serials. It treats stashes, drops, shops, and player inventories as the same primitive, exposed through server exports like RegisterStash and item callbacks. It stores data efficiently and is engineered to avoid the per-frame churn that older inventories suffered from.
Example
Giving an item with metadata looks like exports.ox_inventory:AddItem(source, 'phone', 1, { serial = 'A1B2C3' }). A weapon picked up off a drop keeps its ammo, attachments, and durability because those live in metadata, not in a parallel weapons table. This single model is why ox_inventory integrates cleanly with ox-adjacent scripts and most modern paid scripts that advertise ox_inventory support.
Trade offs
The ecosystem assumes some comfort with Lua and exports. If your team copies and pastes from tutorials without reading them, the learning curve is real. It is also opinionated, so scripts written against older qb item conventions may need a bridge or rewrite.
qb-inventory
qb-inventory is the inventory that ships with the QBCore framework. If you are running stock QBCore, it is the path of least resistance.
Mechanism
qb-inventory is slot based with weight limits and is tightly coupled to QBCore's player object and item definitions in qb-core/shared/items.lua. It supports item info, the qb equivalent of metadata, though historically its metadata handling was less uniform than ox_inventory's. It has been actively reworked over time, and current versions are far more capable than the early releases many old guides describe.
Example
Most QBCore jobs and shops are written directly against qb-inventory exports and events, so dropping in a qb job script usually just works without a bridge. That compatibility with the huge library of QBCore community scripts is its strongest argument.
Trade offs
Its tight coupling to QBCore is both the benefit and the limit. Moving to a different framework, or mixing in ox-style scripts, means bridging. Older forks and leaked variants float around the community with inconsistent behavior, so use the official QBCore repository version.
qs-inventory
qs-inventory is a paid resource from Quasar Store. It targets server owners who want a polished, feature rich inventory without assembling pieces themselves.
Mechanism
qs-inventory supports both ESX and QBCore and uses a slot plus weight model with metadata. Its selling point is the bundled feature set and UI: item rarity, crafting, an inventory HUD, weapon attachments, and configuration aimed at non-programmers. It is designed to drop in and be configured through files rather than code.
Trade offs
Being paid and closed source, you cannot read or freely fork the core, and you depend on the vendor for fixes and updates. For many owners that support relationship is a feature, not a cost. The right question is whether the bundled crafting, HUD, and UI save you more time than wiring those onto a free base.
codem-inventory
codem-inventory is another paid, UI-forward inventory popular for its visual presentation and bundled extras like crafting and a clean HUD. Like qs-inventory it supports ESX and QBCore and uses slot and weight limits with metadata.
The practical comparison between codem and qs-inventory is less about raw mechanics and more about which UI and feature defaults you prefer, what your players are used to, and which vendor's support and update cadence you trust. Both are closed source, so the architectural transparency you get with ox_inventory is not on the table.
How to actually decide
Start from your framework and your script library. If most of your purchased and free scripts list ox_inventory support, choosing ox_inventory removes a whole category of bridging work. If you are committed to stock QBCore and the QBCore script ecosystem, qb-inventory is the lowest friction option. If you want a polished UI and bundled crafting or HUD out of the box and prefer configuring over coding, a paid resource like qs-inventory or codem-inventory earns its price.
Do not pick on screenshots. Pick on which data model your other scripts expect and which one your team can actually maintain when something breaks at 2am during a server event.