A few rules apply across the entire environment. They are standard executor behavior, and reading them once here saves repeating them on every page.

​
Yielding functions

Some functions yield the calling thread while work happens off-thread. Network requests, WebSocket connects, console input, and saves are the common cases. A yielding call resumes on the same thread once the work finishes. A yielding function can only be called from a thread that is allowed to yield. Calling one from a context that cannot yield, such as a metamethod the engine invokes synchronously, errors in the usual Luau way.

​
Thread identity

Athena runs your code with an elevated identity. Functions that read or write through the game, such as the reflection library, protected properties, and game:HttpGet, depend on it. When you create new threads with task.spawn, coroutine.create, or similar, Athena marks them as yours so caller checks keep working. Threads the game created are never marked as yours.

​
Actors and parallel execution

Athena can run code inside Actor Lua states, which are separate VMs from the main one. Two points matter for scripting. Scheduling work onto an actor, with run_on_actor, run_on_thread, or LuaStateProxy:Execute, is refused from inside a parallel phase. Schedule from a serial context. State created in one VM (tables, functions, threads) does not exist in another. Values crossing between VMs are deep-copied, and instances are re-resolved. The executor global is per-VM, so reading getgenv() inside an actor returns that actor’s executor global, not the main one.

​
Error style

When a function rejects its input it raises a Luau error with a specific message. The per-function Errors table lists every message a call can produce and the exact condition behind it. Guard against the condition, not the message text, since messages may be refined between builds.

​
Instances across the cache

Instances handed back by the environment are routed through the engine’s instance cache, so a given game object is represented by one userdata. This is what makes == between two references to the same instance behave as expected, and what cloneref works around when you need a reference that compares unequal.