Nemotron 3.5 Lightning for Coding

Nemotron 3.5 Lightning is a strong open-weight pick for coding agents. NVIDIA reports a SWE-bench Verified score of 51.56 for the BF16 checkpoint. That puts a small, cheap model within reach of real bug-fixing work.

The model is a 30B total, 3B active Mixture-of-Experts. It routes each token through a slice of its experts. So you get big-model knowledge at small-model speed and cost.

This guide shows the coding use case. You will see where it fits, how to wire it into an agent loop, and where it still trails closed frontier models.

Why Nemotron 3.5 Lightning Fits Coding Agents

Nemotron 3.5 Lightning was built for long-running agents that run many tasks in a row. NVIDIA positions it for fast, accurate specialized task execution. Coding agents are exactly that kind of workload.

A coding agent rarely writes one answer and stops. It reads files, edits code, runs tests, and reads the errors. Then it tries again. This loop can span dozens of steps.

Speed and cost matter across that whole loop. NVIDIA claims up to 4x output speed versus similar-sized models. On a task that spends thousands of tokens, faster output means a faster agent.

What the SWE-bench Verified 51.56 Number Means

SWE-bench Verified 51.56 means the model resolved about 51.56 percent of a curated set of real software issues, per NVIDIA's published numbers. SWE-bench draws its tasks from real GitHub issues in open-source Python projects.

Each task hands the model a repository and a bug report. The model must produce a patch that makes the hidden tests pass. It is a strict, end-to-end coding test, not a trivia quiz.

A score near 51 is strong for a model this small and cheap. Always verify the current figure on the model card, since benchmark numbers get revised.

The Agentic and Long-task Strength

The model's real edge is holding context across a long task. It supports a context window of up to 1 million tokens. A coding agent can keep many files, logs, and prior steps in view at once.

NVIDIA reports it completes 10,000 tasks about 30 percent faster than Qwen3.6-35B at similar accuracy. For a fleet of agents, that time adds up fast.

The hybrid design helps here. It interleaves Mamba-2 layers, MoE layers, and select attention layers. The Mamba-2 layers handle long sequences at lower cost than pure attention.

How to Wire It into a Dev or Agent Workflow

Start by picking an access path. You can call the hosted endpoint on build.nvidia.com, or self-host the open weights with a stack like vLLM. Hosted is faster to try; self-host gives you control.

Next, connect the model to your agent framework. Point your coding agent's model client at the endpoint and give it tools. Typical tools are read file, write file, run shell, and run tests.

Then set a task loop. The agent reads the issue, plans an edit, applies it, and runs the tests. It reads the test output and repeats until the tests pass or a step cap is hit.

Keep the loop cheap by feeding only the files that matter. Even with a large context window, tighter prompts run faster and cost less to serve.

The Cost and Speed Advantage of a 3B-active Open Model

With 3B active parameters, each token touches a small share of the network. That is why a 30B-total model can serve tokens at high speed on modest hardware.

The open weights change the cost model. Self-hosting is $0 in license fees; you pay only for hardware and operations. Hosted endpoints on build.nvidia.com charge per token, so check the live rate there.

In our work evaluating open-weight models for clients, the recurring win is agent economics. A cheaper per-token model lets you run more attempts per bug, which raises the odds of a passing patch.

NVIDIA also claims performance comparable to gpt-oss-120b at about one quarter of the total parameters. If that holds for your tasks, you get similar quality for far less compute.

Real Limits Versus Frontier Closed Models

A SWE-bench Verified score near 51 trails the best closed frontier models on hard, multi-file refactors. On the toughest tasks, a top proprietary model still resolves more issues.

The model is specialized for task execution, not open-ended reasoning about a whole product. For deep architecture decisions, pair it with human review or a stronger model.

Small active-parameter models can also miss rare library details. Give it the docs it needs in context rather than trusting recall. Verify every patch with real tests before you merge.

A Worked Agent Loop: Fix One Failing Test

Here is a concrete plan-edit-test loop for a single bug. The agent starts with a repository and one failing test. It works in small steps until the test passes.

Step one is plan. The agent reads the failing test and the error message. It lists the files that likely hold the bug and picks the first one to open.

Step two is edit. The agent opens the file, finds the broken function, and writes a small patch. It changes as little as possible to keep the diff easy to check.

Step three is test. The agent runs the test suite and reads the output. A pass ends the loop. A failure feeds the new error back into the next plan step.

Step four is iterate. The agent repeats plan, edit, and test until the tests pass or a step cap stops it. The 1 million token window keeps every prior step in view.

This is the workload NVIDIA built the model for. Long-running agents run many such loops in a row. The 4x output speed claim shows up as a shorter wait per loop.

What Tools and Permissions to Give the Coding Agent

Give the agent a small, clear set of tools and scoped permissions. A coding agent needs to read files, write files, run shell commands, and run tests. Start with those four.

Scope the file tools to the repository. Let the agent read and write inside the project folder only. Block writes to system paths so a bad step cannot spread.

Limit the shell tool to safe commands. Allow test runners, linters, and build steps. Block network calls and destructive commands unless a human approves them first.

Add a step cap and a diff review gate. The cap stops a runaway loop. The gate holds the final patch for a human to read before it merges.

In our work evaluating open-weight models for clients, the recurring failure mode is over-broad tool access. A tight tool set with scoped permissions is safer and easier to debug than a wide one.

Coding Failure Modes to Watch For

Watch for three common failure modes when a coding agent runs on this model. Each has a simple guard you can set up front.

The first is a passing test that hides a broken feature. The agent can edit the test instead of the code. Lock the test files as read-only so it must fix the real bug.

The second is a stall on a hard multi-file refactor. A SWE-bench Verified score near 51.56 trails top closed models on the toughest tasks. Route those cases to human review or a stronger model.

The third is a missed library detail. A 3B-active model can lack rare API knowledge. Feed the relevant docs into the context window rather than trusting recall.

Verify every patch with real tests before you merge. Treat the agent as a fast junior engineer, not a final authority. The guards above keep its speed from turning into risk.

Using Nemotron 3.5 Lightning in a CI or Review Pipeline

Nemotron 3.5 Lightning fits well as a fast reviewer inside a CI pipeline. Its speed lets it read a diff, flag issues, and suggest patches on every pull request without slowing the build.

A 3B-active design keeps the per-call cost low at high pull-request volume. That matters when a team opens dozens of PRs a day and wants an automated first-pass review on each one.

Self-hosting the open weights also keeps private source code on your own hardware. Regulated teams and teams with strict IP rules can run the model in their own network instead of sending code to a third-party API. Pair the review pass with your existing test suite, and treat every suggested patch as a draft a human still approves.