Has the Rotterdam port backlog cleared after Storm Austen?
Six container ships were at anchor off the Maas entrance, the mouth of the port of Rotterdam, when Claude Sonnet counted them on the evening of 1 November. A second run with a wider search box found ten, and judged that eight of them were waiting for Rotterdam. Storm Austen had closed the port a week earlier, from 23 to 25 October. Asked whether the Rotterdam port backlog had cleared, the second of the two runs that found six wrote that its figures suggest "the storm queue has mostly cleared". Most of the ships it dated had waited a day or two.
Data from live runs on 1 November 2026. Series: Hub: What can an AI agent answer from an AIS API via an MCP server? · Part 1: Are US Gulf crude tankers arriving laden or in ballast? · Part 2: How long are ships waiting at Durban anchorage? · Part 3: Has the Rotterdam port backlog cleared after Storm Austen?
Kuehne+Nagel's port update for 21 to 27 October reported that the port "experienced full closure from 23 to 25 October due to high winds and bad weather". It also reported yard occupancy of 85% at ECT (Europe Container Terminals) and barge and feeder delays of 12 to 72 hours there. A feeder is a smaller container ship that shuttles boxes between hub ports and regional ones. The same update gave a 7-day average vessel waiting time of 1.36 days. A separate Kuehne+Nagel article on Storm Austen said operations at APM Terminals Rotterdam were "set to be temporarily suspended over the weekend due to forecast high winds".
Six runs, three prompts, one 80-request cap
Each run was one non-interactive call to Claude Code in an empty directory. Its only tools were the 19 from vesselapi-mcp, the MCP server for the VesselAPI AIS API. They return live positions, vessel records, port calls and the ships declaring a port as their destination. User settings and Claude Code's built-in tools were switched off. The hub has the setup and the full method. We capped every run at 80 API requests for the test, and each count below is what that one run found.
The plainest prompt asked for three numbers:
Rotterdam's container terminals were closed by a storm from 23 to 25 October. Has the backlog cleared? How many container ships have arrived since the terminals reopened, how many are still waiting at anchor, and how many are due in the next three days?
The second prompt added one instruction:
Look up the type of each ship at the anchorages off the Maas entrance so you can separate container ships from the rest, and use as many calls as you need.
A third prompt asked for the ships themselves:
Rotterdam's container terminals were closed by a storm from 23 to 25 October. Which container ships are waiting at the anchorages off the Maas entrance right now, how long has each been waiting, and when are they due alongside?
| Run | Model | Prompt | Tool calls | API requests served | Time | Container ships at anchor |
|---|---|---|---|---|---|---|
| Queue | Sonnet | which ships, how long | 30 | 30 | 70 s | 6 |
| Plain 1 | Sonnet | three numbers | 6 | 6 | 34 s | no count |
| Plain 2 | Sonnet | three numbers | 5 | 5 | 26 s | no count |
| Plain 3 | Haiku | three numbers | 32 | 32 | 68 s | 1 (called a floor) |
| Typed A | Sonnet | look up each type | 82 | 80 | 149 s | 10, of which 8 for Rotterdam |
| Typed B | Sonnet | look up each type | 92 | 80 | 233 s | 6 |
Both typed runs reached the cap. Typed A had 2 calls refused and Typed B had 12. Each refused call returned the server's message to stop and tell the user. Typed B made 11 more lookups after the first refusal, one after another, because the prompt's "use as many calls as you need" outweighed it. For agent builders, a hard budget belongs in the system prompt or in the client.
Two Sonnet runs declined to count
Sonnet took the plain prompt twice and stopped after 6 and 5 calls. Both read one page of port events, the first page or two of the inbound list and one position search. A ship's type sits in its vessel record by design, one get_vessel call per ship, and both runs worked out that a full count meant hundreds of such calls. The first wrote: "That's a few hundred calls, mostly lookups. Do you want me to go ahead, and can you confirm the reopening time?"
The first run went as far as "My provisional read is that the backlog looks cleared." It rested that on 50 position rows within 30 km of the entrance. The second asked for 5 rows and wrote: "I haven't counted the anchorage, so I can't say it has cleared." In claude -p that question ended the run.
Why Haiku found one container ship
Haiku took the same prompt further. It read one page of 50 position rows from a box over the anchorage, reported 23 ships at anchor and looked up 22 of their types. It reported one container ship and called that figure a floor.
Two things set its count apart from the Sonnet runs. Its box stopped short of the western anchorage, where four of the other runs' six container ships lay. Inside its box was a second ship the Sonnet runs counted. It was over 350 m long with a generic "Cargo" label. Haiku put that one with the "other cargo vessels". It counted only the record that said "Container Ship".
Telling a container ship from a "Cargo" record
AIS ship-type codes, set out in ITU-R M.1371, have no value for container ships. Their cargo-ship group (codes 70 to 79) covers container ships, bulk carriers and general cargo ships alike, and many vessel records carry the matching "Cargo" labels. Of the six ships Typed B counted, one was labelled "Container Ship". It placed the other five, in its words, by "name, length and tonnage", and marked them "probable".
Gross tonnage (GT) measures a ship's enclosed volume. Deadweight tonnage (dwt) is the weight it can carry, cargo and fuel included. A container ship carries light, bulky cargo, so its dwt stays close to its GT. A bulk carrier's dwt runs to nearly twice its GT. The ratios below come from the get_vessel records of the "Cargo" ships Typed B looked up at anchor.
| Ship | dwt ÷ GT | Typed B |
|---|---|---|
| Over 350 m | 0.9 | counted |
| Over 350 m | 1.0 | counted |
| 330 to 340 m | 1.1 | counted |
| 330 to 340 m | 1.2 | counted |
| About 250 m | 1.3 | counted |
| About 150 m | 0.9 | not counted |
| About 170 m | 1.2 | not counted |
| 200 to 230 m (two ships) | 1.8 and 1.9 | not counted |
The ratio separates the two 200 to 230 m ships, which Typed A's emissions check below identified as bulk carriers. It does less at the small end. Two ships under 200 m had ratios of about 0.9 and 1.2, inside or below the counted range, and were left out on size and name. Low ratios are not unique to container ships either. Two inbound ships Typed B took for car carriers had dwt near 0.4 times GT, and it left them out as car carriers.
Typed A added a second check. Ships of 5,000 GT and over calling at EU and EEA ports report their annual emissions under the EU MRV (monitoring, reporting and verification) rules, and get_vessel_emissions returns that report with a ship type. Typed A called it once for each of the 11 anchored ships with a "Cargo" label. Seven of the 11 returned a report: five said container ship and two bulk carrier. One of the five was a ship of about 150 m that the size test alone would have left in doubt. The 11 calls came out of the same 80-request budget, and the run reached the cap before it had looked up any inbound ship.
Search box size and the Rotterdam port backlog count
The queue run and Typed B searched overlapping boxes off the entrance and found the same six container ships, though in the queue run one of them was drifting at about 1 knot and not formally at anchor. The queue run got the types from get_vessel_position, which returns the vessel record with the position. Typed A's box reached further south and north, and it found 55 ships at anchor against Typed B's 31. All four of its extra container ships lay outside Typed B's box. Typed A then removed two of them from the backlog, on the evidence of their recent port events. It wrote: "They are probably waiting for their next port, so I'd leave them out of the Rotterdam backlog."
That leaves eight for Typed A and six for Typed B. The difference is two ships in the southern part of Typed A's box, a container ship of 170 to 190 m and a smaller one.
How long the container ships had waited
AIS gives a ship's status at each report, and the time it dropped anchor has to be worked out from earlier data. Both typed runs dated waits from port events instead of position history. They took each ship's last departure from get_port_events_by_vessel and added a likely passage time. Typed B called the results "rough estimates from each ship's last port departure plus sailing time".
By that method most of the six had waited one to two days. Two ships over 350 m had upper bounds of about five and six days, which would put them at anchor since soon after the closure. Typed B wrote: "These two may be the only holdovers from it."
Typed A agreed on the larger of those two and named a second holdover, the mid-size container ship from its wider box. It could not date two ships, because their port-event calls came after the cap. It said the rest "looks like a normal queue".
Both runs that pulled position history ran into the same ordering. Positions come newest first. The queue run asked for 50 rows for four ships since 25 October and got the last 41 minutes. Typed B asked for 5 rows for one ship and got the last 24 minutes. To see whether a ship was at anchor days earlier, a call needs a timeTo inside that earlier window. Part 2 uses that sampling method in full at Durban. The queue run gave no waits, and proposed the same fix: "poll this area on a schedule and record when each ship first shows zero speed and anchored status."
The inbound list to 4 November
get_port_inbound for NLRTM looks 72 hours ahead by default and is ordered by ETA. Typed B read all of it: three pages and 148 rows through the afternoon of 4 November. In the agent's reading they were mostly barges and small tankers. It looked up 35 ships. Seven records said "Container Ship". It rated five more probable by size or name and left two unconfirmed. Its answer was "12 to 14" container ships due, about nine of them by the end of 2 November. Twelve lookups were refused by the cap, and it listed nine inbound ships it had not checked.
Typed A read one page, ETAs to early on 2 November, and gave no number. Haiku set etaFrom to midnight, so its two pages held ETAs from earlier that day, mostly before the run started. Typed B and Haiku both described the ETAs as the ships' own declarations.
The anchorage and the inbound list compete for one budget. Typed A spent 54 lookups on its 55 anchored ships and 11 on emissions reports, and had none left for the list. Typed B's smaller box left room for 35 inbound lookups, and it still ran out about a dozen short.
Series: Hub: What can an AI agent answer from an AIS API via an MCP server? · Part 1: Are US Gulf crude tankers arriving laden or in ballast? · Part 2: How long are ships waiting at Durban anchorage? · Part 3: Has the Rotterdam port backlog cleared after Storm Austen?
Claude, Claude Code, Sonnet, Haiku and Anthropic are trademarks of Anthropic PBC. Other names are trademarks of their respective owners.