Versión corta: 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; la diferencia está en 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 aclaraciones 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.
Sé honesto contigo mismo sobre 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. Cuenta con ello.
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
Esto importa más que antes, porque muchos dueños de servidores ahora escriben scripts con Cursor, Claude Code o ChatGPT.
Los modelos de lenguaje confunden estos tres frameworks constantemente. Pide un script para Qbox y 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”.
Las skills solucionan esto. Una skill 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.
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.
Skills de FiveM relacionadas
Añade estas skills a Cursor, VS Code o Claude Code para que la IA conozca las APIs reales que se mencionan en este artículo.