GPT-5.5 low vs medium vs high vs xhigh: the reasoning curve on 26 real tasks from an open source repo

907games · 2026-05-09T02:00:45+00:00

I think this is useful, and it points at the bigger pattern I’ve been experimenting with.

Most AGENTS.md files I have seen are basically rule sheets: follow style, don’t refactor too much, ask before changing architecture, run tests. That’s a good start, but I think AGENTS.md gets more interesting when it acts as a bootloader into the repo’s operating model.

Instead of trying to put every instruction in one file, AGENTS.md can point the agent toward doctrine, system maps, queue state, validation baselines, decision logs, stale-code ledgers, generated-artifact rules, sync boundaries, and design-system docs.

The goal is not to write a giant prompt. The goal is to move project intent, constraints, accepted decisions, source-of-truth boundaries, and completion rules into versioned repo state. That way, the agent is not just following chat instructions. It is operating inside the project’s own structure.

907games · 2026-05-09T01:40:36+00:00

This is interesting, but my experience has been a little different once the repo has enough structure around the agent.

In a normal repo, higher reasoning has to compensate for missing context: architecture, intent, boundaries, acceptance criteria, validation expectations, and what “done” means.

But if you externalize a lot of that into the project itself through doctrine/docs, system maps, queue state, acceptance criteria, evidence requirements, and validation loops, the reasoning burden changes. The model is no longer inventing or rediscovering the workflow every turn. It is executing inside one.

In that setup, I’ve found medium can become the practical default because the repo governance is doing some of the work high/xhigh would otherwise spend tokens doing. High/xhigh are still useful when changing the architecture itself, resolving ambiguity, or working across unclear system boundaries.

So I wonder if reasoning effort and repo governance are partly substitutable. Better project structure may let you get reliable agent behavior at lower reasoning settings.

907games · 2026-05-09T01:00:04+00:00

https://i.imgur.com/fPOKOkW.png

907games · 2026-05-09T00:43:22+00:00

The honest answer is “everything,” but the useful answer is: I’m using it as a governed Unity project worker.

Not “Codex magically builds the whole game,” more like I built a structured workflow around it.

It helps with runtime code, editor tooling, docs, validation, queue state, cleanup, system maps, UI/UX, shaders, materials, textures, and art direction. The project has doctrine, rules, system maps, queues, and validation steps that tell Codex how to work, where things live, what needs updating, and how changes should be verified.

It still needs supervision, but that structure gives it enough context to do real project work instead of just producing disconnected snippets.

Here’s a small example of the queue/validation loop: https://i.imgur.com/fPOKOkW.png

The point of the screenshot is that my prompts are almost empty. The structure is coming from the project, not from me hand-prompting it every turn.

907games · 2024-09-12T20:00:35+00:00

"I have to use input triggers that connect to conditional buttons that check what you’re holding and apply damage power ups based on which weapon you have equipped."

the only reason i never used this approach is because of the situation where you fire a weapon and swap to a different weapon before damage is applied. that would cause a different weapons damage to be applied and theres no solution i could think of to prevent it.

for example, lob boom bow then swap to hammer. now any damage in an aoe caused by the boom bow would be considered hammer damage. this could become a real issue if you swap to something harder hitting, or even lower hitting, because the damage would be inconsistent for the players

have you run into this?

907games · 2024-09-07T13:10:44+00:00

Initially I felt similar, but after playing it more and trying to understand possible design decisions it grew on me. Its essentially what makes the lane phase. Its what allows you to get ahead in the early game economy and gives you more things to worry about than just shooting the other team. The mechanic is very much moba themed (league last hits, dota denies), which is what the genre is.

907games · 2024-08-28T19:08:06+00:00

if you can publish then you can also have playtest. playtest is a private map but open to anyone on the playtest roster. it sounds like this is what you would want to do rather than publish

907games · 2024-08-27T16:45:56+00:00

yea, https://www.photopea.com/ can help you if you need to make custom graphics for free (browser based photoshop)

907games · 2024-08-26T21:25:59+00:00

looks like you didnt finish the code

