UE5Coro turns a latent UFUNCTION into a coroutine with a co_await

A latent function, rewritten as a coroutine

The headline example is the one the README puts first, and it shows the whole idea. A latent UFUNCTION normally means writing an FPendingLatentAction, wiring a callback, and unmounting it at the end. With UE5Coro you change the return type and the boilerplate disappears:

UFUNCTION(BlueprintCallable, meta = (Latent, LatentInfo = LatentInfo))
FVoidCoroutine Example(FLatentActionInfo LatentInfo)
{
    UE_LOGFMT(LogTemp, Display, "Before delay");
    co_await UE5Coro::Latent::Seconds(1); // Does not block the game thread!
    UE_LOGFMT(LogTemp, Display, "After delay");

    co_await UE5Coro::Async::MoveToTask();
    UE_LOGFMT(LogTemp, Display, "In game thread: {0}", IsInGameThread());
    FString Value = TEXT("Imagine this was expensive to compute");

    co_await UE5Coro::Async::MoveToGameThread();
    UE_LOGFMT(LogTemp, Display, "In game thread: {0}", IsInGameThread());
    UE_LOGFMT(LogTemp, Display, "Value: {0}", Value);
}

The function keeps its UFUNCTION declaration, the Latent meta and the LatentInfo parameter, and the delay does not block the game thread because the coroutine suspends instead of sleeping. The README also points out a property that matters more than it looks. You can destroy the actor while the coroutine is running, because latent coroutines track their target UObject and clean up early if needed. A latent action that fires a callback into a destroyed actor is a crash, and the plugin treats lifetime as part of the awaitable rather than as something the caller has to remember.

Blueprint never learns a coroutine happened

The second thing the README emphasises is that the coroutine return type is hidden from BP so as not to disturb designers. The Blueprint node for the example function looks exactly as it did before, with the same inputs and the same execution pins, and a screenshot of the node is included in the documentation to prove it. That is a design decision with real consequences. The usual way a runtime change reaches designers is a new node shape, and a new node shape means new graphs, new documentation and new confusion. Here the change is confined to the C++ side, and the plugin states that the return type is hidden from BP for exactly that reason. The same reasoning extends to people who are not interested in latent functions at all: raw C++ coroutines are also supported with the exact same feature set, and the backing implementation is selected at compile time, with latent actions only created if you actually use them.

The catalogue of engine features that get an awaiter

The feature list is organised by what kind of engine interaction you are waiting on, and each group has its own documentation page. Coroutine authoring covers the coroutines themselves, plus cancellation support on its own page, plus generators, plus Gameplay Ability System integration, which the documentation notes works slightly differently. The Unreal integration section covers AI, with MoveTo and pathfinding, animation awaiters for montages and notifies, async awaiters for multithreading and synchronisation, plus an async chain that acts as a universal wrapper for functions taking delegates, HTTP for asynchronous requests, implicit awaiters for engine types that are directly co_awaitable without a wrapper, latent awaiters for game thread interaction and Delay, and within that group asset loading for soft pointers and bundles, async collision queries for line traces and overlap checks, a latent chain as a universal latent action wrapper, and a tick time budget for running for a set number of milliseconds per frame. Latent callbacks round it off, covering interaction with the latent action manager. It is a curated list rather than a general async layer over the engine, which is what makes it usable.

Throttling, time slicing and moving between threads

The README works through the everyday problems with a question and a one line answer, and the answers are the API. For spreading a heavy computation across multiple ticks, you add a co_await NextTick() inside a loop, and there is a time budget class that lets you specify the desired processing time directly and lets the coroutine dynamically schedule itself. For throttling, co_await Ticks(bCloseToCamera ? 1 : 2) schedules the coroutine to resume every first or second tick depending on distance, which is the kind of decision that is otherwise a manual counter in a tick function. For using more than one core, co_await MoveToTask() moves everything after that line into the engine's task system on a worker thread, and co_await MoveToGameThread() brings it back. The plugin is explicit that you are free to move arbitrarily between threads, and that latent UFUNCTION coroutines automatically move back to the game thread when they are done so they can resume in Blueprint.

Awaiting a delegate, and awaiting a timeline

Two of the examples are about removing a specific kind of friction. The first is the dynamic delegate, which in the engine usually means writing a UFUNCTION purely so you can use AddDynamic and BindDynamic, and having to be in a UCLASS to do it:

co_await YourDynamicDelegate;

That is the entire code, and if the delegate carries parameters you can destructure them with auto [Your, Parameters] = co_await YourDynamicDelegate;. The second is a timeline, where co_await Timeline(this, From, To, Duration, YourUpdateLambdaGoesHere) runs an entire timeline as part of the coroutine. The plugin's argument for all of this is about the shape of the work rather than the elegance of the syntax, that a task reduced from writing the StreamableManager boilerplate and moving part of the calling function into a callback down to sticking co_await in front of it will be finished sooner, and that a synchronous blocking version of the same work needs a written justification. It also frames the alternative as a codebase problem, that asynchronous code being easy to write means there is no friction when it comes to doing things the right way, right away.

The Private namespace, and how to read the docs

The documentation has a note that is worth reading before you write code against the plugin. Most of these functions return undocumented internal types from the UE5Coro::Private namespace, and client code should not refer to anything from that namespace directly, because everything within is subject to change in future versions, without prior deprecation. The README explains why this is usually harmless, since the unnamed temporary object in co_await Something() does not appear in your source code, and the same is true of the types the awaiters return. It is a real constraint, though, and it means the surface you may name explicitly is narrower than the surface you may use. The other reading note is about where the documentation lives, since every API function is documented in the C++ headers and the releases contain the Markdown source of the documentation, so the docs can be read in a browser, read straight from an IDE, or read at the version your project actually pins, which is the one that matters when the internal types move.

One plugin, two engine generations

The release history is unusual and tells you how the project is organised. There is v2.3.2, published on 2026-07-19, and alongside it a separate tag for the same version number labelled as the UE4 edition, and an older v1.10.7 published on the same day, which is the long-running branch for the other engine generation. All three releases were published on the same day. The plugin itself is a single Unreal plugin, UE5Coro.uplugin, with Source/ for the code, Config/, Resources/ and a Docs/ directory that holds the Markdown documentation the README links to, and the documentation is organised as one page per topic, from Coroutine.md and Cancellation.md through the GAS, AI, Animation, Async, Http, Implicit, Latent and LatentLoad pages. The licence is BSD 3-Clause Clear, with the text in a COPYING file at the root, and the topics listed for the repository cover async-await, coroutines, cpp20, unreal-engine, unreal-engine-4 and unreal-engine-5.

Editorial conclusion

UE5Coro is the right plugin for a gameplay programmer who has written the same latent action and delegate plumbing in a dozen places and wants it gone, because the change is as small as a return type and the Blueprint side does not move, so the change is invisible to designers. It is the wrong tool if you are on a project that cannot adopt C++20, or if your team wants the compiler to catch thread-affinity mistakes, because moving between threads is a runtime decision the plugin makes for you. Before adopting it, read the page on the Private namespace, since most of the awaiters return internal types that are subject to change without deprecation, and check the documentation for the specific engine feature you need rather than assuming the wrapper set covers it, because the plugin is a curated list rather than a general async layer.

Frequently asked questions

Official sources

1. Issues
2. landelare/ue5coro on GitHub
3. License: BSD-3-Clause-Clear
4. README
5. Releases