Hey everyone. I've been trying to decide between Continue and Cursor for my daily work, and I keep seeing people talk about speed. Since I'm always worried about adding anything that might slow down my workflow (or worse, my actual data pipelines), I decided to measure it myself.
I built a small Python script that uses their respective APIs to generate a simple, standardized completion. The idea was to get a feel for the real-world suggestion latency I might experience. I ran it locally, logged the times, and repeated each call 50 times to get an average.
Here are the results from my run:
- **Continue** (using `togethercomputer/CodeLlama-13B-Instruct` as the configured model): Average latency: **1.82 seconds**
- **Cursor** (using their default model, which I believe is GPT-4 based): Average latency: **3.47 seconds**
Here's the core part of the script I used for Continue:
```python
import time
from continuedev.core.main import Continue, ModelDescription
from continuedev.models.factories import TogetherModelFactory
async def test_continue():
model = TogetherModelFactory.create(
model="togethercomputer/CodeLlama-13B-Instruct",
api_key=YOUR_API_KEY
)
sdk = Continue(model=model)
start = time.time()
completion = await sdk.complete("def calculate_average(data):")
elapsed = time.time() - start
return elapsed
```
My setup isn't perfect—network variability, local resources, etc.—but I tried to keep conditions consistent. The difference was pretty consistent across runs. Continue was noticeably faster in this test, which is appealing for my use case where I'm often iterating quickly on Airflow DAGs or dbt models.
Has anyone else done similar comparisons? I'm particularly curious if this holds true for more complex prompts or when using different models within Continue. I don't want to optimize for a benchmark that doesn't reflect real usage.
I'm a product lead at a series B SaaS company; our stack is Python/Postgres on GCP, and we've had a team license for Cursor in production for about 9 months, with a few devs also running Continue locally.
You're measuring one metric, but shopping for a workflow. Here' drop-for-drop what I'd weigh.
**Latency vs. accuracy tax**: Your 1.8s for Continue is cheap because you're paying for a 13B model. Cursor's 3.5s is likely GPT-4, which is a different class of reasoning. That second matters, but so does rework from a dumber suggestion. With Continue, you trade speed for spending more time correcting its output.
**Real pricing**: Continue is free locally, but you bring your own model/key. That CodeLlama run on Together is maybe $0.30 per million tokens. Cursor's "Free" tier caps GPT-4 use; the Pro plan is $20/user/month flat, which includes their model access. That's the whole cost, but you can't switch the model.
**Integration friction**: Continue is a VS Code extension you configure and wire to your own model endpoints. If your org blocks external APIs, you're stuck. Cursor is a standalone editor that works out of the box, but you can't easily graft it onto an existing, customized VS Code setup.
**Where it breaks**: Continue will choke on complex, multi-file reasoning unless you step up to a much larger/expensive model, which then kills your latency advantage. Cursor handles context better but sometimes feels "heavier" and, anecdotally, its agent mode fails more silently on larger refactors.
I'd pick Cursor for a team that wants a single, predictable tool with strong reasoning for code reviews and legacy refactors. I'd pick Continue for solo devs who already have model credits and want a faster, dumber inline autocomplete. To decide, tell us your main task (greenfield coding vs. debugging spaghetti) and if you need to run offline.
But what about the edge case?
Oh wow, that's a really smart way to test it. I've been worrying about the same thing with my team's workflow. I'm curious, did you notice any variation in the *quality* of the suggestions between those runs? A faster suggestion is great, but if it's wrong more often, the extra time to fix it might cancel out the speed benefit.
You've absolutely nailed the critical distinction between measuring a single metric and evaluating a workflow. The "latency vs. accuracy tax" framework is exactly the right lens for this.
I'd add that the cost of that rework isn't linear; a fundamentally wrong architectural suggestion from a faster, less capable model can cost minutes or hours, not just seconds. However, a slower model that gets the nuance right on the first try, especially for complex business logic, pays for its latency immediately.
Your point about integration friction is also where many teams get stuck. Continue's configuration flexibility is powerful for engineers who want control, but it becomes a support liability in a larger, less technical team. Cursor's "it just works" approach has a real operational value that's hard to quantify in a latency test.
Method over hype