Almost every scheduling and planning vendor now sells "AI". Some of it is genuinely new: machine learning models that predict running times by time band, or ridership models that estimate the effect of a network change before it goes live. Some of it is decades-old operations research with a new label. And some of it, especially anything described as "real-time network rebalancing", is still mostly at the pilot stage.
For a transit agency or operator, the useful question is not "should we use AI?" but "which planning task, which algorithm, fed by which data?". The answer to the last part is the same almost every time: the algorithm is only as good as the actual (as-run) data coming out of the AVM or CAD/AVM system. An optimiser fed with scheduled running times, rather than measured ones, will produce a very precise answer to the wrong question.
This article separates what is operational today from what is marketing, with verified examples from London, the Nordics, Spain and North America.
What "AI" actually covers in bus planning
| Planning task | Typical technique | Maturity in operations | Data it depends on |
|---|---|---|---|
| Running-time calibration | Statistical analysis, machine learning on historical trips | Mature, widely used | AVM segment running times by time band |
| Vehicle and crew scheduling (blocking, duties) | Mathematical optimisation (operations research) | Mature since the 1990s | Timetable, running times, labour rules |
| Frequency setting | Load profiles plus optimisation or rules | Common, often semi-manual | APC loads, ticketing, AVM punctuality |
| Demand and ridership forecasting | Machine learning, travel models, third-party mobility data | Growing, used for scenarios | Ticketing, APC, census, mobile data |
| Network redesign | Human-led design supported by scenario tools | Tools mature, design remains human | All of the above |
| Real-time rebalancing (holding, short-turning, extra vehicles) | Rules, decision support, some ML | Controller-led today, algorithmic control mostly in pilots | Live AVM positions, headways, loads |
Two points stand out. First, the most mature "AI" in the table, crew and vehicle scheduling, is classic optimisation, not machine learning. Second, every row depends on as-run data. Without it, none of these tools has anything real to learn from.
Running times: where the data problem starts
Running-time calibration is the least glamorous task and the one with the clearest return. Times that are too tight mean buses late all day; times too generous mean early running and paid hours the operator does not need.
This work predates the AI label. GIRO's HASTUS-ATP module, documented in 2011 and developed with Transports Metropolitans de Barcelona and the University of Barcelona, calculates optimum run times and minimum layovers from historical AVL records. In London, TfL's iBus system, which covers more than 8,000 buses, has been used to compute actual run times between timing points by time-of-day period so that operators can submit more realistic schedules, as described by Hounsell, Shrestha and Wong in Transportation Research Part C (2012).
What machine learning adds is finer granularity and the ability to combine more variables. Optibus markets "Predictive Runtimes" built on historical data, traffic patterns and weather. Its published case with the Jacksonville Transportation Authority (JTA) is instructive: on Route 30, which suffered recurring delays near a high school at peak times, JTA used vehicle positioning data from Snapper Services, cross-checked against CAD/AVM data, collected in autumn 2024. On-time performance rose from 83.4% to 94%. Note what the headline "13%" measures: it is the relative increase (94 divided by 83.4), which is about 10.6 percentage points. Both are real, but they are not the same number.
The decisive input in that case was not the model. It was a season of clean, trip-level positioning data on one problem route.
Garbage in, garbage out is measurable
Swiftly, which processes AVL feeds for many North American agencies, has published the typical failure modes. AVL update intervals longer than 30 seconds degrade arrival and departure detection. Operator login rates of 50% to 75% at some agencies mean many trips cannot be matched to a vehicle at all. Geofence-based stop detection can produce on-time performance figures up to 15% inaccurate and run times up to 30% shorter or longer than reality. Swiftly reports that Capital Metro in Austin improved its effective AVL frequency from over one minute to under ten seconds by combining feeds.
Feed a running-time model with those errors and it will confidently recommend schedules calibrated to artefacts. This is the core point of the whole topic: AI planning tools do not fix bad AVM data; they amplify it.
Network redesign and demand forecasting: tools assist, people design
The best-known network redesigns of the last decade were not produced by algorithms. Houston METRO's 2015 redesign, from a radial network to a frequent grid, was led by board member Christof Spieler with consultant Jarrett Walker and extensive public outreach. NACTO reports it was implemented with almost no increase in operating costs. The Kinder Institute at Rice University measured a 6.8% rise in total ridership in the first year, but only 1.2% on local buses, with much stronger weekend growth. Barcelona's Nova Xarxa, an orthogonal network studied by Badia, Argote-Cabanero and Daganzo (UC Berkeley, 2016), attracted more demand than the old network, with around 26% of trips involving a transfer by the end of 2015.
Where software now helps is in scenario testing. Remix (owned by Via) offers ridership predictions calibrated with real trip data from Citymapper, and since 2023 it can display Swiftly's stop-by-stop observed run times directly in the timetable editor, so planners see where actual departures diverge from planned ones. Via launched "Via Intelligence" in August 2025, presented as a vertical AI platform for planning, scheduling and operations, citing BC Transit's use of predictive runtimes and an unnamed large US agency using ridership modelling for a post-COVID redesign.
Demand forecasting also depends on what the vehicle measures. Ruter in Oslo began installing automatic passenger counting and other sensors on more than 400 buses from 2016, then moved towards an open ITxPT-based onboard architecture. In the Helsinki region, HSL publishes high-frequency positioning, with most vehicles reporting once per second and emitting stop arrival, departure and door events plus an occupancy field. That kind of granular, standardised feed is what makes load-based frequency setting credible rather than guesswork.
The honest summary: machine learning improves the forecast for each scenario. Choosing the scenario (coverage versus frequency, where to force transfers, what to tell the public) remains a political and professional decision.
Scheduling and blocking: the mature part
Vehicle blocking and driver duty construction are where optimisation has been embedded longest. HASTUS, Optibus, Trapeze and others solve large combinatorial problems (which vehicle covers which trips, how duties respect labour agreements, relief points and depots) to save vehicles and paid hours.
Two caveats matter for buyers. First, the optimiser treats running times and layovers as inputs. If those inputs come from the old timetable rather than measured data, a "more efficient" block can simply mean removing recovery time that the road network does not actually allow, which then shows up as lateness and lost trips. Second, newer generative AI features (natural language queries, assisted setup) change the interface, not the underlying maths.
Real-time rebalancing: what exists today and what is still a pilot
This is where the gap between marketing and operations is widest.
What is standard today. Control rooms already rebalance service in real time: holding a bus at a timing point, curtailing (short-turning) a late bus to fill a gap in the opposite direction, inserting a spare vehicle, or switching a high-frequency line to headway-based regulation. TfL describes curtailments as decisions where "circumstances will normally determine the best course of action", in response to a Freedom of Information request. These decisions are made by controllers using CAD/AVM displays, rules and experience. Software increasingly suggests actions, but a human decides.
What has been tested in the field. Stockholm ran regularity-driven (headway-based) operation trials on its trunk bus lines, analysed by Oded Cats in Transport Policy (2014), who concluded that regularity requires changes across planning, operations and monitoring, not only a control algorithm. More recently, the Chicago Transit Authority tested a headway control decision support system on Route 81 (October 2022, terminal holding) and Route 66 (November 2023, en-route holding). Wait times fell by 8.7% in the AM peak and 19.9% in the PM peak on Route 81, and by 5.8% in the PM peak on Route 66, with 90th percentile loads down 5.5%. But driver compliance with holding instructions was only 35% on Route 81 and 56.9% on Route 66, and experienced drivers complied least.
What is still mostly research. Reinforcement learning for bus holding and fleet control is an active academic field, but the large majority of published results are simulations. Fully automated rebalancing, where an algorithm dispatches extra vehicles or short-turns buses without controller approval, is not standard practice at any large network we could verify.
| Real-time action | Status in 2026 | Main constraint |
|---|---|---|
| Controller holding, curtailment, spare bus insertion | Everyday practice | Controller workload, visibility |
| Headway-based regulation on frequent lines | Deployed on some lines | Driver acceptance, labour rules |
| Algorithmic holding recommendations | Field pilots (e.g. CTA) | Compliance, trust, data latency |
| Fully automated dispatching and short-turning | Research and simulation | Safety, accountability, data quality |
APTA's AI primer (May 2026), based on a survey of 32 member agencies, reaches a similar conclusion: agencies are "piloting, learning, and scaling", with operations among the areas of highest planned adoption, not current maturity.
What this means for an operator or transport authority
Before buying an AI planning module, check the foundations:
- Measure running times by segment and time band, not only end-to-end, and over enough weeks to separate recurring patterns from incidents.
- Audit AVM data quality: position update interval, trip assignment rate (driver login), stop detection method, share of trips with complete records.
- Link loads to trips: APC or ticketing data only supports frequency decisions if it is matched to the trip actually operated.
- Close the loop: compare each new timetable with as-run performance after it goes live, and feed that back into the next calibration.
- Treat real-time AI as decision support first: design for controller and driver acceptance, as the CTA pilots show compliance is the binding constraint.
This is also where the AVM earns its place in the planning chain. A modern CAD/AVM system such as Pysae does not plan the network or build duties, but it produces the as-run data (trips operated, segment running times, punctuality by stop and time band, kilometres) that every planning tool, AI or not, needs to be right.
FAQ
Can AI design a new bus network on its own?
No. Tools can generate and evaluate scenarios and forecast ridership, but the redesigns that worked, such as Houston in 2015 or Barcelona's Nova Xarxa, were led by planners making explicit trade-offs with public input.
What data do I need before using predictive running times?
Trip-level AVM records with accurate stop arrival and departure times, a high share of trips correctly matched to vehicles, and at least one full season of history per route and time band.
Is real-time rebalancing by AI in use today?
Controllers rebalance service every day with CAD/AVM tools. Algorithmic recommendations have been tested in field pilots such as CTA's in Chicago. Fully automated dispatching remains research.
Sources: Hounsell, Shrestha, Wong, "Data management and applications in a world-leading bus fleet", Transportation Research Part C (2012); TRID, "ATP: Run-time analysis and improved punctuality" (GIRO, 2011); Optibus, JTA Predictive Runtimes case study (2025); Optibus blog, AI Predictive Runtimes webinar recap; Swiftly, "3 lessons from hundreds of data therapy sessions"; Kinder Institute for Urban Research, "A year after bus redesign, METRO Houston ridership is up" (2016); NACTO, Metro Bus Network Redesign, Houston; Badia, Argote-Cabanero, Daganzo, "Network effects in bus transit: evidence from Barcelona's Nova Xarxa" (UC Berkeley, 2016); Via, Remix and Swiftly integration (2023, updated 2024); Via, Via Intelligence launch (August 2025); HERE, "What Oslo's buses can teach us about data collection" (Ruter); Digitransit, HSL high-frequency positioning API; TfL FOI response on bus curtailment (WhatDoTheyKnow); Cats, "Regularity-driven bus operation", Transport Policy 36 (2014); Rodriguez et al., "Deploying robust decision support systems for transit headway control", arXiv 2509.08231 (2025); APTA, AI and ML in Public Transit primer (May 2026).
Before publishing: add the Banana Pro cover image, double-check the Ruter "400+ buses" figure (HERE blog, not an official Ruter source) and NACTO's Houston operating cost claim.