Nemotron 3.5 Lightning as a Cursor and Cline Local Backend in 2026: Free in Cline, 4× Faster — and Not Your Main Coding Model

nemotronnvidiaollamaclinecursorlocal-llmsetup-guide

TL;DR: NVIDIA released Nemotron 3.5 Lightning on August 11, 2026 — a 30B MoE with ~3B active parameters, a 1M-token context window, and an OpenMDW-1.1 license, now free inside Cline. It is the fastest tool-calling model in the 24GB local class, but on coding benchmarks it loses to Ornith-1.0 35B by 24 points. Use it as your agent’s executor, not its brain.

Nemotron 3.5 Lightning (local)Ornith-1.0 35B (local)Muse Glimmer 30B (local)
Best forFast tool-call loops, subagents, always-on background agentsMain coding backend: implement, test, fixMCP orchestration, multimodal agent input
SWE-bench Verified51.6 (NVIDIA-reported)75.676.0 (Meta-reported)
License / costOpenMDW-1.1, free weights; free hosted tier in ClineMIT, free weightsApache 2.0, free weights
The catchTerminal-Bench 2.1 of 24.6 — worst-in-class for autonomous terminal workSlower generation (~3B active but no MTP speedups)ATEM parser dependency, NVIDIA Ollama support lagging

Honest take: If you want one local model behind Cursor or Cline on a 24GB card, that model is still Ornith-1.0 35B, not Lightning. Pull Lightning anyway — as the free Cline model for grunt tasks and as a subagent executor it’s genuinely the fastest thing in its class, and free is free.

NVIDIA’s queue of open-weight drops has been relentless this year, and the August 11 release slots into a specific gap: not a frontier reasoner, not a coding specialist, but what NVIDIA’s engineering blog calls the “execution layer” of agentic systems — the tool calls, retrieval, validation, formatting, and summarization steps that burn most of an agent’s token budget without needing frontier intelligence. Within four days, Ollama shipped it, Cline made it free for all users, and OpenRouter stood up a :free endpoint. That distribution blitz is why your feeds are full of it this week.

The question for this site is narrower: should Nemotron 3.5 Lightning be the model behind your Cursor, Cline, or Claude Code sessions? The answer depends entirely on which seat you give it. Everything below was verified August 15, 2026 against NVIDIA’s technical blog, the Hugging Face model cards, Ollama’s release announcement, and Cline’s launch post — with the recurring sandbox note: several official pages were cross-verified through search summaries because direct fetches are egress-blocked in this environment.

What Nemotron 3.5 Lightning actually is

Lightning is a 30B-total, ~3B-active mixture-of-experts model (the “30B-A3B” in its Hugging Face name), distilled from NVIDIA’s 550B Nemotron 3 Ultra and pre-trained on over 20 trillion tokens. The architecture is a hybrid Mamba-transformer — state-space layers instead of attention for most of the stack — which is how it holds a 1M-token validated context window without the KV-cache bill a pure transformer would run up. On top of that, NVIDIA layered multi-token prediction and speculative decoding, which is where the headline “up to 4× throughput vs. comparable open models” claim comes from.

The license is OpenMDW-1.1, and NVIDIA released not just weights but training data and recipes. That’s a genuinely permissive package — no user-count clauses, fine-tuning explicitly encouraged — and it matters for the model’s stated purpose: a cheap, fast worker you fine-tune on your own narrow tasks.

Distribution on day one:

ChannelWhat you get
Hugging Face BF16Full-precision checkpoint (~60GB class)
Hugging Face NVFP4NVIDIA’s 4-bit quantization — the practical RTX checkpoint
Ollama librarylatest ~25GB; NVFP4 ~23GB; MXFP8 ~34GB; BF16 ~66GB; MLX builds for Apple Silicon
unsloth GGUFCommunity GGUF conversions for llama.cpp and LM Studio
OpenRouterHosted API, including a free tier

Released alongside it: NeMo SwitchYard, an open-source model router that decides per-task whether to run Lightning locally or escalate to a bigger hosted model. Keep that in mind — it’s the clearest signal of how NVIDIA itself thinks this model should be used.

The coding benchmark reality check

The premise worth testing was whether Lightning’s speed comes with enough coding ability to displace the current 24GB-class favorites. NVIDIA’s own reported numbers settle it fast:

BenchmarkLightning (BF16)Lightning (NVFP4)Ornith-1.0 35BClaude Sonnet 5 (API)
SWE-bench Verified51.652.875.685.2
Terminal-Bench 2.124.623.564.280.4
PinchBench (10K agentic tasks)85.4n/an/a

