AskMeAnything
Ask
Ask
57
@margot_teller ·

Composer 2.5 vs Sonnet for cross-service debugging in Cursor: how do I test the switch without burning a week? First impressions

My work is debugging across five services. A typical investigation is app logs, traces, a dashboard and code in three repos, and the model's job is to narrow, not to write. Sonnet has been good at it. I also hit the ceiling on the $20 plan by Wednesday, every week.

The cost side did move in July: Composer 2.5 and Cursor Grok 4.5 draw from Cursor's first-party pool, and that pool's included usage was permanently doubled on the newer self-serve paid plans. So switching is genuinely cheaper for me, on paper.

What I cannot get from other people's impressions is whether it holds a mental model of a large codebase well enough for investigation work, or whether I would be paying less to reach worse conclusions faster. "It does not overthink" is exactly what a model that anchors on the first plausible cause also looks like.

Has anyone run the same investigation through both, same prompt, same tools, same starting context, and compared what they did: files opened, wrong branches chased, whether it checked an assumption before acting on it? I would rather copy a method than collect verdicts.

7 answers Share
Report

7 answers

BestTopNewOldControversial

Answering anonymously — a moderator will review it first.

  • @desmond_ruiz · 2h ago · 2 replies
    @desmond_ruiz ·

    Replay solved incidents. It is the only method I have found that survives contact with a real codebase.

    Pick three bugs you personally fixed and know the root cause of. Reconstruct the starting artifacts: the alert text, the log slice, the trace ID, nothing that leaks the answer. Give each model the identical bundle and the identical prompt, in a fresh session.

    Score four things: did it reach the actual cause, how many tool calls it took, how many files it opened that were irrelevant, and whether it stated its assumption before acting on it. Keep the transcripts, because in a month you will want to diff behaviour against the next release rather than rely on memory.

    Three incidents takes an afternoon and tells you more than a fortnight of switching back and forth on live work.

    31
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @petra_lindqvist · 2h ago
      @petra_lindqvist ·

      Add a fourth case where the symptom is misleading: the error surfaces in service A and the cause is a config change in service C. A model that "stays focused" and a model that anchors on the first plausible story are indistinguishable on easy bugs and completely different on that one. That case is the whole reason you are testing.

      11
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @clay_bertram · 2h ago
    @clay_bertram ·

    Before you interpret your bill: included usage is split into two pools. The first-party pool covers Auto, Composer 2.5 and Cursor Grok 4.5. Third-party models sit in a separate pool. The permanent 2x applies to the first-party pool only, on self-serve Pro, Pro+, Ultra and Teams on the newer pricing.

    So "I switched and my limits doubled" is really "I moved work onto a different budget that happens to be bigger". That is still a win, but it changes how you plan: put the mechanical work (reproduce, grep, patch, write the test) on the first-party pool, and spend the third-party pool on the judgement calls where you are paying for a specific model's reasoning.

    22
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @maren_dowd · 15h ago
    @maren_dowd ·

    For investigation work specifically, grounding beats model choice most of the time. If the agent cannot pull the log slice and the trace itself, both models are guessing from whatever you pasted, and they converge on similar quality of guess.

    Wire the tools first: log query, trace fetch, repo search that actually returns the right files. Then re-run your comparison. Every time I have done this the gap between models narrowed a lot, and the remaining gap was in how well each one used the tools rather than what it knew.

    13
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @two_calendars · 2h ago · 2 replies
    @two_calendars ·

    One thing that makes the switch easy: both come out of the same first-party pool, so they drain it at the same rate. Pick whichever you prefer, the budget maths is identical.

    8
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @clay_bertram · 2h ago
      @clay_bertram ·

      Same pool, not the same rate. The pool is drawn down at each model's own token rates, so the two are not interchangeable from a budget point of view.

      Cursor lists Grok 4.5 at $2 per million input tokens and $6 per million output, with a fast variant at $4 and $18. Composer sits lower. For the same token volume the more expensive model empties the pool sooner, and the fast variant does it dramatically sooner. Check the usage breakdown in the dashboard after a real day of work rather than assuming parity, because the fast/standard split is where people lose a week of budget without noticing.

      10
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @bootstrap_nadia · 2h ago
    @bootstrap_nadia ·

    Boring possibility worth ruling out first: the reason you run dry on Wednesday may be context, not model. Long sessions that keep re-sending a large working set cost a multiple of what the same work costs in short, scoped sessions.

    Measure tokens per completed task for a couple of days before you change models. If it turns out you are spending most of your allowance re-reading the same files, switching models just changes how fast you spend it.

    6
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report