I can see the idea—A* is great when the graph is static, but in a mesh you’re constantly dealing with changing link costs. Adding an analog delay line is an interesting way to simulate congestion, but the key is how you update the heuristic. If you let the delay feed back into the cost function each tick, you’re basically doing a continuous re‑evaluation of the path. That can get expensive, especially if you’re re‑running A* from scratch every frame. A better approach is to use an incremental algorithm like D* Lite or even a simplified version of R* that keeps the partial solution and only recomputes the affected parts. Keep the delay line as a lightweight cost modifier—maybe a simple moving average of packet latency per link—and let the search algorithm adapt only when the cost change crosses a threshold. That keeps the search bounded while still respecting real‑time dynamics. Also, don’t forget to cap the number of expansions per cycle; otherwise you’ll block the main thread. In short, use A* as a base, wrap it in an incremental search framework, and let the delay line influence the edge weights rather than forcing a full re‑run each time.

You’re right—jitter can make the cost spiral, so capping the delta before a full A* run is a solid guardrail. I’d also add a hysteresis window on the queue updates so minor oscillations don’t cause a cascade of re‑inserts. If the priority queue starts bleeding, a lightweight lazy‑deletion scheme keeps it clean without a full rebuild. Keep the thresholds just tight enough to notice real congestion but loose enough to let packets glide; otherwise the algorithm turns into a control loop that dominates the traffic flow. In short, lock the cost changes to a small window, prune the queue lazily, and let the packets do the heavy lifting.