ESX vs QBCore vs Qbox en 2026: ¿qué framework de FiveM deberías elegir?

Elige ESX Legacy por el mayor catálogo de scripts y los servidores veteranos, QBCore para empezar con más facilidad y muchos recursos listos, y Qbox si quieres una base moderna centrada en ox_lib. Depende de tus scripts, tu equipo y cuánto quieras migrar.

Elige Qbox si vas a abrir un servidor de roleplay nuevo en 2026 y quieres el ecosistema de QBCore con mantenimiento activo y el stack ox integrado de serie. Elige ESX Legacy si quieres el catálogo de scripts más grande y un core estable que cambia despacio. Elige QBCore solo si heredas un servidor QBCore ya existente o dependes de scripts de pago que no se han probado en Qbox. Los tres corren el mismo juego y usan los mismos natives. Cambian el objeto jugador, el modelo de inventario y quién está corrigiendo bugs este año.

Qué son los tres frameworks

ESX Legacy es la continuación de es_extended, el más antiguo de los tres. Lo mantiene la organización ESX Framework en GitHub, publica versiones etiquetadas (1.9, 1.10, 1.11 y siguientes) y lleva años siendo el estándar de los servidores de roleplay europeos. El objeto jugador es xPlayer, que se obtiene con ESX.GetPlayerFromId(source).

QBCore empezó como fork de un framework "qb" anterior y se convirtió en la opción dominante para servidores de estilo norteamericano hacia 2021 y 2022. El core es qb-core, y la mayor parte del ecosistema son recursos qb-* (qb-inventory, qb-garages, qb-phone). El objeto jugador sale de QBCore.Functions.GetPlayer(source).

Qbox (qbx_core) es un hard fork de QBCore iniciado en septiembre de 2022. Conserva la forma de los datos del jugador de QBCore y añade una capa puente para que la mayoría de scripts qb bien escritos sigan funcionando, pero sustituye los recursos base qb-* por los de Overextended: ox_lib, ox_inventory, ox_target y oxmysql. Apunta a Lua 5.4 en todo el código. El objeto jugador está disponible a través de exports.qbx_core:GetPlayer(source) y, mediante el puente, el antiguo QBCore.Functions.GetPlayer sigue funcionando.

Tabla comparativa ESX vs QBCore vs Qbox

Criterio	ESX Legacy	QBCore	Qbox
Primera versión	2017 (como es_extended)	2021 (qb-core)	2022 (qbx_core)
Mantenimiento en 2026	Activo, versiones constantes	Bastante ralentizado; PRs de la comunidad, pocos cambios en el core	Activo, versiones frecuentes
Tamaño del ecosistema	El mayor, sobre todo en scripts gratuitos y de pago antiguos	Grande; la mayoría de scripts de roleplay en Tebex indican soporte "QB"	Creciendo; la mayoría de scripts QB funcionan a través del puente
Encaje con ox_lib y ox_inventory	Opcional y muy usado; la receta oficial soporta ox_inventory	Opcional; muchos servidores cambian qb-inventory por ox_inventory	Obligatorio; el framework está construido sobre ellos
Base de datos	oxmysql	oxmysql	oxmysql
Versión de Lua	5.4 en versiones recientes	Mixta; el core es 5.4, muchos `qb-*` no	5.4 en todo
Curva de aprendizaje	Baja; la API más simple	Media; muchos recursos, convenciones inconsistentes	Media a alta; hay que entender ox_lib y ox_inventory
Compatibilidad de scripts	Solo scripts ESX (existen puentes, pero irregulares)	Scripts QB	Scripts QB vía puente, scripts ox de forma nativa
Multipersonaje por defecto	Sí, en versiones recientes	Sí (qb-multicharacter)	Sí
Público típico	RP europeo y latinoamericano, servidores de economía	RP norteamericano, servidores de "RP serio"	Servidores nuevos que quieren estilo QB con herramientas modernas

Dos notas sobre la tabla. "Mantenimiento" es un juicio basado en la actividad de commits y la frecuencia de versiones en GitHub en el momento de escribir esto; revisa los repositorios tú mismo, porque cambia. Y "compatibilidad" significa "funciona sin modificaciones para scripts que usaban la API documentada". Un script qb que toque las entrañas de qb-inventory seguirá necesitando trabajo en Qbox.

Quién debería elegir ESX

Elige ESX Legacy si:

Tu comunidad espera el estilo ESX de trabajos, cuentas de sociedad y los recursos esx_*.
Quieres la mayor variedad de scripts gratuitos. Una década de publicaciones significa que casi cualquier mecánica existe de alguna forma.
Quieres un framework que no cambie mucho entre versiones. Las actualizaciones de ESX 1.10 a 1.11 suelen pasar sin sobresaltos.
Estás montando un servidor centrado en la economía y no uno de "RP serio". ESX trata el dinero, los trabajos y las cuentas de sociedad como ciudadanos de primera.

Cuidado con: scripts antiguos escritos para ESX 1.1 o anteriores. Llaman a ESX.GetSharedObject a través de un evento que ya no existe (esx:getSharedObject) y habrá que actualizarlos a ESX = exports['es_extended']:getSharedObject().

Quién debería elegir QBCore

Elige QBCore solo si:

Ya tienes un servidor QBCore y funciona. No hay motivo para migrar un servidor estable porque sí.
Dependes de recursos de pago que se prueban explícitamente contra qb-core y no han verificado soporte para Qbox.
Tus desarrolladores conocen bien los recursos qb-* y no tienes ganas de meterte con el stack ox.

