[CONCERN] Claude Code is very slow

Intelligence vs. processing speed is a tradeoff. It certainly depends on the model you are using. Opus is a larger, more capable model, so it will be slower than Sonnet, for example.

Some ways you can optimize this are to see if you can do more tool calls in parallel (including subagent calls) and figuring out how to make better use of the smaller Sonnet model vs. the larger Opus model.

Intelligence vs. processing speed is a tradeoff. It certainly depends on the model you are using. Opus is a larger, more capable model, so it will be slower than Sonnet, for example. Some ways you can optimize this are to see if you can do more tool calls in parallel (including subagent calls) and figuring out how to make better use of the smaller Sonnet model vs. the larger Opus model.

I think that is not the problem. Actually, claude has the same tk/s from chatgpt models. But claude code are very slow. I am waiting like 5 minutes to get a full resolution. It keeps loading and nothing happens sometimes. Maybe there is a problem here. Since I paid U$ 200 on claude code it was not supposed to happen.

Intelligence vs. processing speed is a tradeoff. It certainly depends on the model you are using. Opus is a larger, more capable model, so it will be slower than Sonnet, for example. Some ways you can optimize this are to see if you can do more tool calls in parallel (including subagent calls) and figuring out how to make better use of the smaller Sonnet model vs. the larger Opus model.

Most of the time the auto mode uses Sonnet automatically. It's very rare I see Opus actively being used - which is actually another problem in itself, because with Opus the slowness can be somewhat justified and I get a better result, but with Sonnet it tends to be slow and also make a lot of mistakes. I wish it would engage Opus more, it's common that I have to explicitly tell Claude to use Opus when it continues to fail on the same problem over and over again.

Tool calls in parallel isn't really a solution for this, because I'm mostly referring to just general behavior and usage. For use cases where it does apply, I could potentially try and break tasks down further myself, split it into tasks that can be parallelized, and hope that it doesn't conflict. This is fairly self-defeating though, if the aim is intelligence and the justification is intelligence is slow, it should be doing this sort of reasoning on its own.

@dicksontsai - consider an addon to the subscription model that provides users with priority compute. It could be tiered like internet plans are. Gatekeeping model intelligence and capability is a dangerous and slippery slope for humanity, but gating it on resource allocation is actually fair and reasonable - because that's what is happening behind the scenes. I think this might be the direction the future needs to go not only to fairly balance the compute requirements, but also to maintain a power balance in society in terms of access to intelligence. Effectively an "intelligence bandwidth" allocation, like "intelligence per second" rather than "MB/s". You already very vaguely have this listed under the highest subscription tier you have: "priority access during high traffic periods" - however I think it needs to be more transparent and defined.

Pay per token on its own is not sufficient because the speed of a model is one of the largest factors in determining its utility, but a pay per token model does not encode that information at all. What we've seen with internet plans in the past is very apt here, and the AI tech space is naturally following a similar trajectory, mostly without realizing it. We started out paying by the amount of bandwidth, then we had various types of subscription models (with fixed caps or slower speeds over thresholds), and now the majority are unlimited plans and you pay based on bandwidth speed. I think most people are quite happy with this system. It also reduces the number of variables to balance in terms of business billing, because higher speed = higher compute cost, so you can now balance on the single metric rather than both. You can also calculate the maximum amount of compute a user can use (within reasonable margins) on any single plan based on the billing period and the speed they're paying for, which helps guide company decisions on where to set prices, floors and ceilings.

I'm on a MAX subscription and there are long periods where 0 T/s are occuring.

This is happening to me as well. I'm on the max subscription, and it's just taking longer and longer times nowadays after updating 1.0.6X.

It got subjectively slower over past 2 or 3 months. It needs to get subjectively faster, not slower.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.