Behavioural-AI startup Godot Inc. is bringing infrared.city’s climate layer (the wind, heat, sun and shade of real streets) into its simulations, reachable through a single API call at interactive speed.

Who this is for

Product teams and platforms that need climate feedback at decision-making speed inside their software, without the opportunity cost building and maintaining a climate-simulation engine:

• Digital twins and simulation platforms that want microclimate (wind, heat, sun and shade) as a ready data layer.
• AI and agent products whose models need real conditions to reason about.
• Design, planning, sport, events, safety and risk tools that need environmental realism on demand, per location and per hour.

A physical world view for behavioural AI

Godot Inc., based near Kobe, builds behavioural AI: it simulates thousands of possible futures to show how a decision plays out across public health, communication and crisis management. Its work reaches the World Health Organization and the Government of Osaka.

infrared.city runs the other side of the problem: the wind, sun, heat and shade of real streets, computed in seconds on the cloud, easily accessible through an API, a far leap from the conventional microclimate studies that take specialized teams days to compute locally.

One layer was missing

A behavioural model can tell you how a crowd moves, where a runner tires, how a neighbourhood responds to a warning. But it needs to draw behaviour from rich data including what the crowd feels like in the space. A 32 °C afternoon in full sun on dark asphalt and the same afternoon under a row of trees are two different events to a human body, and that affects their response. That gap between air temperature and felt temperature spatial map is exactly of what infrared.city computes. Microclimate simulations mean the behavioural model gains a real environment to react to.

A marathon you can feel before you run it

The first thing the two teams built together, with the sportswear company Asics, is a simulator for a marathon, with its first course a route through Kobe, Japan. A runner picks a pacing strategy; the model plays it back against that course: its distance and elevation, its heat, its wind, its humidity, and the moving line of shade the buildings throw across the road as the morning wears on.

The exposed stretches (the wide boulevards with no canopy, the sun-facing embankments) read hot; the shaded, tree-lined segments read kind. Where a runner meets the hard part of the course stops being a guess and becomes something you can see on the map before the gun goes off.

Figure: One layer of the basis. The felt-temperature field the engine returns for a single scenario — computed once per condition and looked up in place ahead of race day.

Read it the other way and it becomes an organiser’s tool. The same map that warns a runner also shows the race director which segments will need water, shade or a misting arch, and roughly how much relief each one buys. It puts the behavioural question (what will people do here) and the physical answer (what will it feel like here) on a single screen.

Figure: The sun layer of the same basis. How much of each kilometer runs in sun rather than shade, solved once and read off in place. Here, 91% of the route is in full sun.

What it takes to make a course queryable

For a behavioural model to try thousands of runner strategies, the physical answer has to come back at once, which rules out solving race-day weather on the spot. So Infrared City ran the simulations ahead of time and left behind something the behavioural layer could look up: a basis of physical conditions along the course, wide enough to cover whatever the morning turns out to be.

The Kobe course was broken into 136 points. At each one, the engine resolved three physical layers (thermal comfort, wind and shade) and swept each across the range a race morning can bring.

Thermal comfort · UTCI: 10 scenarios drawn from Kobe’s own weather in the 9–11h window: the three coldest mornings, the three hottest, and the 20th, 35th, 50th and 65th temperature percentiles. Each carries its own humidity, wind and solar radiation.

Wind speed · rose: 8 directions in 45° steps, north through north-west, at a unit reference speed, so any forecast wind can be matched to the nearest sector and scaled to strength.

Shadow · morning series: 15 min steps of the shadow mask across the race morning, capturing the moving shade the buildings throw over the road as the sun climbs.

On race morning the live forecast (temperature, humidity, wind speed and direction) is matched to the nearest precomputed scenario: closest temperature first, then humidity, then wind for thermal comfort, and the nearest of the eight sectors for wind. The behavioural model then reads felt conditions at any of the 136 points, for any runner at any pace, with no new simulation to wait for. Every field is solved once, through the same engine, and served over the infrared.city API.

One engine, delivered as a layer

Figure: The route as a comfort profile. At pedestrian level the engine resolves felt temperature street by street — the exposed stretches read hot, the shaded ones read kind. The same read turns a course into a kilometre-by-kilometre comfort map, and a race day into a scenario a runner can rehearse.

The physical layer arrives as an API call. Infrared.city runs eleven microclimate models behind a single engine, and hands back the results other products build on: wind and pedestrian wind comfort, thermal comfort and its statistics, solar radiation, direct sun hours, daylight, sky view factor, and the ground materials that drive how a surface heats. Ask for a polygon; get back a grid.

A single conventional CFD solve takes hours to days to set up and run; here, a wind field returns in about a third of a second, pedestrian wind comfort in about four, and thermal comfort in under five. Fast enough that a behavioural model can call it in a loop, and a person can change the scene and watch the answer move.

The basis behind this marathon (ten thermal-comfort scenarios, an eight-direction wind rose and a morning of shadow steps, sampled along 136 points of the course) was stood up in weeks. Built the conventional way, where the wind rose alone is eight CFD runs at hours to days each, the same coverage would take months before the behavioural team had anything to query.

The whole physical basis was live and queryable in weeks: one API call, no simulation pipeline to build first. That is the difference between adding a layer and building one.

What it adds up to

A partnership that began with a hallway introduction in Osaka now ships a working product with a global sportswear brand: a marathon a runner can feel before the gun goes off. The behavioural model needed a real world to act in, and the climate model needed the people it was always describing.

And the method travels. A course becomes a comfort profile the same way a district or a public space would: precompute the physical layer across the conditions that matter, then let the product that knows the people look it up. For any team already modelling how people behave, that is the smaller lesson: the physical world is now a layer you can add.

Add a climate intelligence layer to your product

Whether it starts as an idea or ships in a production platform, infrared.city gives whatever you build a real physical environment. One engine returns wind and pedestrian wind comfort, thermal comfort, solar radiation, direct sun hours, daylight, sky view factor, resolved at street scale and returned in seconds. It arrives as a single API and SDK you call.

• Start building: SDK and docs at infrared.city Platform — Urban Climate Analysis
• Talk to us about an integration: info@infrared.city

infrared.city: the climate intelligence layer for cities and buildings