- Book: AI Agents Pocket Guide
- Also by me: Prompt Engineering Pocket Guide
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
April 2, 2026, Cursor shipped version 3 under the codename "Glass". The headline change isn't a new model. It's a new shape. Composer, the side-pane that defined Cursor since 2024, is gone. In its place: an Agents Window where you spin up multiple agents in parallel, point them at different tasks, and watch them grind. The official changelog is on cursor.com/changelog/3-0 and the launch post lives at cursor.com/blog/cursor-3. InfoQ's writeup is the cleanest third-party summary.
The product framing is direct. Most code will be written by AI agents; a developer's job is orchestration. Cursor wants the IDE to look like that future. Glass is the bet.
Two days into the rollout, the Cursor community forum thread had the predictable mix: people in love with parallel agents on multi-file refactors, people watching their token spend climb 3x because frontier models now require Max Mode on legacy plans. Both reactions are right. Glass is genuinely better for some workflows and noticeably more expensive for others. Worth pulling apart.
What Glass actually is
Three concrete pieces, each non-trivial.
Agents Window. A full-screen workspace, not a side pane. You can launch agents into local worktrees, into cloud sandboxes, or onto remote SSH targets. Each agent gets its own scratchpad, its own diff, its own conversation. The window shows them tiled, with Agent Tabs in side-by-side or grid layout. Closer in shape to a small Kubernetes dashboard than to a chat window.
Design Mode. Inside the Agents Window, you can annotate UI elements directly in a rendered browser preview and feed those annotations to an agent. Point at a button, leave a comment, the agent gets a structured target. Useful for frontend work where "make this button align with that one" used to require either a screenshot or an awkward CSS-selector dance.
Background and remote agents. The Cloud and SSH options aren't new conceptually. Cursor has had cloud agents for a few releases. Glass makes them first-class. You can fire off a long-running refactor and switch to another task while it works.
What it isn't. Glass is not a new model. The underlying coding model is still Composer 2 plus the frontier models you have access to (GPT 5.4, Sonnet 4.6, Opus 4.6, GPT 5.3 Codex) with the same context-window and tool-call mechanics as before. The intelligence didn't change. The way you steer it did.
Where Glass shines
Multi-file refactors with sub-agents. This is the workflow Glass was clearly designed around. You have to rename a domain concept across 40 files, update tests, regenerate fixtures, and patch the migration. In Composer 2 you would either feed it the whole job and watch the context window strain, or chunk the job manually and feed it three or four times. In the Agents Window you spin up one agent for the rename, one for the tests, one for the migration, and one to verify the diff. They run concurrently in worktrees and you review the merged result.
Picture a representative refactor: renaming a Payment aggregate to Settlement across a Python service with roughly 40 files of code, 20-odd test files, and a SQL migration. In Composer 2 you'd typically feed the whole job to one agent, hit the context ceiling, and need a manual nudge to remember the migration. In the Agents Window you'd see noticeably faster wall-clock with three parallel agents and a per-agent diff that's easier to review because each scope is small. Numbers will vary by codebase and model; the shape of the win is what's consistent.
Long-running tasks while you do something else. A cloud agent that's running a test suite or doing a slow type-check no longer blocks the UI. You can have it grinding in a tab while you write a different feature locally.
Frontend iteration with Design Mode. For pixel-pushing on a real page, Design Mode is the first AI-IDE feature in a while that has felt like a step change. Annotating "this padding is wrong" on the rendered button is a cleaner input channel than typing the same thing.
Where it wrecks a budget
The pricing change is the part the launch post talks about gently and the Cursor community forum talks about loudly.
Frontier models (GPT 5.4, Sonnet 4.6, Opus 4.6, GPT 5.3 Codex) moved behind Max Mode for legacy request-based plans starting March 16, 2026. Max Mode bills with a multiplier on top of the standard request rate. As of late April 2026, the Pro plan sits at $20/month, Pro+ at $60, Ultra at $200, per the pricing page. The numbers on the box are unchanged. The numbers on the bill, for teams that used to live on legacy frontier-model access, are not.
The Agents Window magnifies this. Three agents running in parallel against a frontier model in Max Mode is, give or take, three times the spend of one agent doing the same job in series. If the parallelism actually saves you 60% wall time and you're shipping more, the math works. If you spin up four agents because the UI makes it cheap-feeling and three of them duplicate work, the math breaks fast.
This is the part that didn't get a launch banner: parallel agents are a UX pattern, not a free productivity win. Each tab is a token bill.
Two workflows on the same task
Take a small but realistic job. Add a /refunds endpoint to an existing FastAPI service. The endpoint needs idempotency, an audit log, a unit test, and an integration test. The work touches five files.
Workflow A, Composer 2 in Cursor 2.x. One conversation, one model, sequential turns. (Token counts below are illustrative ballparks. Your runs will vary by codebase, model, and prompt phrasing.)
Prompt 1: "Add a POST /refunds endpoint with idempotency keyed
on x-idempotency-key. Touch app/api/refunds.py and
app/services/refund.py."
→ ~9k tokens in, ~3.5k tokens out
Prompt 2: "Now add an audit log entry on each successful
refund. Schema is in app/models/audit.py."
→ ~6k in, ~2k out
Prompt 3: "Write a pytest unit test for the service and an
integration test using the existing TestClient fixture."
→ ~7k in, ~3.2k out
Total: ~22k input, ~8.7k output. One review pass at the end.
Wall time on a frontier model: ~6 minutes. Token spend at typical frontier-model rates (around $3 per million input and $15 per million output, as of late April 2026 per published model pricing): roughly $0.20 (illustrative estimate).
Workflow B, Agents Window in Cursor 3 Glass. Three agents in parallel. (Same caveat: illustrative token counts, not measured from a single fixed run.)
Agent 1 (worktree-refunds-api): adds the endpoint
→ ~9k in, ~3.5k out
Agent 2 (worktree-refunds-audit): wires the audit-log
service in parallel; needs the same context but is
working on a different worktree
→ ~9k in, ~2.4k out
Agent 3 (worktree-refunds-tests): writes both tests; runs
in parallel against a stub interface from your prompt
→ ~10k in, ~3.5k out
Then a merge agent reconciles the three worktrees
→ ~4k in, ~1.2k out
Total: ~32k input, ~10.6k output. Wall time: ~3 minutes.
Same frontier model, Max Mode multiplier on. Token spend at the same rates and assuming a ~1.5x Max multiplier (check Cursor's models and pricing page for the current value as of late April 2026): roughly $0.30 (illustrative estimate). About 50% more spend, for 50% less wall time and a cleaner per-agent diff.
Now scale this up. The same task, but the engineer fires up six agents because the UI makes it easy, and two of them duplicate the audit-log work because they were given overlapping prompts. Token spend roughly doubles again. Wall time saves nothing extra because the bottleneck was already the merge step.
Practical rules I'd give a team adopting Glass
Use parallel agents when the work is genuinely separable. Renames across files, code-plus-test pairs, multi-package refactors. If the agents are going to step on each other's worktrees, you've split the job wrong.
Cap concurrency. Three agents is usually enough. Five is rare. Six is almost always a sign you're using parallelism as a substitute for prompting clarity.
Read the Max Mode line item every Friday. If frontier models live behind Max Mode on your plan, watch the multiplier. The Cursor docs page on models and pricing is the one to bookmark.
Don't disable Max Mode entirely. Some teams reacted to the multiplier by forcing all agents to non-frontier models. Quality drop on hard refactors is sharp; you save spend and pay for it in re-runs. Mix: cheap models for boilerplate, frontier-on-Max for the core diff.
Treat each tab as a separate budget. A useful mental model: each Agent Tab is a small contractor with a clock running. You wouldn't open six tabs of contractors and then go to lunch. Don't do it here either.
Was it the right call?
Replacing Composer with the Agents Window is a strong opinion, and strong opinions in IDEs usually annoy the half of users whose workflow depended on the old shape. Glass is no exception. There's a real cohort of Cursor users for whom Composer 2 was already the optimal tool, who don't have multi-file parallelizable work, and who now have a more complex UI for the same single-agent task they were doing before.
For that cohort, Glass is overkill. You can still drive a single agent in the new window, but the cost of the redesign hits you and the benefit doesn't.
For everyone whose work actually benefits from parallel agents (a real and growing cohort, especially anyone refactoring large codebases or maintaining multi-package monorepos), Glass is the first IDE-level interface that takes parallel agentic coding seriously. The Agents Window is what JetBrains and VS Code don't have a clean answer to yet. Cursor's bet is that this is what every IDE will look like in 18 months, and that being early is worth the friction.
Whether the bet pays out depends on two things. Whether teams discover, the way Snap and others have started saying out loud, that more code is now AI-written than human-written. And whether the Max Mode pricing settles into something teams budget for instead of resent. The first looks more inevitable each quarter. The second is a question the pricing megathread is keeping live.
The right call, on balance, was a useful redesign with a debatable price tag attached. Use the Agents Window. Watch the bill.
If this was useful
The AI Agents Pocket Guide covers the orchestration patterns the Agents Window turns into shipped features: task decomposition, sub-agent boundaries, merging concurrent diffs, and the budget controls you need when "spin up another agent" stops being free. The Prompt Engineering Pocket Guide is the other half: how to write the prompt for each sub-agent so they don't overlap, retry sensibly, and finish the job you actually wanted.
Top comments (0)