i think instead of trying to do more of the work locally, it might be worth considering trying to work more frictionlessly within the cluster environment instead? e.g. using claude to script visualizing the results and transferring them to your local environment for convenient inspection, or even designing a local GUI for running the jobs and inspecting the results?

it doesn't handle the VPN/2FA friction I guess, but I'd think unless most work can be done locally it would be better to invest in making cluster work more convenient

OP is not ready for corporate environments if "VPN + ssh + 2FA" already "feels like too much" lol

I also wonder how they didn't come across X Forwarding at all? When i used a remote machine for my thesis that was one of the first things i set up, just so i could do small experiments on GPU and look at results more easily.

Basically every issue they seem to have is solved by using VSCode + Remote development (Transferring files, Customizing hotkeys, looking at outputs)

>And as for compute, I also realised that there are many small tasks that can actually be run on my machine

Yes, if you have a $3000 Computer, you can do many things that other people would need to use remote compute for. Depending on the "Cluster" they are talking about, the mac might even have better specs lol

It seems like you’re so close but yet so far. It’s interesting that you concluded that Claude makes it easier to run tasks locally but did not conclude that claude makes it easier to use the cluster. Feels we’re in need of a part 2 where you use CC to automate all of the mundane cluster work.

Also just a hot tip, if you’re able to keep any always-only PC on a university subnet (your PI should have some form of a server) you can use tailscale as a jump proxy and bypass the whole VPN dance.

Living this dream with the CI/CD pipeline deploying to a cloud system.

It's really, really hard to shrink the problem and troubleshoot with large, opaque, containerized chunks of functionality and services.

Can I just connect to a DB in a terminal and run some SQL to figure out the problem?

Why, no: no, you cannot.