The workflow graph currently does not scale to handle the display of several dozens of jobs very well. A more compact and navigable visualization would be a great addition. See attached screenshot of example workflow graph, with browser zoom at 30% on a fairly traditional 1920x1200px display.

It would be nice to be able to set resource constraints for specific images and/or side car containers. The cloud environment will share the resources across your specified resource class when using side car containers.

Automatic scaling to handle changing workloads - AWS ASGs, Kubernetes, etc.

To avoid slow spin up and make each job running faster, you can run the spin-up phase even before a job starts. You might think that this is wasteful in terms of resources but in our case it can reduce at least 2.5 minutes in workflow time which is 60% of the complete workflow

It would be helpful to add a label to the pod that is running the task with the real job-name to easily reference which pod is running which task. These labels can then show up in our observability platform and we can easily aggregate across the same job type. Right now we can only do it by resource class

Would be nice to specify multiple executor/resource types in a ranked preference order. I could have multiple self-hosted runner resource classes I've created, and if one has no nodes available, CircleCI moves down the list to the next resource class. It would be nice if the list could also include cloud executor types - if none of my self-hosted runner classes have nodes available, then I default to using a CircleCI-hosted node.

An ask to open source the self hosted runner agents so the community can work with the team on any issues

It would be helpful to be able to list all namespaces and resource classes that have been reserved for the CCI agent runner. This is also an existing idea here: https://github.com/CircleCI-Public/circleci-cli/issues/663

Would like the ability to restrict who can use certain runners in an org, similar to how we can restrict who has access to contexts.

We would like to use the cache steps that are defined here: https://circleci.com/docs/caching/ We would like to be able to host the cache ourselves as our hosting is a long way from the CircleCI infrastructure causing it to be very slow when pulling the cache data. We like the fact it is simple and easy to use and we would like to have something similar when using runner.