Ok. That's what I was thinking would be the next best alternative. Thanks.

What is the advantage to returning only string types?

I would expect consistency in types I connected with those I retrieved.

We usually use YAML objects rather than JSON objects, so our code littered with local saving of objects just so that we can upload them again as artifacts.

Well, I connected a dictionary of params that needed to be accessible in the GUI via task.connect using a loop, where I was filtering that dictionary:

for k, v in config_dict.items(): if k not in ['element1', 'element2']: task.connect(v, name=k.lower())
It seemed more logical to return the params with a single call:

task_parameters = task.get_parameters_as_dict()

Say I have a more complicated, nested dict of params, and I only want to send some of the nested keys to the GUI. I also want each one of those to be a "hyper parameters" field in the ClearML GUI. How do I connect each of these fields as such and return the correct types?

example:
config: field1: dict(param1=123, param2='text') field2: dict(param1=123, param2='text') field3: dict(param1=123, param2='text')
If I understand what you suggested above, doing ` task.connect(base...

How do I preserve types when using task.get_parameters_as_dict() or task.get_parameters() ?

If I connect the params via task.connect(input) , change via the GUI, and use one of the methods above, all int and float values turn into strings. This doesn't work very well for hyperparameters that are numerical.

Follow up: I see that if I move an Experiment to a new project, it does not copy the associated model files and must be done manually. Once I moved the models to the new project, the query works as expected.

That seems to work. Thanks!

Maybe. Will look into this. Thanks for the suggestion.

Yes, that's what I'm doing right now. I was hoping there was something that felt a little less hacky.