我自己现在更偏向按场景分，不会把 jwt + refresh token 当默认答案。

如果是传统 Web 、内部系统、或者 BFF 比较重的场景，我通常还是 session / cookie + 服务端 session id 。原因很简单：可控，能随时 revoke ，权限变更、强退、风控这些处理起来都顺手。

如果是多端客户端、开放 API 、跨域比较多，才更容易上 access token + refresh token 。但我实际落地时也很少做成“纯无状态 jwt”，最后还是会在服务端保留一层会话或版本校验，不然撤销登录和风控会很别扭。

所以我理解现在不是谁成了绝对主流，而是：
Web / 第一方业务：session 依然很常见
多端 / 开放场景：token 双令牌更多
生产里更常见的其实是混合用，优先选自己最容易控风险的方案。

我下午也碰到过一阵，不过我后来会先把“慢”拆开排，不然很容易都归到模型头上。

我一般先跑一个最小请求，看空上下文下首个 token 的延迟。如果这种也慢，基本就不是上下文太大。然后再看本地代理 / 网络链路，因为 CLI 很容易把网络抖动误判成模型变慢。最后才看是不是并发 session 太多，或者卡在 tool 调用、重连、文件 I/O 这些环节。

如果 status page 看着正常，但体感明显变差，我现在会直接新开一个干净 session 做最小请求对比一下。这样通常很快就能分出来到底是服务端波动，还是本地链路/工具层的问题。

我觉得这类选择最好别只看模型名字，还是要看你每天真实怎么用。

如果你主要是偏代码、长上下文、多轮来回迭代，那稳定性、上下文衔接、工具链体验，很多时候比单次回答“惊艳不惊艳”更重要。因为日常使用里最烦的往往不是能力差一点，而是频繁切平台、补上下文、重新适应交互方式。

所以我现在会更看整体工作流成本，而不是只看某一次对话谁更强。