Cuenta con el mantenimiento. Cuando una actualización del juego rompa algo en el core, puede que tengas que esperar a un fork de la comunidad en lugar de a una versión oficial.

Quién debería elegir Qbox

Elige Qbox si:

Vas a abrir un servidor nuevo hoy y te gusta el modelo de datos y el ecosistema de scripts de QBCore.
Quieres ox_inventory, ox_target y ox_lib desde el primer día en lugar de cambiarlos más adelante.
Quieres mantenimiento activo upstream y un core que asume Lua 5.4.
No te importa leer documentación. Qbox y los recursos ox están bien documentados, pero dan por hecho que la vas a leer.

Cuidado con: scripts que dicen ser "compatibles con QB" pero acceden directamente a qb-inventory o qb-target. Esos necesitan adaptación, y la cantidad de adaptación es el costo real de pasarse a Qbox.

Notas de migración

De QBCore a Qbox. La documentación oficial de Qbox describe la ruta de migración. En la práctica: instala la receta de Qbox desde cero, migra tu tabla players (la forma del JSON es compatible) y luego mueve los recursos uno a uno. El inventario es la parte difícil; los datos de ítems de qb-inventory y los de ox_inventory se guardan de forma distinta, así que conviertes los ítems en lugar de copiar la columna. Mantén el servidor viejo funcionando hasta que hayas probado todos los trabajos y tiendas.

De ESX a QBCore o Qbox. Esto es una reconstrucción, no una migración. Los identificadores de jugador, las estructuras de trabajos y los formatos de inventario son todos diferentes. Si lo estás considerando, el consejo honesto es empezar con una base de datos nueva y ofrecer a los jugadores una transferencia única de dinero o vehículos mediante un script, no intentar convertir todo el esquema.

De QBCore a ESX. Poco habitual e igualmente una reconstrucción.

Cómo manejan cada framework los asistentes de IA

Muchos dueños de servidores ya escriben scripts con Cursor, Claude Code o ChatGPT, y los modelos de lenguaje confunden estos tres frameworks constantemente. Pide un script para Qbox y muchas veces te dará QBCore.Functions.GetPlayer con exports de qb-inventory. Pide uno para ESX y puede que te dé xPlayer.addInventoryItem (eliminado en favor de inventarios como ox_inventory) o el viejo evento del shared object. El modelo ha visto los tres ecosistemas en todas sus versiones y los trata como una única API borrosa de "FiveM RP".

Una skill lo soluciona. Es un archivo de referencia que el agente carga antes de escribir código, de modo que usa la API de la referencia y no la de su memoria. Nuestra skill esx-framework cubre los métodos de xPlayer, trabajos, cuentas de sociedad y la integración con ox_inventory. La skill qbcore-framework cubre QBCore.Functions, PlayerData, ítems y los exports qb-* habituales, y señala dónde difiere Qbox. Combina cualquiera de las dos con la skill oxlib y el problema de las APIs mezcladas prácticamente desaparece. Nuestro artículo sobre por qué ChatGPT escribe scripts de FiveM rotos tiene la lista completa de errores a vigilar.

Lista de decisión

Responde en orden y para en la primera que lo decida:

¿Ya tienes un servidor funcionando? Quédate en su framework. Las migraciones llevan semanas.
¿Tienes scripts de pago que solo soportan un framework? Ese framework, salvo que estés dispuesto a reemplazarlos.
¿Quieres el estilo QBCore (multipersonaje, bandas, PlayerData)? Qbox para un servidor nuevo.
¿Quieres el estilo ESX (cuentas de sociedad, trabajos esx_*) o el catálogo gratuito más grande? ESX Legacy.
¿Tú o tu desarrollador ya conocen bien uno de ellos? Dale mucho peso. La familiaridad con el framework vale más que sus funcionalidades.
¿Vas a escribir scripts con un asistente de IA? Cualquier framework sirve, pero instala la skill correspondiente antes de empezar, o pasarás las noches arreglando APIs mezcladas.

Si estás sopesando opciones, nuestra comparativa de herramientas de IA para FiveM explica en qué acierta cada una y dónde falla.

Preguntas frecuentes

¿Está muerto QBCore en 2026?

Muerto no, pero el desarrollo se ha ralentizado mucho comparado con 2022. Los servidores existentes siguen funcionando y la comunidad parchea problemas, pero las funcionalidades y correcciones nuevas llegan más rápido en Qbox. Para un servidor nuevo es difícil recomendar QBCore por encima de Qbox, salvo que un script de pago concreto te obligue.

¿Es Qbox compatible con los scripts de QBCore?

En su mayoría. Qbox incluye un puente que proporciona el export qb-core y la API QBCore.Functions, así que los scripts escritos contra la API documentada de QBCore suelen funcionar sin cambios. Los scripts que dependen de las entrañas de qb-inventory, qb-target o qb-menu necesitan adaptarse a ox_inventory, ox_target y ox_lib.

¿Qué framework tiene más scripts gratuitos?

ESX, con mucha diferencia, por su antigüedad. QBCore es el segundo y la mayor parte de su ecosistema funciona en Qbox. Aun así, cantidad no es calidad. Muchas publicaciones antiguas de ESX necesitan actualizarse a la API actual de es_extended antes de funcionar.