For the records, even if Fedora 34 has not been branched yet, toolbox can find a f34 image:

$ toolbox create --distro fedora --release f34
Image required to create toolbox container.
Download registry.fedoraproject.org/f34/fedora-toolbox:34 (500MB)? [y/N]: y
Created container: fedora-toolbox-34
Enter with: toolbox enter --release 34

The problem is that we don't have an easy way to map rawhide to a numerical value in a way that would stay updated over time without manual intervention.

One option that was suggested in #fedora-devel on Freenode was to parse the metadata in the Fedora RPM repositories for rawhide. That's something that needs to be explored because I don't know off-hand how easy or difficult that would be.

It seems to me that the best candidate is to use Fedora's package DB collections API that's also used by GNOME Software.

(Thanks to @AdamWill and @kalev for suggesting that.)

Another option that was presented to me in #fedora-devel on Freenode was to parse the branch names of the fedora-release Git repository.

So to give my standard explanation of this stuff for the record:

• The "collections API" isn't really an API any more and hasn't been for years. It's a static JSON file that releng update by hand. If they forget to update it or make a booboo while doing it, the data will be wrong. Both these things have happened more than once.
• I have some code that needs this same thing, and the way I do it is: rawrel = str(fedfind.helpers.get_current_release(branched=True) + 1). That uses my fedfind library, which formerly used the collections JSON as its data source, then tried using Bodhi's releases API for a bit, and right now is using my own hand-maintained JSON (on the theory that at least I can fix that one without needing someone else to run a playbook), though I might ping it back to the collections JSON.
• I'm currently trying to get some momentum behind a project I wrote called releasestream that is intended to work as a better/more reliable/more automated source of this kind of information. The idea would be to deploy an official Fedora releasestream instance and have system/scripts that do release-y things, like branching and EOL and so on, also update releasestream at the same time.

Thanks for putting that on record. For what it's worth, I heartily endorse your efforts on releasestream.

Personally I just use https://pdc.fedoraproject.org/rest_api/v1/product-versions/ for this.
Bodhi's API might be slightly more precise, depending on the exact use-case.

The limitation of PDC is it doesn't have full lifecycle info (it just has 'active' or not; it doesn't distinguish pre-release from stable). I also don't know these days how exactly it gets updated and whether that's any more reliable than the collections JSON. The issue I had with Bodhi is that releases are changed from pre-release to stable state in Bodhi some days before they're actually publicly available.

For toolbox's purposes, neither of those should really be a problem, so you could potentially use either of those sources too. Rawhide's version number should always be one higher than whatever the highest numbered release provided by the data source is.