Poolside vs Cursor: A Coding Model and a Coding Editor Are Not the Same Product

Poolside and Cursor are not competing products. Poolside is an AI lab that publishes open-weight coding models you can download and run; Cursor is an AI-first code editor that developers install and use every day.

That distinction decides the whole comparison. A model is an engine. An editor is the car. You can put many engines in one car, and this particular car has never been tied to one engine.

Poolside publishes its Laguna family on Hugging Face. Its model page lists Laguna S 2.1 at 118B total parameters with 8B active and a 1M-token context, and Laguna XS 2.1 at 33B total with 3B active and a 256K context (Poolside).

Cursor is sold per seat. As listed on Cursor's pricing page in August 2026, the plans are a free Hobby tier, a $20 per month individual Pro tier, and Teams pricing at $40 per user per month, with higher-limit tiers above Pro and custom Enterprise pricing. Plans change often, so confirm current tiers on that page before you budget.

Poolside vs. Cursor: Side-by-Side

These are two different product categories

Poolside sells a model; Cursor sells a workspace. Comparing them head to head only makes sense once you name which layer you are actually buying.

An open-weight model gives you the raw capability and nothing else. You supply the editor, the agent loop, the file context, the diff review, and the serving infrastructure.

An AI-first editor gives you all of that surrounding machinery and abstracts the model away. That is its value, and it is a real one — the harness around a coding model is where most of the engineering time goes.

What Poolside actually is

Poolside is a San Francisco AI lab building models for software development, and it now publishes those models as open weights. Licensing runs per variant rather than family-wide: the Laguna S 2.1 and XS 2.1 model cards on Hugging Face list OpenMDW 1.1, a permissive license backed by the Linux Foundation, while the earlier M.1 is Apache 2.0. Poolside's own site describes its licensing only as permissive and varying by model, so read the license file on the repository you download.

The published specs are unusual for a coding model. Poolside lists Laguna S 2.1 at 118B total parameters with 8B active per token and a 1M-token context, and the smaller Laguna XS 2.1 at 33B total with 3B active and a 256K context (Poolside).

The small active-parameter count is the interesting part. A sparse Mixture-of-Experts model with 8B active parameters serves far cheaper than its total size suggests, which is what makes a 118B model realistic to run on your own hardware.

• Open weights on Hugging Face, licensed per variant: OpenMDW 1.1 on Laguna S 2.1 and XS 2.1, Apache 2.0 on the earlier M.1
• Laguna S 2.1: 118B total / 8B active / 1M context (Poolside)
• Laguna XS 2.1: 33B total / 3B active / 256K context (Poolside)
• Weight formats include BF16, FP8, INT4, and NVFP4, plus official GGUF and MLX conversions
• Poolside publishes no rate card; hosted access runs through third-party providers, and OpenRouter listed Laguna S 2.1 at $0.09 input / $0.18 output per million tokens on August 2, 2026

What Cursor actually is

Cursor is an AI-first code editor — a full development environment built around an agent that reads your repository, proposes multi-file edits, and runs commands. The model is a component inside it, not the product.

That is why no single benchmark score describes it. Capability shifts with whichever frontier model you select inside the editor, and with how well the surrounding harness feeds that model context.

Pricing is per seat. As listed on Cursor's pricing page in August 2026, the plans are a free Hobby tier, a $20 per month Pro tier for individuals, $40 per user per month for Teams, higher-limit individual tiers above Pro, and custom Enterprise pricing. Confirm the current tiers on the vendor's own pricing page — they change frequently.

• An editor and agent harness, not a downloadable model
• Model choice happens inside the product
• Per-seat subscription pricing rather than per-token inference cost
• No self-hosting path for teams that need code to stay in-house

Cost: per seat versus per token

The two pricing models fail in opposite directions, and which one is cheaper depends entirely on your usage shape. Per-seat pricing is predictable and flat; per-token inference is variable and scales with how hard you push it.

A five-developer team on a $20/month individual plan has a known monthly cost regardless of how much code the agents write. The same team running an open-weight model pays for GPU hours or per-token calls, which can land well under or well over that number.

