Versão curta: escolha Qbox se você está começando um servidor de roleplay novo em 2026 e quer o ecossistema do QBCore com manutenção ativa e a stack ox já embutida. Escolha ESX Legacy se quer o maior catálogo de scripts e um core estável que muda devagar. Escolha QBCore só se está herdando um servidor QBCore existente ou depende de scripts pagos que ainda não foram testados no Qbox. Os três rodam o mesmo jogo e usam os mesmos natives; a diferença está no objeto do jogador, no modelo de inventário e em quem está corrigindo bugs este ano.
O que são os três frameworks
ESX Legacy é a continuação do es_extended, o mais antigo dos três. É mantido pela organização ESX Framework no GitHub, publica versões com tag (1.9, 1.10, 1.11 em diante) e há anos é o padrão de servidores de roleplay europeus. O objeto do jogador é o xPlayer, obtido com ESX.GetPlayerFromId(source).
QBCore começou como fork de um framework “qb” anterior e se tornou a escolha dominante para servidores no estilo norte-americano por volta de 2021 e 2022. O core é o qb-core, e a maior parte do ecossistema são recursos qb-* (qb-inventory, qb-garages, qb-phone). O objeto do jogador vem de QBCore.Functions.GetPlayer(source).
Qbox (qbx_core) é um hard fork do QBCore iniciado em setembro de 2022. Ele mantém o formato dos dados do jogador do QBCore e adiciona uma camada de bridge para que a maioria dos scripts qb bem escritos continue rodando, mas substitui os recursos base qb-* pelos da Overextended: ox_lib, ox_inventory, ox_target e oxmysql. Usa Lua 5.4 do início ao fim. O objeto do jogador está disponível por exports.qbx_core:GetPlayer(source) e, pela bridge, o antigo QBCore.Functions.GetPlayer ainda funciona.
Tabela comparativa ESX vs QBCore vs Qbox
| Critério | ESX Legacy | QBCore | Qbox |
|---|---|---|---|
| Primeiro lançamento | 2017 (como es_extended) | 2021 (qb-core) | 2022 (qbx_core) |
| Manutenção em 2026 | Ativa, releases constantes | Desacelerou bastante; PRs da comunidade, poucas mudanças no core | Ativa, releases frequentes |
| Tamanho do ecossistema | O maior, especialmente scripts gratuitos e pagos mais antigos | Grande; a maioria dos scripts de roleplay no Tebex lista suporte a “QB” | Em crescimento; a maioria dos scripts QB roda pela bridge |
| Encaixe com ox_lib e ox_inventory | Opcional e muito usado; a recipe oficial suporta ox_inventory | Opcional; muitos servidores trocam qb-inventory por ox_inventory | Obrigatório; o framework é construído sobre eles |
| Banco de dados | oxmysql | oxmysql | oxmysql |
| Versão do Lua | 5.4 nas releases recentes | Misto; o core é 5.4, muitos qb-* não são | 5.4 em tudo |
| Curva de aprendizado | Baixa; API mais simples | Média; muitos recursos, convenções inconsistentes | Média a alta; você precisa entender ox_lib e ox_inventory |
| Compatibilidade de scripts | Só scripts ESX (existem bridges, mas são irregulares) | Scripts QB | Scripts QB pela bridge, scripts ox nativamente |
| Multi-personagem padrão | Sim, nas versões recentes | Sim (qb-multicharacter) | Sim |
| Público típico | RP europeu e latino-americano, servidores de economia | RP norte-americano, servidores de “RP sério” | Servidores novos que querem o estilo QB com ferramentas modernas |
Dois esclarecimentos sobre a tabela. “Manutenção” é um julgamento baseado na atividade de commits e na frequência de releases no GitHub no momento da escrita; confira os repositórios você mesmo, porque isso muda. E “compatibilidade” significa “roda sem modificação para scripts que usaram a API documentada”. Um script qb que mexe nos internos do qb-inventory ainda vai precisar de trabalho no Qbox.
Quem deve escolher ESX
Escolha ESX Legacy se:
- Sua comunidade espera o estilo ESX de jobs, contas de society e os recursos
esx_*. - Você quer a maior variedade de scripts gratuitos. Uma década de lançamentos significa que a maioria das mecânicas existe de alguma forma.
- Você quer um framework que não muda muito entre versões. Atualizações de ESX 1.10 para 1.11 costumam ser tranquilas.
- Você está montando um servidor focado em economia, e não em “RP sério”. O ESX trata dinheiro, jobs e contas de society como cidadãos de primeira classe.
Fique atento a: scripts legados escritos para ESX 1.1 ou anterior. Eles chamam ESX.GetSharedObject por um evento que não existe mais (esx:getSharedObject) e precisam ser atualizados para ESX = exports['es_extended']:getSharedObject().
Quem deve escolher QBCore
Escolha QBCore só se:
- Você já roda um servidor QBCore e ele funciona. Não há motivo para migrar um servidor estável só por migrar.
- Você depende de recursos pagos que testam explicitamente contra o qb-core e não verificaram o suporte a Qbox.
- Seus desenvolvedores conhecem bem os recursos
qb-*e vocês não têm interesse na stack ox.
Seja honesto consigo mesmo sobre manutenção. Quando uma atualização do jogo quebra algo no core, você pode ficar esperando um fork da comunidade em vez de uma release oficial. Reserve tempo para isso.
Quem deve escolher Qbox
Escolha Qbox se:
- Você está começando um servidor novo hoje e gosta do modelo de dados e do ecossistema de scripts do QBCore.
- Você quer ox_inventory, ox_target e ox_lib desde o primeiro dia, em vez de trocar depois.
- Você quer manutenção ativa upstream e um core que assume Lua 5.4.
- Você não se importa em ler documentação. O Qbox e os recursos ox são bem documentados, mas partem do princípio de que você vai ler.
Fique atento a: scripts que dizem “compatível com QB” mas acessam qb-inventory ou qb-target diretamente. Esses precisam de adaptação, e a quantidade de adaptação é o custo real de migrar para o Qbox.
Notas de migração
QBCore para Qbox. A documentação oficial do Qbox descreve o caminho de migração. Na prática: instale a recipe do Qbox do zero, migre sua tabela players (o formato JSON é compatível) e depois mova os recursos um por um. O inventário é a parte difícil; os dados de itens do qb-inventory e do ox_inventory são armazenados de forma diferente, então você converte os itens em vez de copiar a coluna. Mantenha o servidor antigo rodando até que todos os jobs e lojas tenham sido testados.
ESX para QBCore ou Qbox. Isso é uma reconstrução, não uma migração. Os identificadores de jogador, as estruturas de job e os formatos de inventário são todos diferentes. Se você está considerando, o conselho honesto é começar um banco de dados novo e oferecer aos jogadores uma transferência única de dinheiro ou veículos por um script, em vez de tentar converter o schema inteiro.
QBCore para ESX. Raro e igualmente uma reconstrução.
Como os assistentes de IA lidam com cada framework
Isso importa mais do que antes, porque muitos donos de servidor agora escrevem scripts com Cursor, Claude Code ou ChatGPT.
Modelos de linguagem confundem esses três frameworks o tempo todo. Peça um script para Qbox e você vai receber QBCore.Functions.GetPlayer com exports do qb-inventory. Peça para ESX e pode receber xPlayer.addInventoryItem (removido em favor de inventários como o ox_inventory) ou o antigo evento do shared object. O modelo viu os três ecossistemas, em todas as versões, e trata todos como uma única API borrada de “RP FiveM”.
As skills resolvem isso. Uma skill é um arquivo de referência que o agente carrega antes de escrever código, então ele usa a API da referência, não a da memória. Nossa skill esx-framework cobre os métodos do xPlayer, jobs, contas de society e a integração com ox_inventory. A skill qbcore-framework cobre QBCore.Functions, PlayerData, itens e os exports qb-* mais comuns, e aponta onde o Qbox difere. Combine qualquer uma delas com a skill oxlib e o problema das APIs misturadas praticamente desaparece. Nosso post sobre por que o ChatGPT escreve scripts FiveM quebrados tem a lista completa de erros para ficar de olho.
Checklist de decisão
Responda nesta ordem e pare na primeira que decidir:
- Você já roda um servidor funcionando? Fique no framework dele. Migrações custam semanas.
- Você tem scripts pagos que só suportam um framework? Esse framework, a menos que esteja disposto a substituí-los.
- Você quer o estilo QBCore (multi-personagem, gangues,
PlayerData)? Qbox para um servidor novo. - Você quer o estilo ESX (contas de society, jobs
esx_*) ou o maior catálogo gratuito? ESX Legacy. - Você ou seu desenvolvedor já conhecem bem um deles? Dê muito peso a isso. Familiaridade com o framework vale mais que funcionalidades do framework.
- Você vai escrever scripts com um assistente de IA? Qualquer framework funciona, mas instale a skill correspondente antes de começar, ou vai passar as noites corrigindo APIs misturadas.
Perguntas frequentes
O QBCore está morto em 2026?
Morto não, mas o desenvolvimento desacelerou muito em comparação com 2022. Servidores existentes continuam rodando e a comunidade corrige problemas, mas novas funcionalidades e correções chegam mais rápido no Qbox. Para um servidor novo, é difícil recomendar QBCore em vez de Qbox, a menos que um script pago específico force isso.
O Qbox é compatível com scripts do QBCore?
Na maior parte, sim. O Qbox vem com uma bridge que fornece o export qb-core e a API QBCore.Functions, então scripts escritos contra a API documentada do QBCore normalmente rodam sem alteração. Scripts que dependem dos internos de qb-inventory, qb-target ou qb-menu precisam ser adaptados para ox_inventory, ox_target e ox_lib.
Qual framework tem mais scripts gratuitos?
ESX, com larga vantagem, por causa da idade. QBCore vem em segundo, e a maior parte do ecossistema dele roda no Qbox. Mas quantidade não é qualidade; muitos lançamentos antigos de ESX precisam ser atualizados para a API atual do es_extended antes de rodar.
Skills de FiveM relacionadas
Adicione estas skills ao Cursor, VS Code ou Claude Code para que a IA conheça as APIs reais citadas neste artigo.