Two things jump out. First, the NVFP4 quant essentially matches BF16 — quantization isn’t the problem, so run the 4-bit build without guilt. Second, that Terminal-Bench score is not a typo. At 24.6, Lightning completes roughly a third as many autonomous terminal tasks as Ornith-1.0 at the same VRAM budget. Hand it a Cline session that needs to install dependencies, run a test suite, read the failures, and iterate — the exact loop Terminal-Bench measures — and it will fall over regularly.

On llm-stats’ 14-row comparison against Qwen3.6-35B-A3B, Lightning loses 13 rows. Its single win is IFBench instruction-following (71.9 vs 63.7), and that win is the tell: this model is very good at doing exactly what it’s told — format this, call that tool, validate this output — and mediocre at figuring out what to do. NVIDIA never claimed otherwise. The launch post positions it for “specialized task execution for long-running agents,” and PinchBench, the benchmark NVIDIA leads with, measures completing 10,000 short agentic tasks quickly (86% accuracy, 30–35% faster than Qwen3.6 MoE at comparable accuracy) — not resolving GitHub issues.

So the reframe: Lightning isn’t a worse Ornith. It’s a different tool that happens to fit the same GPU.

The 4× speed claim, against independent numbers

NVIDIA’s marketing number is “up to 4× the throughput of similarly-sized open models.” What do outside measurements say?

  • Artificial Analysis clocked the hosted API at 293 output tokens/second — several times faster than typical 30B-class endpoints.
  • Kubesimplify’s DGX Spark test through Ollama measured 71–73 tok/s decode on short runs and 2,583 tok/s prompt processing on long-context runs.
  • DevelopersIO measured 79.6 tok/s standalone on DGX Spark, 115.8 tok/s with the DSpark speculative-decoding drafter loaded, and 421.9 tok/s aggregate across 8 concurrent instances — that last number being the “always-on agent fleet” scenario NVIDIA designed for.

No stable community numbers existed yet for RTX 3090/4090 cards at publication time; we’ll update when they land. But the pattern from the DGX Spark data holds: real-time-readable single-stream speed, and unusually strong concurrent throughput because only ~3B parameters activate per token. For interactive Cursor chat that’s nice. For four subagents running simultaneously on one card, it’s the whole point.

Setup: Ollama, Cline, Cursor, Claude Code

Ollama (v0.12+ class releases have the model; update first):

ollama pull nemotron-3.5-lightning        # default tag, ~25GB
ollama run nemotron-3.5-lightning "write a pytest fixture for a temp sqlite db"

Here’s the problem we hit on paper before pulling: the default tag is ~25GB, and a 24GB card is not 25GB. On an RTX 3090 or RTX 4090, the default pull will spill layers to CPU and your tok/s collapses — the same silent-fallback failure mode we documented in Ollama not using your GPU. The fix is two-part. Pull the NVFP4 build (~23GB) instead of latest, and cap the context allocation — Kubesimplify’s testing confirmed Ollama reserves a 262,144-token context window for this model by default, which adds KV cache on top of weights. On a 24GB card:

ollama pull nemotron-3.5-lightning:30b-a3b-nvfp4
OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Even then, 23GB of weights plus KV on a 24GB card is the tightest squeeze we’ve covered in this series — tighter than Ornith’s 20GB Q4_K_M or Muse Glimmer’s 17GB K-Quant. If you’re on 24GB, unsloth’s smaller GGUF conversions through llama.cpp or LM Studio are the more comfortable path. On 32GB+ or a DGX Spark’s unified pool, the Ollama default is fine as-is. Our num_ctx deep dive covers why the context cap matters for agent tools specifically.

Cline gives you three routes, fastest first:

  1. The free hosted tier. Cline made Lightning free for all users at launch — select the Cline provider and pick Nemotron 3.5 Lightning from the model list. Zero setup, zero GPU, up to 1M context. This is the easiest way to feel the model out before committing disk space.
  2. OpenRouter: provider OpenRouter, model nvidia/nemotron-3.5-lightning:free.
  3. Fully local: provider OpenAI Compatible, Base URL http://localhost:11434/v1, model ID nemotron-3.5-lightning:30b-a3b-nvfp4, any non-empty API key. Standard JSON tool calling works out of the box — Ollama lists tools as a supported capability, with none of the custom-parser drama that Muse Glimmer’s ATEM format requires.

