For my sanity, can you confirm that the Gradle version the JetGradle uses is at least 1.1? JetGradle does not respect GRADLE_HOME from the env AFAIK (and I don't think it should). There's UI configuration for it in JetGradle.
JetGradle does not respect the Gradle wrapper setting, too, which is unfortunate, but I'm hoping it will get fixed in JetGradle at some point (please vote for this ticket in the JetGradle tracker .
Tooling api does fork a new daemon if the current one is busy. Rapidly clicking refresh causes extra daemons for that reason I think.
Tooling api does not implement any synchronization rules (other than most clases are designed to be thread-safe - see the javadoc for more details). If users request multiple operations concurrently the tooling API will attempt to execute them concurrently. At the moment we don't plan to change that behavior in the tooling api.
It's up to the client to synchronize the operations that should not execute concurrently. For example, I think JetGradle should not allow multiple concurrent entire-project refreshes. Yet, it should allow running tasks concurrently (for example when the user wants to run :a:foo and :b:bar concurrently).