What held back the switch was accumulated setup, not performance

This sets out, with the verdict held back, the first impressions of someone who had used only one ecosystem for a year, a few days after moving to another commercial coding agent. What stands out is what the switching barrier really was: the reason they hadn't moved was not performance but settings such as skills and memory that had already piled up, and when the installer detected the existing tool and brought all of that over in one go, the switching cost all but vanished. A caveat is attached, secondhand, that elaborately configured hooks and subagents do not carry over. Beyond that, the two diverge on several points: limits drain more slowly and leftover resets can be saved up for later; the lineup has several models, so they can be allocated task by task; and connecting external services is easier on this side, while the other side is better at understanding and carrying out published skill documents. There is also the observation that its ability to operate the screen directly, opening things and clicking through them, is actually usable, but the evidence is all a few days' worth of impressions, and permissions and the risk of mis-operation are not addressed.

This is a note: my own write-up after reading several sources. It has no source link; events checked against a source are kept as records.