There are options in config.xml:

<max_wus_in_progress> N </max_wus_in_progress>
<max_wus_in_progress_gpu> M </max_wus_in_progress_gpu>
Limit the number of jobs in progress on a given host (and thus limit average turnaround time). Starting with 6.8, the BOINC client report the resources used by in-progress jobs; in this case, the max CPU jobs in progress is N*NCPUS and the max GPU jobs in progress is M*NGPUs. Otherwise, the overall maximum is N*NCPUS + M*NGPUS).

and

<max_ncpus>N</max_ncpus>
An upper bound on NCPUS (default: 64)

I assume you have defaulted to 64 cores and WCG to 1 * number of cores.

I have no experience of such large machines.

After you returned enough valid tasks that limit will increase,
but with 80 cores you will soon meet another limit.
BOINC doesn't ask for new work when you have >1000 in queue.

The answer will be like:

31852 World Community Grid 04 Feb 16:23:22 Sending scheduler request: To report completed tasks.
31853 World Community Grid 04 Feb 16:23:22 Reporting 4 completed tasks
31854 World Community Grid 04 Feb 16:23:22 Not requesting tasks: too many runnable tasks

But only up to the point that the device profile knows of the core count, which is either default 32 or 64, hence why <max_ncpus>N</max_ncpus> is needed to override that setting.

Similarly if you run into the 35 per core cap, you can play this flag, some do with beta to fake 16 when there's only 8 e.g. Of course when you fake 16, 16 will also be started, so it's a case of value up, restart, fetch, value down, restart.

Yup, those are the server side settings... note the difference between config.xml in your document and cc_config.xml which is user side, where the cc_ prefix stands for old speak core client.

Inquiring minds want to know - Just what hardware is that ?
Cheers