Self-hosting flips the equation again. Once you own or rent the GPUs, marginal inference is close to free, but you have paid for capacity whether you use it or not — and you now own the serving stack.

• Per-seat: predictable, no infrastructure, cost rises with headcount not usage
• Hosted per-token: no infrastructure, cost rises directly with agent activity
• Self-hosted: high fixed cost, near-zero marginal cost, and you run the serving stack
• Heavy agentic workloads are where per-token bills surprise people — long-horizon agent runs consume far more tokens than chat

→ Compare per-token pricing for every AI model

Where your code goes is the real decision for regulated teams

For teams under contractual or regulatory constraints on source code, self-hosting is the only answer that ends the conversation. Weights running inside your own network mean no third party ever sees the repository.

That is the strongest argument for an open-weight coding model, and it is the one argument no hosted editor can answer. Defense contractors, healthcare vendors, and financial firms with source-code confidentiality clauses hit this constraint regularly.

For everyone else, the hosted path is usually acceptable once you read the vendor's data-retention and training settings and configure them deliberately. Do read them rather than assuming a default.

You can often use both

These two choices are not mutually exclusive, and treating them as a fork is the most common mistake in this comparison. Open-weight coding models are reachable from many editors and agent harnesses.

Poolside lists day-one support across common serving stacks and agent platforms, including vLLM, SGLang, and Ollama for serving, and several third-party agent front ends. That means an open-weight model can sit behind whichever workflow your team already likes.

Layer3 Labs runs its own coding-agent fleet across a portfolio of content sites, and the pattern we keep hitting is that the harness matters more than the model for day-to-day throughput. A strong model in a weak harness loses context and repeats work; a mid-tier model with good repository context and a tight review loop ships more.

That observation cuts both ways here. It is an argument for paying for a mature editor when your constraint is developer productivity, and an argument for open weights when your constraint is where the code lives.

Who should pick what

Pick an open-weight model like Poolside Laguna when your code cannot leave your infrastructure, or when your agent usage is heavy enough that per-token or per-seat costs have become a real line item you want to control directly.

Pick an AI-first editor when you want productivity today with no infrastructure to run, and your code can go through a vendor's backend under settings you have reviewed.

Pick both when you have a regulated codebase and an unregulated one, which is more common than it sounds. The regulated repositories get the self-hosted model; everything else gets the fastest available workflow.

• Regulated or contractually restricted source code: self-hosted open-weight model
• Small team, no infrastructure appetite, wants results this week: AI-first editor
• Very heavy agentic usage with GPU capacity available: self-hosted open-weight model
• Mixed environment: both, split by repository sensitivity

What to verify before you commit

Every number in this comparison comes from a vendor's own published page, and every one of them can change without notice. Verify before you sign anything or size a cluster.

For Poolside, check the model card on Hugging Face for the exact license text and the current parameter and context figures. Vendor-published benchmark scores are a starting point, not an independent result.

For the editor, check the live pricing page for current tier names, limits, and per-seat costs, and read the data-retention and training-opt-out settings against your own policy.

• License file on the exact model repository you download
• Current parameter count, active parameters, and context window on the vendor page
• Current per-seat pricing and what each tier limits
• Data retention, training opt-out, and code-privacy settings
• Whether your serving stack supports the model architecture and quantization you need

The Verdict

If your constraint is where your source code goes, Poolside wins — open weights on the Laguna S 2.1 and XS 2.1 variants under OpenMDW 1.1, published in quantized formats, servable inside your own network. No hosted editor can match that, at any price.

That is a category split rather than a scoreboard. These are two layers of the same stack, not two versions of the same product, so the buying question is which layer your constraint lives in — and the answer above only holds when the constraint is code custody.

If your constraint is developer productivity per dollar of engineering time, an AI-first editor wins, because it hands you a working agent harness you would otherwise build yourself. Cursor is one of the mature options in that category and worth evaluating on its current pricing and privacy settings, not on a benchmark score. And if you have both a regulated codebase and a normal one, the correct answer is genuinely both. Prices, licenses, and model specs change without notice — confirm each on the vendor's own page before you commit.