Tried another quick cross-model test using both my Rosetta MCP in Claude Code (with Anthropic subscription) as well as Gemini (set the "Pro" on free plan) and ChatGPT (using it default free site) from the 7.24beta2 release note:
The obvious question which actually product models does that list of switch chip resolve?
So I prompted Claude Opus 4.8 which has a ton of pre-loaded RouterOS stuff, including my Rosetta MCP doc tool. And then tried "steering" Gemini and ChatGPT website (using logged in but "free plan" on these).
Claude Code answer...
Cross-checked. I pulled the full devices.csv catalog and matched it against
the doc-derived mapping. Here's how they line up:
CSV cross-check vs. doc mapping
┌───────────┬──────────────────────────────┬──────────────┬──────────────┐
│ Chip │ │ In │ │
│ (release │ Model(s) from doc │ devices.csv? │ CSV cpu field│
│ note) │ │ │ |
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ │ │ │ 98DX8208 ✅ │
│ 98DX8208 │ CRS309-1G-8S+IN │ ✅ │ direct chip │
│ │ │ │ match │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ │ │ │ 98DX8216 ✅ │
│ 98DX8216 │ CRS317-1G-16S+RM │ ✅ │ direct chip │
│ │ │ │ match │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ 98DX8212 │ CRS312-4C+8XG-RM │ ✅ │ QCA9531 │
│ │ │ │ (mgmt CPU) │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ 98DX8332 │ CRS326-24S+2Q+RM · │ ✅ ✅ │ QCA9531 │
│ │ CRS326-4C+20G+2Q+RM │ │ (both) │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ 98DX3257 │ CRS354-48G-4S+2Q+RM · │ ✅ ✅ │ QCA9531 │
│ │ CRS354-48P-4S+2Q+RM │ │ (both) │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ │ CRS504-4XQ-IN · │ │ QCA9531 │
│ 98DX4310 │ CRS504-4XQ-OUT · │ ✅ ✅ ✅ ✅ │ (CRS5xx) / │
│ │ CRS510-8XS-2XQ-IN · │ │ AL73400 │
│ │ RDS2216-2XG-4S+4XS-2XQ │ │ (RDS2216) │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ 98DX8525 │ CCR2216-1G-12XS-2XQ · │ ✅ ✅ │ AL73400 / │
│ │ CRS518-16XS-2XQ-RM │ │ QCA9531 │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ 98CX8410 │ CRS520-4XS-16XQ-RM │ ✅ │ AL52400 │
├───────────┼──────────────────────────────┼──────────────┼──────────────┤
│ 98DX3255 │ CCR2116-12G-4S+ │ ✅ │ AL73400 │
└───────────┴──────────────────────────────┴──────────────┴──────────────┘
Result: the answer aligns 
All 14 product SKUs from the doc-based mapping exist as real products in
devices.csv — every model name checks out.
The one nuance worth calling out: the CSV's cpu column only stores the Marvell
switch ASIC for the cases where the switch chip is the main processor — the
older ARM 32-bit CRS3xx boxes (CRS309→98DX8208, CRS317→98DX8216). For every
other product, the cpu field records the management/control CPU (QCA9531,
AL73400, AL52400), and the switch ASIC isn't stored at all. That's exactly
why:
- A direct CSV/device_lookup query on the chip ID only ever resolves 2 of 9
chips (8208, 8216). - The other 7 chips return nothing in a chip-string search — not because the
products are missing, but because the catalog doesn't carry the switch-ASIC
field for them.
So the two data sources are consistent: the L3HW doc table is the
authoritative chip→model source (it's the only place the switch ASIC is
recorded for QCA9531/AL-managed boxes), and the devices.csv confirms every
resolved model is a genuine SKU. No contradictions, nothing to revise in the
earlier answer.
One small data-quality note for the rosetta dataset itself: if you wanted
chip-ID lookups to work directly for all these switches, the devices table
would need a separate switch_chip column distinct from cpu — right now those
two facts are conflated into one field.
ChatGPT combine the results with a quick summary:
Short answer: Claude's answer is the strongest, Gemini's is nearly correct, and my answer was functionally equivalent to Claude's for the original question.
The key distinction is what question was being answered.
If the question is:
"What specific MikroTik products correspond to the switch ASICs listed in the 7.24beta2 release note?"
Then the canonical answer is:
| ASIC | Products |
|---|---|
| 98DX8208 | CRS309-1G-8S+IN |
| 98DX8216 | CRS317-1G-16S+RM |
| 98DX8212 | CRS312-4C+8XG-RM |
| 98DX8332 | CRS326-24S+2Q+RM, CRS326-4C+20G+2Q+RM |
| 98DX3257 | CRS354-48G-4S+2Q+RM, CRS354-48P-4S+2Q+RM |
| 98DX4310 | CRS504-4XQ-IN, CRS504-4XQ-OUT, CRS510-8XS-2XQ-IN, RDS2216-2XG-4S+4XS-2XQ |
| 98DX8525 | CCR2216-1G-12XS-2XQ, CRS518-16XS-2XQ-RM |
| 98DX3255 | CCR2116-12G-4S+ |
| 98CX8410 | CRS520-4XS-16XQ-RM |
Claude, your Rosetta MCP, and my answer all agree on that table.
Where Gemini is slightly weaker
Gemini says:
"98DX3257 – CRS354-48G-4S+2Q+RM (and potentially its PoE variant CRS354-48P-4S+2Q+RM)"
The word "potentially" is unnecessary.
The MikroTik L3HW documentation explicitly associates the 98DX3257 family with both CRS354 variants. So Claude's answer is more precise here.
Gemini also omitted:
- CRS504-4XQ-IN
- CRS518-16XS-2XQ-RM
- RDS2216-2XG-4S+4XS-2XQ
Those omissions matter because the release note names ASICs, not product families.
Where Claude goes beyond the original question
Claude's table includes a second level of validation:
- cross-checking against
devices.csv - noting when the ASIC appears in the CPU column versus being a companion switch ASIC
- identifying management CPUs (QCA9531, AL73400, etc.)
That's useful metadata, but it isn't actually required to answer the release note.
For example:
- CRS309 uses the 98DX8208 as the main SoC.
- CRS312 uses a QCA9531 management CPU plus a 98DX8212 switch ASIC.
That distinction explains why some MikroTik inventories can be confusing, especially when you're mining devices.csv.
One thing Claude caught that many models miss
The release note says:
added HW offloaded VRF support on ... switches
Yet the list contains:
- CCR2116 (98DX3255)
- CCR2216 (98DX8525)
Those are routers, not switches.
The only way the release note makes sense is if MikroTik is referring to the Prestera switch ASICs that exist inside those CCR platforms, not the product category itself.
That's exactly how I interpreted it as well.
If I were ranking them
For RouterOS/MikroTik accuracy specifically:
- Claude + Rosetta MCP — best answer because it validated against MikroTik-specific structured data and exposed the chip/CPU nuance.
- My answer — correct mapping, but lacked the extra validation layer.
- Gemini — mostly correct but omitted several products and expressed uncertainty where the docs appear definitive.
What I find more interesting is not the final table—which all three systems mostly agree on—but why Claude got there. The Rosetta MCP appears to have access to a normalized device database (devices.csv) plus documentation lookup, which is exactly the sort of grounding that prevents the classic RouterOS failure mode you've complained about before: mixing switch ASICs, management CPUs, and RouterBOARD product names from old wiki-era training data.
For MikroTik questions, a model with access to:
product.csv/devices.csvmanual.mikrotik.com.mdllms.txt
will almost always beat a foundation model relying on pretraining alone, because the hard part isn't networking knowledge—it's the ever-changing MikroTik hardware matrix.