oh, this is actually interesting that the support team is offering you to kind of spam them with login requests. My guess is that there will still be a limit, it might just be a little bit larger (for instance a few dozens tries per minute or hour).
It would probably make
much more sense if they could somehow tell you how they verify your login credentials (a hash algorithm used for the database-stored password probably)... and maybe even somehow sent you in a very secure manner the "hash" that they have stored (of course only for your specific user id) to verify that your login name and password are correct. It wouldn't probably be a problem for them to do so... but my guess is they won't do that nevertheless. They will probably say that they can't do it for legal reasons etc etc etc... but the real problem would be that they "leak" the information about how they store the passwords and how they verify login requests.
Of course you could argue against that, that otherwise you probably need to DOS / spam them with requests because your password is "random"/complicated. I think even a lawyer might NOT be able to make the company hand out the user login hash. They will try to find several arguments that this is not possible....
The problem with online cracking (i.e. cracking by sending web/http/https requests), is that it is both very slow (because of the network overhead etc), might not be 100% reliable and they could suddently send you wrong answers or block you (even if they told you there is no limit, they will/can do that, because otherwise you could risk to disrupt their services).
There are many such "online cracking tools", I think hydra was (or still is?) one of the most known one
https://github.com/vanhauser-thc/thc-hydra ... but in this case you could also just develop a simple python/perl/php or whatever script that uses for instance the CURL library to send login requests (and basically automatically fill out the login form). Otherwise you could also use headless browsers, like most scrapers (or scraping tools/software) do... this is sometimes needed if there is some javascript involved on the page while logging in (basically a new way or alternative to the phantomjs approaches that were used some years ago to scrap or send web requests with some scripting).
There might also be new / better alternatives to hydra, that do these step all automatically. Maybe you find something on google+github etc.
.... but the problem still remains... it's not good to send a lot of web requests and just because some dude at the support team told you that you can now send more requests and that there is no limit in login attempts, it doesn't mean that you can DOS / spam the service and that you couldn't face some legal threats if you do so (that's also the problem of big companies, the administrators, security team might not even know that you are "allowed to try to login more often", they might just log your IP and send it to the legal team).
That means that I for sure wouldn't even try/risk to send dozens of requests per minute... if anything, you should really keep a very, very low amount of tries per day ... and this probably wouldn't allow you to find the correct password in years
Therefore, I would recommend to still try to get more info and good will from the support team, also some clear written statements about what is allowed and what not. how many requests per hour or day etc. and ... maybe they are even allowed / willing to tell you how they verify your login credentials and give you another means to unlock the account (e.g. the user login hash approach, but I REALLY doubt that).
at the end it's also important to analyze / realize if this is really worth it. is the value stored that high ? or even somehow try to find backups of the password you have used (stored in a password manager or similar), or remember as much as possible from the password and somehow "log"/store your attempts to avoid trying the same password again and again (which for sure is a waste for your time and also a resource waste for the login server).