Bolt pulled facts from a short product packet correctly on my ASUS ProArt P16. Add a pile of unrelated material, though, and it chose the wrong Raspberry Pi variant in all three attempts. Getting a usable answer depended on the job I gave it and how closely the result was checked.
That puts NVIDIA’s Nemotron 3.5 Bolt in a practical role for my work: preparing source-based information for review. Product facts, model comparisons and image descriptions all feed into an article. A mistake at that stage can travel straight into the finished copy, especially when the answer arrives in a neat table or structured record.
My initial P16 review covers the machine and my everyday setup. I ran these tests on one laptop, my ASUS ProArt P16, on one day, October 28, and my agent, assa, ran and checked the workloads. The local timings here are three-run medians from standalone llama.cpp, rather than complete Hermes agent-job timings. Hermes also has to read files, follow its application instructions and return a result.
Start with a product packet
Give Bolt a short packet and ask for specific facts, and there’s a workable starting point. In the development tests, it returned the expected price and specification fields, compared exact product tiers and removed duplicate records correctly in all three repetitions of each task.
It also completed a supervised file-reading task through Hermes, though its answer kept unavailable details empty and separated advertised capabilities from evidence of what had actually been installed or measured. That’s the preparation I want from a local assistant: read a supplied source, organize it and leave a visible gap where the source doesn’t answer the question.
The task still needs a precise output contract. One media-record test wanted a true-or-false value for whether image pixels had been inspected. Bolt returned the number zero, though, and with an added reminder, it returned null instead. Neither was the requested Boolean false. The checker has to catch that.
That distinction can look fussy in a chat window, though in a workflow that sends a record to another program, it can decide whether an image is treated as checked. Our first scoring script also accepted zero as equal to false. A stricter type check corrected the score, with the original answers preserved. The checker needs testing too.
How long the local answer takes
In a short generation test capped at 256 output tokens, Bolt produced a median 23.60 tokens per second across three runs, though the first text on the small structured-extraction task arrived in a median 0.476 seconds. Starting the process and loading the model to readiness took a median 9.33 seconds in the 8K-context setup, with the operating system’s disk cache uncontrolled. That start cost is part of the wait.
Longer input adds a wait before the answer starts, though all three repetitions at each length passed. With 5,863 input tokens, median first-content time was 20.082 seconds. At 11,863 tokens, it was 33.389 seconds. Those tasks asked for markers near the beginning and end of the supplied text. That wait grows with the packet.
| Local workload | Median first content | Median generation rate | Result |
|---|---|---|---|
| Short structured extraction | 0.476 seconds | 24.26 tokens/s | 3/3 exact matches |
| 256-token generation | 0.326 seconds | 23.60 tokens/s | Speed test, output capped |
| 5,863-token input | 20.082 seconds | 22.87 tokens/s | 3/3 marker-retrieval matches |
| 11,863-token input | 33.389 seconds | 21.78 tokens/s | 3/3 marker-retrieval matches |
A longer brief can change the answer
The harder Raspberry Pi case put 200 unrelated records ahead of the relevant source. Bolt selected the wrong variant and Wi-Fi value in all three baseline attempts, though it had passed the compact version of the task three times. That is the split in this piece.
Adding general instructions didn’t solve that problem. Across five held-out cases, the baseline passed 12 of 15 repeated trials. The added-instruction version passed nine, though it also turned the previously correct compact Pico task into three failures. General advice made the tight case worse.
A specific correction worked better. The next request included the previous answer and named the mismatched fields, without supplying the expected values. Bolt corrected all three distractor-heavy answers, though those extra calls took a combined 78.189 seconds. Including the original failed attempts, the three two-attempt jobs consumed 154.977 seconds of request time.
That’s a usable repair for this case, with a real time cost. Keep source packets focused, check the exact model and variant, and return a concrete error instead of asking the model to generally “be more careful.”
Reading a display isn’t identifying every part
The photo tests used three official Segway images: a street scene, a dashboard and a brake detail. Bolt read the dashboard text correctly across all six answers to that image, though it also repeatedly called the circular fork-top components lights. That error is easy to miss in a neat description.
All 18 photo responses passed the required structure and unknown-specification checks. That meant they avoided filling in unsupported exact specifications. Structure passed. Identification did not.
For my articles, I’d use that output as a draft description beside the original photograph, though exact component names, small labels and implied functions need another look before they become captions or feature claims. That is draft work, not final copy.
Luna, Terra and Astra on the same tasks
Each cloud model received the same five exact-output task inputs and three photo inputs. Luna, Terra and Astra each passed the five exact-output cases in their single attempts, including the distractor-heavy Pico question that Bolt missed in all three baseline repetitions. That is a clean contrast on the cluttered case.
| Exact-output case | Bolt baseline | Luna | Terra | Astra |
|---|---|---|---|---|
| Held-out label reading | 3/3 | 1/1 | 1/1 | 1/1 |
| Compact Pico variant | 3/3 | 1/1 | 1/1 | 1/1 |
| Pi 5 accessories | 3/3 | 1/1 | 1/1 | 1/1 |
| Public media record | 3/3 | 1/1 | 1/1 | 1/1 |
| Pico with unrelated records | 0/3 | 1/1 | 1/1 | 1/1 |
The photos separated them further. Luna described the dashboard viewpoint incorrectly. Both Luna and Terra used an unsupported lens-like description for the circular hardware, though Astra described its visible shape without assigning that function and covered the required feature groups in these three images.
I keep a separate review step for difficult source reconciliation and visual claims. The cloud runs used their native agent environments with xhigh reasoning, while the Bolt tests had thinking disabled. Each cloud model produced one answer per case, versus Bolt’s three repeats.
Reusing the same input cuts the opening wait
A separate six-request test enabled prompt caching and repeated an identical request twice after its first run, using one text case and one image case in a fixed order. For text, the first-content wait changed from 1.460 seconds to 0.168 and 0.177 seconds. For the image request, it changed from 12.547 seconds to 0.205 and 0.206 seconds.
The runtime reported reused tokens, and the answer stayed identical within each group. It was reusing processed context, though, not learning new model weights. This is promising for repeated work on an unchanged packet. Reuse helps when the packet does not change.
What I’d hand off now
I’d start with a short public source packet and a small list of fields. Keep the source beside the answer, check exact product names and variants, and reject a record that doesn’t meet the required types. assa can check that preparation before it reaches the article, though difficult comparisons and image captions stay in the review step, rather than flowing straight into publication. That is the handoff I trust.
The smaller Nano model also read the same public file as Bolt in a separate Hermes comparison. Both returned all ten checked facts correctly, though neither fully answered the requested qualification about measured context. That application-level result gives me no reason to choose a model solely by its parameter count.
The P16 can run this local text-and-image workload through native ARM64 CUDA. In the later logged runs, all 89 model layers were offloaded to the GPU. For a writer or researcher who wants to prepare short source packets locally, that is a concrete capability to use with a checker. Bolt earns local prep work: drafting from short source packets with a checker in the loop. It does not get unattended final answers. The wrong variant and the invented lights are the reason.
