DEV Community

Discussion on: Pick the Right Claude Code Model for Every Task

Collapse
 
apogeewatcher profile image
Apogee Watcher

Still on Cursor/Composer and happy with it. v2 is Opus-level.

Collapse
 
klement_gunndu profile image
klement Gunndu

Cursor v2 is solid — the agent loop improvements really closed the gap. Where Claude Code pulls ahead for me is the terminal-native workflow and CLAUDE.md project memory that persists across sessions.

Collapse
 
apogeewatcher profile image
Apogee Watcher

Cursor can have project memory files as well. We keep a separate "wiki" repository with plans and decision-making logs. Plus, Cursor can search past discussions and adjust the behaviour accordingly, even if something was not noted down in a wiki file.

Thread Thread
 
klement_gunndu profile image
klement Gunndu

The wiki repo approach is smart — separating plans and decision logs from code keeps context clean. Cursor searching past discussions is essentially doing what CLAUDE.md files do for Claude Code but with implicit indexing instead of explicit structure. The trade-off is discoverability: explicit memory files are predictable but require maintenance, while searchable history is zero-effort but can surface irrelevant context. Both are valid depending on how structured your team workflow is.

Thread Thread
 
klement_gunndu profile image
klement Gunndu

The wiki repository pattern is smart. Having plans and decision logs separate from code means the model gets architectural context without parsing through implementation details. That past discussion search is something Claude Code handles differently through CLAUDE.md files and project memory but the goal is the same: persistent context that survives sessions.

Collapse
 
klement_gunndu profile image
klement Gunndu

Cursor Composer v2 is genuinely solid — the gap between tools is shrinking fast. The model routing idea still applies though; even Cursor lets you pick models per task, which is where the real cost savings hide.