host-authoritative-state

host-authoritative-state is a skill for Claude Code from ouzlifaneyassine1-dot/onyx-engine. It costs 73 tokens per session (4,494 once invoked), scanned A, a copy of host-authoritative-state, MIT.

A guide for deciding which parts of a Godot multiplayer game's state belong to the host and which may belong to clients. The host is the player or server treated as the trusted source of shared game facts.

In plain words
What is it for?
It helps classify state fields, validate client requests, broadcast approved changes, and combine host authority with client prediction for responsive movement.
Why use it?
It helps prevent cheating, duplicated items, false hit detection, and players appearing in different places because clients changed data they should not control.

Skill for Claude Code

Written for Claude Code: allowed-tools in frontmatter. Also seen: mentions Claude Code; mentions Codex.

Part of the onyx plugin — 77 skills, 1 command, 2 hooks, 1 MCP server shipped together

Good fit It helps classify state fields, validate client requests, broadcast approved changes, and combine host authority with client prediction for responsive movement.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/ouzlifaneyassine1-dot/onyx-engine/host-authoritative-state
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent
npx skills add ouzlifaneyassine1-dot/onyx-engine --skill host-authoritative-state
Clone the repo
git clone --depth 1 https://github.com/ouzlifaneyassine1-dot/onyx-engine

Made for: Claude Code.

Or install onyx, the plugin that ships this one along with the rest of its 77 skills, 1 command, 2 hooks, 1 MCP server.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for host-authoritative-state