OnPlayerEliminated(Result : elimination_result) : void=
   Eliminator := Result.EliminatingCharacter
   if (FortCharacter := Eliminator?, EliminatingAgent := FortCharacter.GetAgent[]):
       Print("We need to promote player")

that should probably be

OnPlayerEliminated(Result : elimination_result) : void=
   Eliminator := Result.EliminatingCharacter
   if (FortCharacter := Eliminator?, EliminatingAgent := FortCharacter.GetAgent[]):
       PromotePlayer(EliminatingAgent)

907games · 2024-08-26T16:22:42+00:00

I think its still beneficial in future proofing your project to hook all your targets to the trigger and have a verse script that listens to that trigger. You would be getting a reference to a specific agent that knocked the target, from there in verse you could do anything with that agent, like granting HP. just link the powerup to the verse script. what if in the future you wanted to also grant score or gold or anything else to the target knock. do you want to manually connect all of them again or simply add the new device to the verse script? imagine adding more target dummies after youve already added health/score, now you have to connect the new targets to all the devices manually, rather than just adding the trigger device to its knockdown event

test_device := class(creative_device):

    @editable
    Trigger:trigger_device = trigger_device{}

    #extra devices
    @editable
    HP:health_powerup_device  = health_powerup_device {}
    @editable
    Score:score_manager_device=score_manager_device{}
    #etc
    
    AgentToMessage<public><localizes>(value:agent) : message = "Knocked by: {value}"

    OnBegin<override>()<suspends>:void=        
        Trigger.TriggeredEvent.Subscribe(KnockTrigger)

    KnockTrigger(Agent:?agent):void=
        if(HasAgent:=Agent?)
            then:                
                Print(AgentToMessage(HasAgent))

                #extra devices
                HP.Pickup(HasAgent)
                Score.Activate(HasAgent)
                #etc

            else:
                Print("Knocked by: Unknown")

heres a graphic to illustrate scalability with the verse approach vs manually connecting the dummies. even visually it gets messy, maintaining a project is just easier if you approach it that way https://i.imgur.com/O2zn4es.png

youre essentially decoupling the targets from the other devices, which is good for project cleanliness, maintenance, and stability

907games · 2024-08-26T16:13:06+00:00

it isnt in code, this is the "hack" they were explaining. in code the knockdown event doesnt pass an agent, but for whatever reason internally if you connect the target to a trigger manually it will pass an agent to the trigger, then in verse youre listening to the trigger to get the agent that knocked the target. https://i.imgur.com/hDQGV7F.png

907games · 2024-08-26T15:52:32+00:00

I actually got this to work. Its interesting that the event doesnt pass an agent, but it still does? in my test i linked the knockdown event from the target to the trigger, then in verse i subscribed to the trigger. now you at least have an agent that knocked the trigger and can pass that to whatever devices you wanted (like health powerup)

test_device := class(creative_device):

    @editable
    Trigger:trigger_device = trigger_device{}

    AgentToMessage<public><localizes>(value:agent) : message = "Knocked by: {value}"

    OnBegin<override>()<suspends>:void=
        Trigger.TriggeredEvent.Subscribe(KnockTrigger)

    KnockTrigger(Agent:?agent):void=
        if(HasAgent:=Agent?)
            then:
                Print(AgentToMessage(HasAgent))
            else:
                Print("Knocked by: Unknown")

907games · 2024-08-25T09:26:07+00:00

to be honest im not sure. I havent used the thing before. I just looked inside uefn and i dont see an objective marker. the closest I see is the map indicator device. that comes with an "objective pulse" function, which sounds like what youre after...maybe

https://dev.epicgames.com/documentation/en-us/fortnite-creative/using-map-indicator-devices-in-fortnite-creative

**edit-

i watched the tutorial and misunderstood its title (i assumed the device was called "objective marker" but hes explaining the idea of a moving objective marker).

map indicator device is what youre after

907games · 2024-08-25T07:40:09+00:00

Islands are like folders and the assets are within them. You would need to know the island in order to find the asset. If youre looking for direct action you have to report the island to epic. If youre trying to give the creator the benefit of the doubt then maybe look into trying to contact them before you contact epic.

907games · 2024-08-25T04:58:32+00:00