Cursor remains the awkward local citizen: Chat and Cmd+K work through a custom OpenAI-compatible endpoint, but Cursor’s server-side routing means a bare localhost URL won’t reach your machine — the tunnel workaround and its limits are in our Cursor + Ollama guide. Given Lightning’s benchmark profile, we’d honestly skip Cursor entirely here; this isn’t a Chat-quality model.

Claude Code is the one-liner NVIDIA and Ollama are jointly advertising:

ollama launch claude --model nemotron-3.5-lightning

That wires Anthropic’s terminal agent to the local model via Ollama’s launch integration — the same mechanism we walked through in the Claude Code + Ollama setup. It works, but remember the Terminal-Bench number before you hand it a multi-step refactor: 24.6 means the agent harness is writing checks the model can’t cash.

Where Lightning actually earns its VRAM

Match the seat to the benchmark profile and the model makes sense:

The subagent executor. In a multi-agent setup — the orchestration pattern we mapped in June — the orchestrator needs judgment, but the workers mostly need to call tools fast and follow instructions exactly. IFBench 71.9 and 4× throughput is precisely that job description. Lightning running three concurrent workers on one card while a hosted Sonnet 5 orchestrates is a legitimately new price-performance point.

Always-on background agents. Hermes Agent and similar always-on setups burn tokens around the clock on triage, summarization, and validation. A 3B-active model that idles cheap and bursts to hundreds of tok/s across instances is built for exactly this — it’s the “always-on agents” framing in Ollama’s own announcement.

The SwitchYard pattern. NeMo SwitchYard routing formalizes what budget-conscious developers already do by hand: send the 80% of steps that are mechanical to the free local model, escalate the 20% that need real reasoning. If DeepSeek’s announced price hike lands, this hybrid gets more attractive, not less.

Fine-tuning base. OpenMDW-1.1 plus released training recipes plus 3B active parameters means single-card fine-tuning on your own task distribution is realistic. None of the other 24GB-class models ship with this level of reproducibility.

What it should not be: the model you point Cline at for “implement this feature and make the tests pass.” That’s Ornith-1.0’s seat on a used RTX 3090, and nothing in this release changes it. For which GPU tier runs the bigger Nemotron family members, runaihome has the Nemotron 3 Ultra hardware guide and the Ornith GPU guide.

Verdict

Lightning is the first local model we’ve covered that’s honest about being infrastructure. NVIDIA didn’t claim SWE-bench glory; it built a fast, permissively licensed, fine-tunable executor and shipped it everywhere at once — including free tiers that cost you nothing to adopt. Judged as a main coding backend it’s a clear no: 51.6 SWE-bench Verified and 24.6 Terminal-Bench put it far behind Ornith-1.0 at identical VRAM. Judged as the execution layer under a smarter orchestrator, it’s the best free option that exists today, and the free Cline tier means you can verify that against your own workload in five minutes.

FAQ

Is Nemotron 3.5 Lightning better than Ornith-1.0 for coding? No, and it isn’t close: 51.6 vs 75.6 on SWE-bench Verified, 24.6 vs 64.2 on Terminal-Bench 2.1 (NVIDIA-reported vs the numbers we verified for Ornith in July). Lightning wins on generation speed, context length (1M vs 128K-class), and concurrent throughput.

Does it really have a 1M context window locally? The model validates 1M tokens, and Cline’s hosted tier advertises up to 1M. Locally, KV cache is the constraint: Ollama defaults this model to a 262K window, and on a 24GB card you’ll want 32K. Long-context is real on unified-memory machines (DGX Spark ran 256K with ~86GB of pool to spare); on consumer GPUs treat 1M as theoretical.

Is the free Cline tier a trap? It’s an adoption play, and NVIDIA’s incentive is selling the hardware the model runs on — same reason the license is generous. Standard caveat for any free hosted endpoint applies: assume prompts may be logged, and keep client code you’re contractually obligated to protect on the local path instead.

Will it run on a 12GB or 16GB card? Not the official builds — NVFP4 is ~23GB before KV cache. Watch unsloth’s GGUF repo for smaller quants; MoE models with 3B active parameters usually quantize down further with tolerable damage, but nobody had published quality numbers for sub-4-bit Lightning quants as of August 15. On smaller cards, the 12B-class picks in our Mellum 2 guide remain the honest answer.

  • RTX 4090 — 24GB with the throughput headroom to make Lightning’s speculative decoding visible
  • RTX 3090 — the budget 24GB entry point, though Lightning’s NVFP4 build is a tight fit

Sources

Last verified August 15, 2026. Pricing, model availability, and runtime support change frequently — verify current state before building on any of it.

Was this article helpful?