README.md
[![agentmods](https://agentmods.dev/badge/skills/ouzlifaneyassine1-dot/onyx-engine/host-authoritative-state/github.svg)](https://agentmods.dev/skills/ouzlifaneyassine1-dot/onyx-engine/host-authoritative-state)
Your own site
<a href="https://agentmods.dev/skills/ouzlifaneyassine1-dot/onyx-engine/host-authoritative-state"><img src="https://agentmods.dev/badge/skills/ouzlifaneyassine1-dot/onyx-engine/host-authoritative-state/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for host-authoritative-state

Your own site · 80×15
<a href="https://agentmods.dev/skills/ouzlifaneyassine1-dot/onyx-engine/host-authoritative-state"><img src="https://agentmods.dev/badge/skills/ouzlifaneyassine1-dot/onyx-engine/host-authoritative-state.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 73 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 4,494 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin 89% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00073 $0.04494
Opus 5 $0.00036 $0.02247
Sonnet 5 $0.00015 $0.00899
Haiku 4.5 $0.00007 $0.00449

Measured 10d ago against content hash 962e9505bbfa, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-11, from the pricing page.

Security

Grade A, and why

host-authoritative-state scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

89% identical to host-authoritative-state — 18 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

skills/multiplayer-and-networking/host-authoritative-state/SKILL.md · 333 lines

How it starts

The opening of the file, as written. The whole thing — 333 lines — stays where its author put it; the contents beside it link to each section on GitHub.

/host-authoritative-state — Designing the State Layer

Overview

This is Layer 2 of multiplayer architecture. /peer-to-peer-multiplayer covers all four layers; this skill zooms in on the one that produces 90% of shipping-quality MP bugs. For every piece of state in your game, decide: does the host own it, or does the client own it? Get this wrong and you ship a cheat-vulnerable, desync-prone game where players "teleport," items dupe, and hit-detection lies. Get it right and the rest of multiplayer falls into place.

The fundamental question

For every state field, ask one question:

If a malicious client lies about this, does it break the game?

Answer Owner Notes
Yes Host-authoritative. Clients send intent (RPC request); host validates and broadcasts.
No Client-owned. Cosmetic. Replicated for visual sync only.
Sometimes Host-authoritative with client prediction. Position is the canonical example: client predicts to feel responsive; host reconciles to prevent teleport-cheats.

This question is the entire decision tree. Apply it to every field, no exceptions.

The decision matrix

The canonical state-ownership table for a typical 3D action game. Use this as your starting point and extend per game.

State field Owner Why What an attacker could do if you got it wrong
health host core combat integrity edit memory → infinite HP, ignore damage
mana / stamina host gates ability/sprint use infinite-cast spam, infinite-sprint
score / kills / objectives host competitive integrity self-award kills, fake leaderboard
inventory contents host items must not dupe broadcast "I picked it up" twice → duped item
currency (gold, gems) host trade exploits mint currency on the client
ability_cooldowns host gates damage rate spam-cast every frame
current_weapon equipped host tied to inventory and damage tables swap to "best gun" without owning it
team_assignment host balance + friendly fire switch sides mid-match
ready_state (lobby) host match-start gating force-start with one player
chat_messages host-relayed moderation hooks, profanity filter bypass mute, broadcast to muted peers
position client-predicted, host-reconciled input latency feels awful otherwise speed-hack, teleport — reconciliation catches both
velocity client-predicted, host-reconciled same as position same as position
look_direction (yaw/pitch) client cosmetic; host doesn't need it for hit-reg if you raycast on host cheating here doesn't help
animation_state client visual; can lead the truth wrong anim = visual glitch, not exploit
footstep_audio client host doesn't care spam → mild annoyance, not exploit
particle_fx / muzzle_flash client host doesn't care same
aim_assist_target client local UX spoofing it only hurts the spoofer

Read the full file on GitHub · 333 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 10d ago First seen · 333 lines · 73 tokens per session scan A 962e9505bbfa

Subscribe to this mod's changes

host-authoritative-state is a skill published in the GitHub repository ouzlifaneyassine1-dot/onyx-engine (0 stars, last pushed 2mo ago), licensed MIT. It adds 73 tokens to every session and 4,494 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. It is 89% identical to host-authoritative-state, differing in 18 lines, and is treated as a copy.

Related

Other skills, from other repositories

host-authoritative-state

Use when designing the state layer of a multiplayer Summer game: deciding what the host owns, how clients request changes, and how the host validates and broadcasts. Pairs with /peer-to-peer-multiplayer. Trigger on "host authority", "authoritative state", "state ownership", "MP cheating", "client validation", "RPC…

SummerEngine/summer-engine-agent · 74 tokens

peer-to-peer-multiplayer

Use when starting a multiplayer Summer game from scratch with peer-to-peer host authority. Build the network architecture top-down so authoritative state, routing rules, and real-time rendering are not bolted on later. Use before writing game logic, not after. Trigger on "multiplayer", "peer-to-peer", "p2p", "co-op"…

SummerEngine/summer-engine-agent · 88 tokens

setup-multiplayer

Use when the user wants to add multiplayer to an existing Summer game: co-op LAN, co-op online, competitive PvP, or a lobby. Start with Summer Engine's high-level MultiplayerAPI plus MultiplayerSpawner and MultiplayerSynchronizer; use custom networking only with a justified reason. Walks peer authority, RPC patterns…

SummerEngine/summer-engine-agent · 125 tokens

gameobject-component-destroy

Destroy one or more Components from a target GameObject. Missing (null) components are skipped — they cannot be destroyed. Use 'gameobject-find' and 'gameobject-component-get' to identify the components first.

IvanMurzak/Unity-MCP · 49 tokens

unity-version-split

Split a C# file into Unity 6.5+ and pre-Unity 6.5 variants. Use when a file needs different implementations for different Unity versions due to API changes (e.g., EntityId vs int, GetEntityId vs GetInstanceID).

IvanMurzak/Unity-MCP · 59 tokens

godot-signals-groups

Build event-driven, decoupled Godot 4.7 gameplay with signals and node groups: declare and emit custom signals, connect with Callables (incl. bind/one-shot), and broadcast to many nodes via groups and callgroup. Use when wiring node communication in a Godot project, replacing tight references with signals…

gamedev-skills/awesome-gamedev-agent-skills · 95 tokens