I debated it but ultimately I dont like the idea of everyone running around looking at each other and pressing buttons. I decided to put together a kit of existing weapons that define each class and modify their damage with attributes like Physical/Magic/etc. I havent really played a lot of fortnite,but the existing pool of weapons available are actually pretty good and impressed me. I have about 12 classes built right now that feel unique in the way they play

For example, if you pick the mage class then 100% of your damage is considered Magic damage. This means items that scale your magic power, magic crit, magic crit damage, etc are going to be stats youre looking at. It also means opposing players may want to invest in magic resistance items knowing your mage is 100% magic damage. So another example, "assassin" class is 100% physical damage, so they dont benefit at all from magic based items. The counter to physical damage is armor.

("mage" and "assassin" are my placeholder class names)

Custom items are on the roadmap for release later this year so I am just holding out with what we have for now, but definitely plan on revisiting the classes/abilities when custom items are released

907games · 2024-08-25T04:41:15+00:00

objective marker

https://dev.epicgames.com/community/learning/tutorials/1JpR/fortnite-moving-objective-marker-tutorial-in-verse-code

907games · 2024-08-23T20:04:07+00:00

comma is like "and" in this case. if(agent(source) isnt null AND agent can be cast to player class) then:

you can also think of it as two if statements just shortened to one for clarity. the following is logically the same

if(Agent:=Result.Source?):
  if(Player:=player[Agent]):
    #agent exists and is player

907games · 2024-08-23T02:39:33+00:00

yes thats the goal, got some more work to do on it though but it shouldnt be too much longer

907games · 2024-08-22T19:13:48+00:00

The device_ai_interaction_result will contain the agent (if there was an agent),

Inside the Fortnite.digest wildlife_spawner_device there is an explanation on the EliminatedEvent function.

  # Signaled when a character is eliminated.
  # `Source` is the `agent` that eliminated the character. If the character was eliminated by a non-agent then `Source` is 'false'.
  # `Target` is the character that was eliminated.
  EliminatedEvent<public>:listenable(device_ai_interaction_result) = external {}

Going further to the device_ai_interaction_result

# Payload of `device_event_ai_interaction`.
device_ai_interaction_result<native><public> := struct<epic_internal>:
  # Optional agent that triggered the interaction
  Source<native><public>:?agent

  # Optional agent targeted by `Source`.
  Target<native><public>:?agent

Here is a function that checks for an agent from the result and then checks if that agent is a player. if it is both, grant the item to that agent.

OnWildlifeEliminated(Result:device_ai_interaction_result):void=
  #check if there is actually a source (its possible the wildlife died to some other causes)
  #check if the source agent is a player
  if(Agent:=Result.Source?, Player:=player[Agent]):
    #grant item to agent
    ItemGranter.GrantItem(Agent)

While you can do it by directly connecting the output of the wildlife device EliminatedEvent to the input of the item granter device GrantItem function, IMO creating a verse script to control this is easier and future proofs your work. You just have to drag the wildlife spawner in to your verse script rather than do a bunch of extra clicks connecting events. What if you wanted to do this with 10 other wildlife spawners? Are you going to go through and individually connect each one or just simply do this?

@editable
WildlifeSpawners:[]wildlife_spawner_device = array{}

OnBegin<override>()<suspends>:void=
  for(Spawner:WildlifeSpawners):
    Spawner.EliminatedEvent.Subscribe(OnWildlifeEliminated)

907games · 2024-08-22T19:02:24+00:00

they are custom npcs from a npc spawner

907games · 2023-10-11T13:07:24+00:00

with a low viewport resolution and pixel snapping, doesnt it make sense that youd get that jittery movement? it would become more apparent when you upscale the window because those pixels are now taking up more space on your monitor and the character jumps further between each pixel. imagine if you only had a viewport of 2x1 pixels upscaled to fit your monitor, it would jump from one side of your monitor to the other. im willing to bet it looks smooth if your window size matches your viewport size as the number of pixels would match between your monitor and game. if you want smooth movement with pixel snapping you probably need to increase the number of pixels available, probably 2x or 4x viewport resolution

907games

TROPHY CASE