Feature

Zero hallucinated exports.

Generic coding AIs guess. They call ox_lib.notify_player(), they pass arguments to oxmysql:fetch() in the wrong order, they invent QBCore events that do not exist. SwisserAI is tuned against the real API surface of the libraries FiveM actually runs.

You paste less, you reread less, you spend less time explaining that no, that function has never shipped.

Try it free See pricing

The ox_lib hallucination problem

Generic AI models ChatGPT, Claude, Copilot are trained on the entire public internet. That includes ox_lib documentation, but it also includes every stale forum thread, every PR that never merged, every screenshot of someone's home-grown fork, and every Lua tutorial that confidently teaches a function that was renamed two releases ago.

The result: when you ask a generic model for a notification, it might give you ox_lib.notify_player(source, "hello") a function that has never existed. The correct call is lib.notify(source, {title = "hello"}). One looks reasonable, one actually works.

Multiply that by every function across ox_lib, oxmysql, ox_inventory, ox_target, QBCore, Qbox, ESX Legacy, ESX v1-final, and the FiveM natives themselves, and you have a developer tax: every AI answer needs a manual pass to check the model did not invent half the call site.

Generic AI output

-- Invented / wrong
ox_lib.notify_player(source, "You got paid")

local result = oxmysql:fetch(
  "SELECT * FROM players WHERE id = ?",
  playerId
)

RegisterNetEvent("QBCore:GiveMoney")
AddEventHandler("QBCore:GiveMoney",
  function(amount)
    QBCore.Player.AddMoney(source, amount)
  end
)

notify_player does not exist · oxmysql:fetch wants a table · QBCore:GiveMoney is not a real event · AddMoney lives on QBCore.Functions.GetPlayer(src)

SwisserAI validated output

-- Grounded against current APIs
lib.notify(source, {
  title  = "Paid",
  description = "You got paid",
  type   = "success",
})

local row = MySQL.single.await(
  "SELECT * FROM players WHERE id = ?",
  { playerId }
)

local Player = QBCore.Functions.GetPlayer(source)
if Player then
  Player.Functions.AddMoney("cash", amount, "payout")
end

lib.notify signature matches ox_lib · MySQL.single.await is the real oxmysql call · QBCore.Functions.GetPlayer is the real core lookup

How SwisserAI grounds outputs

Under the hood, SwisserAI is a FiveM-tuned model wrapped in a grounding and validation layer. Three things happen to every generation:

Step 1

Framework detection

We inspect your prompt, your pasted code, or your resource to determine which frameworks are in play ox_lib, oxmysql, QBCore, Qbox, ESX Legacy, ESX v1-final and which versions. The model only pulls grounding for what is actually relevant.

Step 2

Grounded generation

The model is tuned on the API surfaces of those libraries exports, events, natives, argument shapes. Grounding is stitched into the context so the model is never guessing what lib.callback accepts.

Step 3

Export linter

After generation, a static pass checks every export, event, and native in the output against the grounded index. Anything that cannot be verified is flagged in the UI before you copy it anywhere near your server.

We are honest about the limit of this: grounding reduces hallucination rate, it does not prove correctness. Edge cases in niche forks, custom resources we have never seen, and frameworks that broke their own exports last week will still produce the occasional miss. But the baseline is no longer "every answer needs a full manual check" it is "the model now reliably uses real function names, and the linter catches the rest."

Compared to a generic model that will happily invent QBCore:TriggerServerCallbackAsync because it sounds right, this is the difference between shipping in an afternoon and debugging console errors for two hours.

What we validate

The grounded index covers the surface area you hit every day on a real FiveM server. If it is in the stock release of any of these libraries, SwisserAI knows the current signature.

ox_lib functions

lib.notify, lib.callback, lib.showContext, lib.registerContext, lib.cache, lib.locale full argument shapes for the current ox_lib release.

oxmysql syntax

MySQL.query vs MySQL.prepare vs MySQL.scalar vs MySQL.insert, correct parameter arrays, awaitable vs callback variants.

QBCore events

Client and server event names, QBCore:GetCoreObject, PlayerData shape, QBCore.Functions.* and QBCore.Commands.Add.

Qbox state bags

Player.PlayerData via state bags, the Qbox migration deltas from QBCore, and the Qbox-specific helper exports.

fxmanifest structure

fx_version, game, lua54, shared_scripts, client_scripts, server_scripts, dependencies, ui_page in the right order with correct values.

Resource naming

Folder-matches-resource, kebab-case conventions, avoiding reserved names, and valid dependency references in server.cfg.

Beyond the stock libraries

If your stack includes a library we have not indexed yet or your own internal resource you can paste the relevant exports into the session and SwisserAI will treat them as the ground truth for the rest of the conversation. Team plans include persistent private grounding for organisation-specific frameworks.

FAQ

No. Any model is capable of making up a function name, a field, or an event especially for edge cases, niche forks, or custom resources it has never seen. What we do is reduce the hallucination rate dramatically for the FiveM surface area that matters: the stock ox_lib exports, the oxmysql argument shapes, the QBCore and Qbox event names, and the ESX legacy vs v1-final differences. In practice this means far fewer "this export does not exist" errors in your server console after pasting in generated code, and far fewer wasted back-and-forth turns asking the AI to "please actually use the real function".

The supported surface today covers ox_lib, oxmysql, ox_inventory, ox_target, QBCore (core shared + client/server events), Qbox (state bags and PlayerData patterns), ESX Legacy and v1-final, and the core FiveM natives via the official native reference. We also validate fxmanifest.lua structure (fx_version, game, shared_scripts, dependencies) against what server.cfg actually accepts.

Grounding data is refreshed on a rolling basis whenever a major release ships. ox_lib in particular moves exports get renamed, new ones get added and stale grounding is worse than no grounding. When a framework ships a breaking change we prioritise re-indexing, and you can check the footer of any generated answer to see what revision of each library the output is grounded against.

Two things. First, the in-product linter flags any export, event, or native the model called that it cannot verify against its grounded index, so you see a warning before you ever run the code. Second, you can reply with the console error and the model will re-ground against the real library and regenerate it does not dig in and insist the fake export exists the way a generic model often does.

Yes. Paste code you got from any AI (ChatGPT, Claude, Copilot, Cursor) into SwisserAI and ask it to "validate exports and events against ox_lib / QBCore / Qbox / ESX". The same grounding runs in review mode you get back a diff with the fake calls highlighted and suggested real replacements.

Partially. For custom exports inside your own resource, you can point SwisserAI at your repo (or paste the relevant resource) and it will treat those exports as the ground truth for the rest of the session. For entirely custom frameworks we have not indexed, the model will still generate against FiveM natives correctly but cannot guarantee your internal exports. Team plans include private grounding for organisation-specific frameworks.