Inspiration

An 11 kW charger tells you how fast one vehicle might charge. A depot has a more interesting problem: which vehicle should receive power, when, and through which physical plug?

Vehicles arrive with different battery levels, need different amounts of energy, and leave at different times. They share a grid connection. A van that has finished charging may still occupy its plug. Cheap electricity can encourage every vehicle to charge simultaneously, creating a peak with a cost of its own.

We built ChargeWise.AI for fleet and depot managers who need to make those decisions before the next departure. Our question was simple: how much can better planning achieve with the charging infrastructure already available?

What it does

ChargeWise turns a fleet roster, charger inventory and electricity tariff into an editable charging simulation. You can change fleet size, arrival and departure times, battery capacity, initial and target state of charge, energy requirements and vehicle charging limits. Add or remove chargers, mix their power ratings and connectors, change their availability, and configure the shared power limit, efficiency, prices and demand tariff.

The application compares first-come-first-served, earliest-deadline-first, least-laxity-first and optimized scheduling under the same physical constraints. It accounts for fixed plug occupancy, charger and vehicle power limits, charging losses and an optional conservative SoC-dependent taper envelope.

The optimizer prioritizes meeting energy targets, then minimizes energy plus incremental demand cost. An alternative objective minimizes peak power before cost. Outages and price changes trigger replanning; advancing simulation time preserves energy already delivered. A capacity study explores the installed hardware and provides an inspectable feasibility check and, where established, a minimum-capacity proof.

How we built it

The interface uses React, Vite, Tailwind CSS and Recharts. FastAPI, Pydantic and pandas handle the API, typed inputs and CSV validation. OR-Tools with SCIP constructs the schedule, and a separate validator checks its allocations against the physical constraints before publication. Actual planning stages stream to the dashboard as they complete.

NVIDIA Nemotron runs through Nebius Token Factory. Typed tools let the model retrieve computed schedule facts and request an authorized outage simulation. The solver calculates the resulting plan; the validator checks it; Nemotron explains the returned results. We verified real schedule-read and outage-replanning calls through Token Factory. The shared public planner uses clearly labelled local summaries and needs no API key.

The architecture animation follows this workflow across one continuous map. The downloadable build includes the prebuilt dashboard and runs the complete Python planner without Node.js or model downloads.

Challenges we ran into

A power chart can hide an impossible plug assignment. Scheduling aggregate kW is insufficient if two vehicles need the same occupied connector. We model physical ports and keep fixed connections occupied until departure, including idle periods.

A lower energy price can produce a higher bill. We separated energy cost from incremental demand charges and included prior billing peaks. This lets the planner recognize when spreading charging is worth more than concentrating it in the cheapest interval.

Replanning must respect what has already happened. Completed charging remains part of the delivery history. Versioned browser workspaces and idempotent events keep stale edits and repeated requests from silently changing the simulation twice.

A plausible explanation still needs computed facts. We give Nemotron typed tools and compact numeric results, including delivered energy and active charging duration. This avoids asking the model to reconstruct quantities from incomplete allocation lists.

Accomplishments we are proud of

In our synthetic four-van example, all four policies deliver the requested 84 battery kWh. The three baseline policies peak at 22 kW; the optimized schedule reaches 8.89 kW, approximately 60% lower, with zero energy shortfall.

There is a physical explanation for that result. The afternoon pair needs 48 kWh within six hours. At 90% efficiency, the required average grid power is:

$$ P_{\min} \geq \frac{E_{\mathrm{battery}}}{\eta T} = \frac{48\ \mathrm{kWh}}{0.9 \times 6\ \mathrm{h}} \approx 8.89\ \mathrm{kW}. $$

The checked schedule reaches this lower bound. Taking one charger offline from 08:00 to 12:00 raises the example's peak to 10 kW, while every vehicle still receives its requested energy.

We verified the application with 41 passing automated tests, including a physical scheduling case with 101 vehicles and 51 mixed-power chargers. Browser checks cover custom battery/SoC inputs, charger renaming and removal, pagination, invalid drafts and a walkthrough that preserves the user's configuration. Larger scenarios remain subject to the interactive solver's resource budget.

What we learned

Better forecasts do not automatically create better charging decisions. We ran TimesFM 2.5 and Chronos-Bolt models on chronologically held-out months of historical German electricity prices, followed by over 500 physical scheduling replays. Chronos-Bolt Small reduced price forecasting error by 29% against ridge regression.

The timetable and equipment determine how much of a prediction improvement can become an operational advantage. Already published prices should feed the planner directly; forecasting matters where future prices remain unknown. This historical study is exploratory, and the checkpoints' pretraining overlap with the old test period is unknown.

The Language Model's value comes from useful tools, well-defined actions and feedback from the actual calculation.

Our experience with Nebius and NVIDIA

Token Factory let us integrate an NVIDIA model without provisioning a GPU server. Nemotron successfully retrieved a vehicle's schedule and requested a checked outage replan. One practical integration challenge was normalizing nested tool arguments that arrived as serialized JSON; the resulting arguments still pass through the same typed validation and permission checks.

What's next for ChargeWise AI

The next useful evaluation combines an operator's linked vehicle duty cycle with battery telemetry, equipment records and tariffs. That would let us measure departure readiness, energy shortfall, peak power and cost across repeated days, and assess where extra infrastructure would help. A station-protocol simulator would provide the next step toward testing charger commands.

The current demo is based on real-world datasets and historical prices are retained separately with source information. The result we can demonstrate today is a complete, configurable workflow from inputs to an independently checked charging plan.

Built by Julius Störk, Muhammad Talha Toqeer and Umar Khan.

Explore the project · Download the working application · Source code · NVIDIA/Nebius runtime results