The short answer
Choose AI assistance for GDScript by how accurately it handles your engine version, scene structure, and verification checks—not by a universal model ranking. In GDSense, Standard, Thinking, and Max are the public reasoning controls; the server manages the underlying model lineup. Start with a focused task and escalate depth only after supplying the evidence the answer needs.
What makes an AI answer good for GDScript?
A useful answer is compatible with your Godot version and your actual project. It should name the relevant node types, preserve scene and signal contracts, and identify what you must run to verify it. Fluency alone is not a pass: a convincing answer can reference an old API, invent a node, or miss a lifecycle problem.
Check unfamiliar methods in the matching Godot class reference. For example, advice written for an old TileMap API is not automatically valid for TileMapLayer. Ask for the exact class and method involved rather than accepting a generic claim that a snippet is “Godot compatible.”
- Uses the stated engine version and the correct node or resource class.
- Distinguishes observed facts from missing scene or runtime information.
- Preserves requested interfaces, signal payloads, and data formats.
- Proposes a small reviewable change and a test of the original behavior.
- Acknowledges uncertainty instead of claiming to have run your project.
When should I use Standard, Thinking, or Max?
Use Standard for a local question, Thinking when several pieces of evidence interact, and Max when a difficult design decision warrants deeper analysis. These are task-selection guidelines, not guaranteed correctness or benchmark scores. Workflow choice remains separate: Chat can handle analysis without asking Agent to change the project.
Mode availability depends on the plan, and deeper modes consume more credits for the supported request paths. The current mode reference and Pricing page are the source of truth for access and costs. Do not assume Explain or autocomplete has the same routing or charging behavior as a selected Chat mode.
| Task | Starting point | Evidence to provide |
|---|---|---|
| Explain a typed assignment or small function | Standard | Selected code, exact warning, expected type |
| Find a signal-order or scene-reload bug | Thinking | Emitter, receiver, lifecycle, reproduction |
| Compare save-system boundaries and migration risks | Max if available and justified | Current format, failure cases, compatibility constraints |
How can I compare answers without a misleading benchmark?
Build a small evaluation set from your own project and keep the starting code, prompt, attachments, and expected behavior fixed. Compare the work required to reach a correct result, not how verbose the answer sounds. One lucky answer or one failure does not establish a permanent ranking.
Use a disposable copy for edits. For each attempt, note whether it parses, passes the gameplay checks, changes only the allowed files, and explains the cause accurately. Record your review time and credit use separately. A fast answer that needs extensive repair may not be the cheapest completed task.
| Fixture | Success check | Common failure to reject |
|---|---|---|
| Enemy scene runs without its usual Player sibling | Missing target handled deliberately; normal pursuit still works | A null guard silently hides required setup |
| Health signal updates a HUD | One update per health change, correct payload, correct initial value | Duplicate connection or missing initial render |
| Damage function cleanup | Normal, critical, zero-damage, and over-armored results unchanged | Changed clamp order or rounding |
What should I do when the first answer is wrong?
First determine whether the answer lacked evidence, used the wrong API, or misunderstood the contract. Add the smallest missing input and ask for a corrected explanation. Increasing reasoning depth without fixing a wrong scene path or omitted signal connection asks the model to reason harder about the same incomplete problem.
The proposed fix still fails after reopening the inventory.
The receiver is recreated on each scene load; the emitter is an Autoload.
Here are the connection code, teardown code, and two debugger log lines.
Trace the second-open lifecycle. Do not change the item format or add polling.
State which assumption in the previous answer was wrong and how to test the correction.Keep in mind: If the task is changing while you compare attempts, you are evaluating different problems. Reset the fixture or label the new attempt as a different test.
Why does GDSense document modes rather than a fixed model leaderboard?
GDSense routes public reasoning modes through a server-managed lineup. Provider, deployment, and raw model identifiers can change. A published ranking would age independently of the workflow you use, while a repeatable verification method remains useful as routing evolves.
Choose the shallowest mode that solves the real task reliably, check current access before sending, and keep control of the final diff. No mode removes the need to validate GDScript in the intended engine and scene.
Current GDSense plans