DEV Community: Anup Karanjkar

JSON-LD Rich Results 2026: What Google Still Shows

Anup Karanjkar — Wed, 11 Nov 2026 04:36:16 +0000

As of November 10, 2026, Google no longer shows FAQ rich results for any site. The feature stopped appearing on May 7, 2026, per Google's Search Central documentation changelog, and Google removed the FAQ docs on June 15, 2026. It is the latest cut in a cleanup that started with HowTo in 2023, took out the sitelinks search box in 2024, and cut six more types in 2025 (Google announced seven, then kept Book actions in a limited form). What still works is the list on Google's structured data search gallery: Article, Product, Review snippet, Breadcrumb, Organization, Local business, Video, Event, Recipe, Job posting, Software app and a handful of others. Below: a status table with dates and sources for every type, minimal JSON-LD for the five types most sites need, and a testing workflow that won't send you chasing a feature Google has already removed.

How we checked: the WOWHOW team read Google's search gallery, the Search Central changelog, the relevant Search Central blog posts and each feature's documentation page on November 10, 2026. Every status below links to the Google page it comes from. Where Google's own wording is narrower than "shown" or "retired", the table says so.

TL;DR

Retired: FAQ (May 7, 2026), HowTo (September 13, 2023), sitelinks search box (November 21, 2024), Course info, Estimated salary, Learning video, Special announcement, Vehicle listing, ClaimReview (phased out in 2025) and Practice problem (docs removed January 6, 2026).
Limited: Breadcrumbs show on desktop only, Book actions is restricted to large book providers, Dataset markup feeds Dataset Search rather than Google Search, and Event results require a physical venue.
Still documented: Article, Product (snippets and merchant listings), Review snippet, Organization, Local business, Video, Recipe, Job posting, Software app, Q&A, Discussion forum, Profile page, Education Q&A, Math solver, Carousel, Employer aggregate rating, Subscription and paywalled content and more.
Valid markup makes a page eligible. Google states plainly that it does not guarantee a rich result.

Rich result status in November 2026

The table sorts every type we could pin to a Google source. "Still shown" means the type sits in the current search gallery with a live documentation page. Dates are when the change took effect or, where Google gave no effective date, when it was announced.

Rich result type	Status	Date	Google source

| FAQ | Retired | May 7, 2026 | Changelog |

| Course info, Estimated salary, Learning video, Special announcement, Vehicle listing | Retired | Announced June 12, 2025; docs removed September 9, 2025 | Search Central blog |

Google's 2023, 2024 and June 2025 retirement posts each say the change does not affect ranking. The June 2025 announcement put it as "This update won't affect how pages are ranked." Losing a rich result changes how a listing looks, not where it sits.

What happened to FAQ rich results

FAQ went in two steps. On August 8, 2023, Google limited FAQ rich results to "well-known, authoritative government and health websites." For everyone else the accordion under the blue link disappeared that week. That restriction no longer matters: on May 8, 2026 Google added a deprecation notice saying the feature "will no longer appear in Google Search starting May 7, 2026," and on June 15, 2026 it removed the documentation entirely. Government and health sites lost it too.

You don't have to strip FAQPage markup out of your templates. Google's 2023 post said "there's no need to proactively remove it" because "structured data that's not being used does not cause problems for Search." The sitelinks search box post made the same point about unsupported markup: it "won't cause issues in Search, and won't trigger errors in Search Console reports." Remove it when you next touch the template, to keep your HTML lean. Don't schedule a sprint for it.

The visible FAQ section on the page is a separate question. It can still answer a reader's follow-up, and it still gives Google plain text to work with. Keep the content; just stop expecting a rich result from the markup.

Minimal JSON-LD for the types most sites need

Google recommends JSON-LD "if your site's setup allows it," per its intro to structured data. Each example below is the smallest block that meets the required properties on the linked Google page. Swap in your own values, and make sure the markup describes content a visitor can actually see on the page.

Article or BlogPosting

The Article docs say: "There are no required properties; instead, add the properties that apply to your content." These five are the ones most templates can fill reliably.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Replace a Bike Chain",
  "image": ["https://example.com/photos/chain-1x1.jpg"],
  "datePublished": "2026-11-10T08:00:00-05:00",
  "dateModified": "2026-11-10T08:00:00-05:00",
  "author": [{ "@type": "Organization", "name": "Example Cycles", "url": "https://example.com/about" }]
}

BreadcrumbList

The only required property is itemListElement, an ordered list of ListItem entries, per the breadcrumb docs. Expect it on desktop results only.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Guides", "item": "https://example.com/guides" },
    { "@type": "ListItem", "position": 2, "name": "Repairs", "item": "https://example.com/guides/repairs" }
  ]
}

Product (product snippet)

Product snippets need a name plus at least one of review, aggregateRating or offers, per the product snippet docs. Stores that want merchant listing features should follow the stricter merchant listing requirements instead.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Pro Bike Chain, 12-speed",
  "image": "https://example.com/photos/trail-pro-chain.jpg",
  "offers": {
    "@type": "Offer",
    "price": 39.99,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Organization

No required properties here either, per the Organization docs. Put it on your home page or About page.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Cycles",
  "url": "https://example.com",
  "logo": "https://example.com/logo-512.png",
  "sameAs": ["https://www.linkedin.com/company/example-cycles"]
}

SoftwareApplication

Required: name, offers.price (use 0 for a free app) and either aggregateRating or review, per the software app docs. The rating has to come from real reviews shown on the page.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Example Route Planner",
  "operatingSystem": "Android",
  "applicationCategory": "TravelApplication",
  "offers": { "@type": "Offer", "price": 0 },
  "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.6, "ratingCount": 812 }
}

Wrap any of these in <script type="application/ld+json">. Our free schema markup generator builds Article, Product, Organization, BreadcrumbList, LocalBusiness, Event, Recipe and VideoObject blocks with a form and a one-click Rich Results Test link. It also still offers FAQPage and HowTo, which are valid schema.org but no longer produce Google rich results.

How to test without chasing dead features

Each tool answers a different question, so use them in this order.

Rich Results Test tells you which Google rich result types a URL or code snippet is eligible for. Google removes retired types from it: when Course info, ClaimReview and four others went, Google said they "will be removed from Search Console rich result reporting, the Rich Result Test, and the list of Search appearance filters." A retired type simply stops appearing in the test.
Schema Markup Validator checks "syntax and compliance of markup with schema.org standards," in Google's description. It does not check Google rich result types. Use it for types Google doesn't consume, or to catch a misspelled property.
Search Console rich result reports show errors and warnings for indexed pages, grouped by type. Google's docs suggest deploying a few pages first, checking them with the URL Inspection tool, then watching the relevant rich result status report after indexing.
Search Console Performance report, filtered by search appearance, is where you see whether a rich result actually earned impressions.

Then check the rest of the listing. Your title and meta description still do most of the work in a plain result, so preview them with the meta tags previewer. Our developer guide to meta tags covers the tags that matter next to your JSON-LD.

Eligible is not the same as shown

Google's structured data policies say it directly: "Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test." A clean test result means you passed the entry check. Whether the rich result appears for a given query depends on Google. Treat markup as a prerequisite and measure what happens in Search Console instead of assuming it.

The same page lists common reasons markup gets ignored, including "The content referred to by the structured data is hidden from the user" and markup that "is not representative of the main content of the page." Reviews have their own trap. Self-serving reviews are spelled out in the review snippet docs: LocalBusiness and Organization reviews only count from sites that review other businesses.

Frequently Asked Questions

Do FAQ rich results still work in 2026?

No. Google stopped showing FAQ rich results on May 7, 2026 and removed the documentation on June 15, 2026. The 2023 exception for government and health sites ended with it.

Will leftover FAQPage or HowTo markup hurt my rankings?

No. Google has said unused structured data does not cause problems for Search, and its HowTo, sitelinks search box and June 2025 retirement posts all say the change does not affect ranking. You can remove it whenever it suits you.

Which rich result types should a typical business site use?

Organization on the home page, BreadcrumbList on deep pages, Article or BlogPosting on posts, and Product, LocalBusiness, Event or SoftwareApplication where the page really is one of those things.

Is JSON-LD better than Microdata for Google?

Google says all three formats are equally fine when valid, but recommends JSON-LD because it is easiest to implement and maintain at scale.

Why doesn't my valid markup show a rich result?

Valid markup only makes a page eligible. Google does not guarantee display, and it skips markup that breaks its policies, such as markup describing hidden content or self-serving reviews.

Do breadcrumbs still appear on mobile?

No. Since January 23, 2025, Google shows breadcrumbs in the visible URL on desktop only. Mobile results show the domain. Breadcrumb markup is still supported.

Originally published at wowhow.cloud

Docker Run to Compose: Flag Conversion Guide (2026)

Anup Karanjkar — Wed, 11 Nov 2026 04:19:06 +0000

There is no 1:1 mapping from docker run flags to Compose service keys. Some flags map cleanly (-p → ports, -e → environment). Some map to a key that looks right but behaves differently (--restart is not deploy.restart_policy). And some have no Compose equivalent at all because the behavior belongs to the CLI invocation, not the service definition (--rm, -d, -it). This guide maps 31 flags a typical docker run command might use, cites Docker's own CLI reference and the Compose Specification for every claim, and runs real commands through our free Docker Run to Compose converter to show what it actually outputs today — including three parsing bugs we found while writing this.

Use the method below if you want to convert by hand, use the converter for anything with the flags it supports, and read the "what the converter gets wrong" section before you trust its output on a command with --rm, -it, or --privileged sitting right before the image name.

How to convert a docker run command to Compose

Split the command into one flag (or flag pair) at a time — do not try to convert the whole line in your head.
Look up each flag in the reference table below to find its Compose service key, or confirm it has none.
For anything with no listed key (--rm, -d, -it, --pull), decide whether the behavior belongs in docker compose run/up flags instead of the YAML.
Paste the result into the converter to catch formatting mistakes, then diff it against your hand conversion with the diff checker if the two disagree.

The full flag-to-Compose-key reference

Compose key names and defaults below are quoted from the Compose Specification services reference unless noted otherwise.[2] CLI flag defaults are from the docker container run reference.[1]

docker run flag	Compose key	Notes

| -p, --publish | ports | Short form [HOST:]CONTAINER[/PROTOCOL]. No host IP means it binds 0.0.0.0 — reachable from outside, in both the flag and the key. |

| -v, --volume | volumes (short form) | Same syntax both places. A missing host directory is created automatically by both the CLI and Compose's short/long bind syntax. |

| --mount | volumes (long form, type: bind) | Different defaults — see "Short volumes vs. --mount" below. |

| -e, --env | environment | Map or array form. -e NAME with no = copies the value from your shell at runtime — Compose resolves it the same way, and unsets it if the variable isn't exported. |

| --env-file | env_file | Compose processes multiple files top-down (last one wins) and defaults required: true — a missing file is an error unless you set required: false. |

| --name | container_name | Must match [a-zA-Z0-9][a-zA-Z0-9_.-]+. Setting it stops Compose from scaling that service past one container. |

| --restart | restart | Same four values as the CLI (no, always, on-failure[:max-retries], unless-stopped). Not the same key as deploy.restart_policy — see below. |

| --network, --net | networks | A service with no networks: joins the implicit default network instead of none. |

| --network-alias | networks.<name>.aliases | Nested under the network entry, not a top-level key. |

| -w, --workdir | working_dir | Creates the directory inside the container if the image doesn't already have it. |

| --entrypoint | entrypoint | A non-null value here makes Compose ignore the image's default CMD, same as the CLI flag ignores it. |

| trailing command/args | command | Overrides image CMD. Unlike a Dockerfile's CMD, Compose does not run it through the image's SHELL automatically. |

| --cap-add / --cap-drop | cap_add / cap_drop | Lists of capability strings, same names both places. |

| --device | devices | HOST_PATH:CONTAINER_PATH[:CGROUP_PERMISSIONS] in both. Under --privileged/privileged: true, only the specified cgroup permissions are ignored — the device mapping itself still applies, and the container gets every other host device too. |

| --init | init | Boolean in Compose (init: true) vs. a bare flag on the CLI. |

| --read-only | read_only | Boolean in Compose (read_only: true) vs. a bare flag on the CLI. |

| --tmpfs | tmpfs | A path, or a list of paths/path:options. Compose's options are mode, uid, gid. |

| --health-cmd / --health-interval / --health-timeout / --health-retries / --health-start-period | healthcheck.test / .interval / .timeout / .retries / .start_period | Compose's docs say it "has the same default values" as a Dockerfile HEALTHCHECK, without restating the numbers. The CLI defaults it does list: --health-interval, --health-timeout and --health-start-period all default to 0s. |

| --memory, -m / --cpus | deploy.resources.limits.memory / .cpus | The Compose Specification defines this key with no Swarm-only wording — what that does and doesn't prove is below.[3] A flatter mem_limit: / top-level cpus: pair is also valid and must stay consistent with the deploy values if both are present. |

| -l, --label | labels | Map or array of key=value. The com.docker.compose prefix is reserved — using it in your own label is a Compose error. |

| -h, --hostname | hostname | Must be a valid RFC 1123 hostname in both. |

| --add-host | extra_hosts | HOSTNAME=IP short form (also accepts : since Compose 2.24.1). host-gateway resolves to the host's internal IP either way.[1] |

| --privileged | privileged | Boolean in Compose. Docker's own wording: "extended privileges," disables the default seccomp/AppArmor profile — the CLI docs warn "a container with --privileged is not a securely sandboxed process." |

| --shm-size | shm_size | Byte-value string, same format. |

| --ulimit | ulimits | CLI format is type=soft[:hard]; Compose takes an integer (single limit) or a {soft, hard} map per ulimit type. |

| --log-driver / --log-opt | logging.driver / logging.options | Defaults are platform-specific on both sides — neither doc lists a universal default driver. |

| -i/--interactive, -t/--tty (-it) | stdin_open, tty | Two separate booleans — the Compose docs say stdin_open is "the same as running a container with the -i flag" and tty is "the same as running a container with the -t or --tty flag." No combined -it-style shorthand key. |

| --rm | none | No service key. See below. |

| -d, --detach | none (CLI flag on up/run) | Not a service key. docker compose up -d has the flag; the YAML itself has nothing to set. |

| --platform | platform | os[/arch[/variant]], e.g. linux/arm64/v8. CLI flag needs daemon API 1.32+. |

| --pull | pull_policy | CLI only has always/missing/never (default missing). Compose's pull_policy adds build, daily, weekly, every_<duration>, and if_not_present as an alias for missing. |

No Compose key: --rm, -d, -it

Three of the most common flags in any docker run line have nothing to write in the YAML, because they describe how you want to run the container right now, not how the service is defined.

--rm has no service key because docker compose up doesn't have a --rm flag at all — it isn't in the command's options table.[6] When the up command exits, Docker's docs say only that "all containers are stopped," not removed.[6] docker compose run does have --rm, documented as "Automatically remove the container when it exits," but it's opt-in — every example in the docs adds it explicitly, the same as plain docker run.[7] If you relied on --rm to keep a host clean of one-off containers, that's a habit to carry into whichever Compose subcommand you actually use, not a line to add to compose.yaml.

-d/--detach is the same shape of answer: it's a flag on docker compose up (and run), not a service key.[6] docker compose up -d gets you the same background-and-print-ID behavior you'd get from docker run -d.

-it (short for -i -t) is the one case where the CLI flag does have Compose keys — stdin_open: true and tty: true — but they only matter if you're running docker compose run or attaching interactively; they're inert for a background docker compose up service that nothing ever attaches to.

Short volume syntax vs. --mount: who creates the directory

Here's a divergence that bites people the other direction from what they expect. Docker's bind-mount docs are explicit: -v/--volume "automatically creates the directory on the host for you" if it's missing, while "--mount does not automatically create a directory if the specified mount path does not exist on the host" — you get an error instead, unless you add the separate bind-create-src option.[8]

You'd expect Compose's long type: bind syntax, which maps to --mount, to inherit that fail-on-missing-path default. It doesn't. The Compose Specification sets bind.create_host_path to default to true: "Creates a directory at the source path on host if there is nothing present."[2] So a typo'd host path under Compose's short or long volume syntax silently becomes an empty directory instead of an error — the opposite of what the raw --mount flag it's modeled on would do. If you want the CLI's fail-closed behavior inside Compose, set create_host_path: false explicitly on the long form.

--restart is not deploy.restart_policy

The plain restart: key takes the same four values as docker run --restart — no, always, on-failure[:max-retries], unless-stopped — and the Compose docs point straight at the docker run --restart reference for what they mean.[2] That's the key our converter uses, and it's the right one for a direct flag conversion.

deploy.restart_policy is a different, Swarm-service-shaped schema entirely: condition (none/on-failure/any, defaulting to any), delay (default 0), max_attempts (default unlimited) and window, the evaluation period before Swarm decides a restart succeeded.[3] If you're copying a block from a Swarm stack file into a non-Swarm compose.yaml and expect it to behave like --restart, don't — it's a different four fields with no window or condition equivalent on the plain restart: key, and the Compose docs themselves note that when deploy.restart_policy isn't set, Compose falls back to the service's restart field.[3]

--memory and --cpus: what deploy.resources.limits actually traces back to

The common advice online is that the entire deploy: section — including resources.limits — is a Swarm-only artifact that plain docker compose up silently ignores unless you pass --compatibility. That advice has one real citation behind it, and it's more than eight years old: a GitHub thread opened February 17, 2018, about the original Python docker-compose v1, not the Go-based Compose v2 plugin you almost certainly have installed now (the one invoked as docker compose, no hyphen).

Here's exactly what that thread shows, because it gets misquoted a lot: a Docker maintainer, in a July 31, 2018 comment, ran docker-compose --compatibility up -d — the legacy v1 binary, with the compatibility flag explicitly set — against a file with resources.limits.cpus: '0.50' and a 50M memory limit. docker inspect on the resulting container reported "Memory": 52428800 and "NanoCpus": 500000000, matching the YAML.[9] That proves the translation mechanism existed in 2018 — for v1, with the flag set. It says nothing about v2 with no flag. The same maintainer's own framing in that thread is that deploy options are "scheduling options for swarm-mode services," and Compose "deploys local containers," so there's no orchestrator to apply them to on its own.[9] An October 3, 2023 reply in the same thread adds only that v2 "now uses the compose-specification file format which does not use a version" — it doesn't say whether resources.limits applies without Swarm or without --compatibility today.[9]

What we can confirm from Docker's current docs: the Compose Specification defines resources.limits as a plain key with no Swarm-only or version-gating language anywhere on the page — a real difference from the versioned v3 schema that 2018 thread was arguing about.[3] The docker compose up command reference has no --compatibility flag at all; it isn't in the options table.[6] What we could not confirm anywhere on docs.docker.com is whether a plain docker compose up, no flags, actually enforces resources.limits on a single engine today. Don't take our converter's deploy.resources.limits output on faith: run docker compose up -d on your own file and check docker inspect <container> for Memory/NanoCpus against the YAML before you rely on it in production.

Worked example: a Node API, by hand

Here's a realistic docker run line and its hand-written Compose equivalent, using the mappings above:

docker run -d --name api \
  -p 3000:3000 \
  -v ./logs:/app/logs \
  -v appdata:/data \
  -e NODE_ENV=production \
  -e DATABASE_URL=postgres://admin:secret@db:5432/myapp \
  --network app-net \
  --restart unless-stopped \
  --memory 512m --cpus 0.5 \
  node:20-alpine node server.js

services:
  api:
    image: node:20-alpine
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - ./logs:/app/logs
      - appdata:/data
    environment:
      NODE_ENV: production
      DATABASE_URL: "postgres://admin:secret@db:5432/myapp"
    networks:
      - app-net
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: "0.5"
    command: node server.js

volumes:
  appdata:

networks:
  app-net:

-d doesn't appear anywhere in the YAML — you'd run this with docker compose up -d instead, as covered above.

We ran that exact command through our own converter

Rather than hand-wave that our Docker Run to Compose converter "handles this," we ran it. The tool runs entirely in the browser, so we extracted its parsing logic unmodified and ran it against the command above, pasted as a single line. Here is the actual output, byte for byte:

services:
  api:
    image: node:20-alpine
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - ./logs:/app/logs
      - appdata:/data
    environment:
      NODE_ENV: production
      DATABASE_URL: "postgres://admin:secret@db:5432/myapp"
    networks:
      - app-net
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: "0.5"
    command: node server.js

volumes:
  appdata:

networks:
  app-net:

That matches the hand conversion exactly, as long as the command lands in the textarea as one line. For the flags it supports — -p, -v, -e, --name, --restart, --network, --memory, --cpus, and a trailing command — the converter is reliable on single-line input. (-d is also recognized, but produces no YAML either way, same as covered above — it's a CLI flag, not a service key.) "As long as it's one line" turns out to matter a lot, which is the first bug below.

Three bugs we found while testing it

Bug 1: its own placeholder example breaks the tool

The converter's input box ships with this exact placeholder text, shown in gray before you type anything:

docker run -d --name nginx \
  -p 80:80 -p 443:443 \
  -v /data/nginx:/etc/nginx \
  --restart always \
  nginx:alpine

Paste that in verbatim — line breaks and trailing backslashes included, exactly as it's formatted in the placeholder — and the actual output is four parse errors plus one "parsed" service that isn't nginx at all:

Could not parse: "  -p 80:80 -p 443:443 \..."
Could not parse: "  -v /data/nginx:/etc/nginx \..."
Could not parse: "  --restart always \..."
Could not parse: "  nginx:alpine..."

The one "parsed" service that results has image: \ — a lone backslash as the image name, with no quotes around it (the converter's YAML writer never quotes image). The root cause: the component splits the textarea's contents into lines on every \n before handing each line to the parser, and treats every line as an independent docker run invocation. The parser itself does have code to collapse a trailing \ plus newline into a space — but by the time a line reaches that code, the newlines are already gone, so that collapse logic never has anything to do. A multi-line, backslash-continued command, which is how Docker's own docs and most READMEs format anything with more than two or three flags, has to be joined into one line before you paste it in. The box's own example doesn't follow that rule.

Bug 2: --rm immediately before the image fails outright

Everything outside the supported flag set goes through a generic "skip this flag, and skip the next token too if it doesn't look like another flag" fallback. That fallback assumes every unrecognized flag takes exactly one value. Boolean flags that take no value break it, and two of the most common ones are --rm and -it.

Feed the converter docker run --rm nginx:alpine on its own and it fails outright:

Could not parse: "docker run --rm nginx:alpine..."

What happens: the parser sees --rm, doesn't recognize it, advances past it, and then — because the next token (nginx:alpine) doesn't start with a dash — treats the image name as --rm's value and skips it too. There's nothing left to become the image, so the whole line errors.

Bug 3: -it before the image silently produces the wrong service

This one is worse than Bug 2, because it doesn't error — it silently produces the wrong service. The cause is -it alone. Feed the converter docker run -it ubuntu:24.04 bash and the real output is:

services:
  app:
    image: bash

-it is an unrecognized flag, so the generic fallback skips it, then checks whether the next token looks like another flag. ubuntu:24.04 doesn't, so the fallback swallows it as -it's "value" too, discarding the real image entirely. The next bare token, bash — which was supposed to be the command — gets assigned as the image instead, because it's the first non-flag token the parser ever reaches. The output has no error, looks plausible, and is completely wrong. Putting --rm in front of it, as in docker run --rm -it ubuntu:24.04 bash, doesn't change the outcome: -it starts with a dash, so --rm's own fallback skips only itself, leaving -it to eat ubuntu:24.04 exactly as before. We confirmed a different failure mode with --privileged and --init placed directly before an image with no trailing command: both make the converter report "Could not parse" for the same reason --rm alone does in Bug 2 — there's no bare token left over to become the image.

The practical rule until this is fixed: never put a zero-argument flag — --rm, -it, --privileged, --init, --read-only, or any other flag that takes no value — directly before the image. Put it anywhere else in the flag list, then check the image name in the tool's "Parsed N services" summary before you trust the YAML.

Flags the converter silently drops today

Everything in the reference table that isn't -d, -p, -v, -e, --name, --restart, --network/--net, --memory/-m, or --cpus gets silently discarded — no error, no warning, just absent from the output. We confirmed this by running a command with sixteen of them at once, pasted as a single line (multi-line input here hits the same parsing failure as Bug 1 above):

docker run --user 1000:1000 -w /app --entrypoint /bin/sh --cap-add SYS_PTRACE --device /dev/snd:/dev/snd --health-cmd "curl -f http://localhost/ || exit 1" --health-interval 30s --health-retries 3 --label com.example.app=web --hostname web1 --add-host db.local:10.0.0.5 --platform linux/amd64 --pull always --mount type=bind,source=/data,target=/data --env-file ./app.env --network-alias web myorg/app:1.2.3

Actual output:

services:
  app:
    image: myorg/app:1.2.3

Every one of those sixteen flags — --user, -w, --entrypoint, --cap-add, --device, all three health flags we passed, --label, --hostname, --add-host, --platform, --pull, --mount, --env-file, and --network-alias — vanished. None of these happened to collide with the image-eating bug above (each one here is immediately followed by its own value, not by the image), so you get a clean, valid, silently-incomplete compose.yaml rather than an error or a wrong image. Add the keys for these by hand from the reference table above — they're the right Compose keys, the tool just doesn't write them yet.

Converting .env files along the way

If your docker run command used --env-file app.env, the Compose key is env_file: [app.env] — a one-line swap, since Compose reads the same VAR=value format. Where it gets messier is when a long -e/--env list should become an env_file instead for readability, or vice versa. Our free .env file converter handles reshaping between .env, JSON, and shell-export formats if you're restructuring environment variables as part of the migration rather than just converting flag syntax.

FAQ

Does docker compose up remove containers the way docker run --rm does?

No. docker compose up has no --rm flag — Docker's own reference for the command confirms it isn't in the options table — and stopping the command only stops containers, it doesn't remove them.[6] docker compose run has --rm, but like plain docker run, it's opt-in, not default.[7]

Why did my converted compose.yaml create an empty folder instead of erroring?

Because both Compose's short and long bind-mount syntax default to creating a missing host directory (bind.create_host_path: true), the same way -v does on the CLI.[2] If you want a typo to fail loudly instead, add create_host_path: false to the long volume form.

Will deploy.resources.limits actually limit my container without Swarm?

We couldn't confirm that from Docker's own docs either way. The Compose Specification defines resources.limits with no Swarm-only language,[3] but the only runtime demonstration we found is more than eight years old and used the legacy v1 CLI with --compatibility explicitly set — not today's v2 plugin with no flag.[9] Check it yourself: run docker compose up -d and compare docker inspect's Memory/NanoCpus fields against your YAML.

Can I just copy my --restart value into deploy.restart_policy?

No — they're different schemas. restart: takes the same four values as the CLI flag. deploy.restart_policy uses condition/delay/max_attempts/window, a Swarm-service shape with no 1:1 mapping back to the simple flag.[3]

What should I do with flags the converter drops?

Add them by hand using the Compose key from the reference table above. None of the dropped flags in our test run broke the output — they're just missing from it, so the fix is additive, not corrective.

Once you have a complete compose.yaml, the next step is making it production-ready — health check ordering, secrets, and resource limits that actually hold under load are covered in our Docker Compose for production guide. Paste your own command into the Docker Run to Compose converter, then check anything with a zero-argument flag before the image against the "Parsed N services" summary it shows you.

Sources

9. docker/compose pull request #5684, maintainer comment thread, GitHub (accessed November 5, 2026)

Originally published at wowhow.cloud

Claude Code in Visual Studio 2026: 5 Ways to Run It Today

Anup Karanjkar — Tue, 03 Nov 2026 14:23:56 +0000

As of November 2, 2026, Anthropic does not ship a Claude Code extension for Visual Studio 2026. The official docs cover VS Code, Cursor and JetBrains IDEs, and tell users of other editors to run the claude CLI in their editor's integrated terminal.[1][12] The GitHub feature request for a native Visual Studio 2026 extension, issue #15942, has been open since January 1, 2026 and had 480 thumbs-up reactions when we read it. None of the comments GitHub displays without expanding the thread comes from Anthropic staff.[2] That leaves five ways to run it today: the CLI in Visual Studio's terminal with a plain-text workflow, or one of four community extensions linked in that thread. Two of them, firish's and cv4vs Agents, connect the CLI to Visual Studio over the same IDE channel the official VS Code extension uses; dliedke's and nachum-shmilovitz-66's drive the CLI their own way.[3][11] This post compares all five, shows the setup commands, and shows which files the firish extension writes into your repo (and how to check the others), which most install guides skip.

How we researched this: the WOWHOW editorial team compared these extensions from their Visual Studio Marketplace listings, their READMEs and the Anthropic and Microsoft docs on November 2, 2026. We did not install them on a Visual Studio 2026 build, so every feature claim below is what the project documents, not what we measured.

TL;DR

No official Visual Studio 2026 extension exists. Anthropic's plugins cover VS Code, Cursor and other VS Code forks, and JetBrains IDEs; Visual Studio gets the CLI-in-a-terminal route.
Claude Code for Visual Studio (firish, v1.21.0, about 10,600 installs) is the closest thing to the VS Code experience: native diffs, Error List diagnostics, Roslyn lookups and a debugger Claude can read. VS 2026 only.
Claude Code Extension for Visual Studio (dliedke, v298.0, about 345,000 installs) is the most installed. It supports VS 2022 and 2026 and nine other agents besides Claude Code.
claude-code-visualstudio (nachum-shmilovitz-66) is the only one that reaches back to VS 2017.
cv4vs Agents (Corsinvest, v1.15.0, 415 installs) is the newest entrant: VS 2022 and 2026, native diffs, debugger tools, GPL-3.0 license.
All four are unofficial, need the Claude Code CLI plus a paid Claude plan or another supported provider, and two ride an undocumented protocol that a CLI update can break.

Why there is no official Visual Studio extension yet

Claude Code's IDE support is built around a small local protocol. The editor extension runs an MCP server named ide bound to 127.0.0.1 on a random port between 10000 and 65535, speaks unencrypted ws://, and writes a fresh auth token to a lock file at ~/.claude/ide/<port>.lock. The CLI reads that file and sends the token in an X-Claude-Code-Ide-Authorization header.[1] That is how diff viewing and diagnostic sharing reach the terminal agent.

Anthropic implements the editor side of that protocol for VS Code and for JetBrains IDEs, and the VS Code extension also installs in forks such as Cursor, Kiro and Devin Desktop. The JetBrains plugin runs the same ide MCP server with the same lock file and X-Claude-Code-Ide-Authorization header.[12] Visual Studio is a different product with a different extension model (VSIX on .NET, not a VS Code extension), so none of that code carries over. The docs never name Visual Studio. The phrase "Visual Studio Marketplace" appears only because that is where Anthropic publishes the VS Code extension.[1]

The demand is clear. The issue author writes that they rely on "Visual Studio 2026 for C++ and Win32 system-level development (e.g., global hooks, drivers)" and asks for a native VSIX "that provides feature parity with the existing VS Code extension": a chat panel, native diffs, context from open files, selections and build errors, and /ide support.[2] The issue carries the labels area:ide, enhancement and platform:windows. Most of the thread is developers linking their own workarounds. That is where the four extensions below came from.

The catch for anyone planning around this: an open issue with 480 reactions is not a roadmap. Pick a workaround on its merits, not on the hope that an official build lands next month.

Step zero: install the CLI on Windows

Every option here, including all four extensions, drives the real claude binary. None of them makes model calls itself. Install the CLI first. From PowerShell, using the native installer in Anthropic's setup docs:[7]

# PowerShell (prompt shows PS C:\). No admin rights needed.
irm https://claude.ai/install.ps1 | iex

# Open a NEW terminal, then confirm the install
claude --version
claude doctor

claude doctor prints read-only install and settings diagnostics without starting a session. If you prefer a package manager, winget install Anthropic.ClaudeCode works too. WinGet installs do not auto-update, though, so you need winget upgrade Anthropic.ClaudeCode on a schedule unless you set CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1 in settings.json env, which makes Claude Code run the upgrade for you (it can fail while claude.exe is running). The native installer, by contrast, updates itself in the background.[7]

Two Windows details matter for Visual Studio users. First, Git for Windows is optional: with it, Claude Code uses Git Bash for its Bash tool; without it, it runs commands through PowerShell. If Claude Code cannot find Git Bash, point it there in settings.json:

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

Second, sandboxing is not supported on native Windows. Only WSL 2 supports it.[7] Most Visual Studio solutions (MSBuild, .NET Framework, Win32, drivers) need the native Windows toolchain, so you will usually run without the sandbox. That makes the permission prompts your main safety net, and it is the strongest argument for an extension that routes every edit through a diff you approve.

Last prerequisite: a paid plan. Claude Code needs a Pro, Max, Ultra, Team, Enterprise or Console account. The free claude.ai plan does not include it.[7] Paste the JSON above into the JSON formatter before saving if you are editing settings by hand. A stray backslash in a Windows path is the most common reason the file fails to load.

Option 1: the built-in terminal, no extension

This is the route Anthropic documents for editors without a plugin.[1] Open Visual Studio's terminal window (View > Terminal), cd to the folder that holds your .sln, and run claude. The agent reads and edits files on disk, runs dotnet build or msbuild, and Visual Studio picks up the changed files.

What you lose is everything the IDE protocol carries. No native diff for approving edits, no Error List feed, no selection context. You approve edits as text diffs in the terminal, and you paste build errors in by hand. For small, well-tested repos that is fine. In a large solution, where one wrong edit to a shared header triggers a long rebuild, the missing diff view hurts.

A short CLAUDE.md at the solution root closes part of the gap, because it tells the agent how to build and test without you repeating it each session:

# CLAUDE.md (solution root)
## Build
- Build: dotnet build MyApp.sln -c Debug
- Test:  dotnet test MyApp.sln --no-build
- Never edit files under obj/ or bin/.

## Conventions
- Target framework: net10.0. Do not retarget projects.
- Treat compiler warnings in src/Core as errors; fix them, do not suppress.

Swap in your own solution name and commands. If you keep a set of rules files you reuse across repos, the Production CLAUDE.md and AGENTS.md Rule Pack is a starting point.

firish, dliedke and nachum-shmilovitz-66 compared

Issue #15942 links four community extensions.[2] The table covers three of them: the two with the most Visual Studio Marketplace installs (dliedke and firish) and the only one that supports VS 2017 and 2019 (nachum-shmilovitz-66, which ships its VSIX files through GitHub Releases rather than the Marketplace). The fourth, cv4vs Agents, gets its own section after them. All four are free, unofficial, and not affiliated with Anthropic. The figures below come from each project's Marketplace listing or README on November 2, 2026.

	Claude Code for Visual Studio (firish)	Claude Code Extension for Visual Studio (dliedke)	claude-code-visualstudio (nachum-shmilovitz-66)

| How it talks to Claude Code | Implements the IDE protocol: WebSocket + lock file + MCP | Native chat tab (default) or embedded agent terminal | WebView2 chat; drives claude via stream-json over stdin/stdout |

| Edit review | Visual Studio's native diff, accept or reject | Tab showing uncommitted Git changes; opt-in per-file Keep/Undo of agent changes (no per-edit accept/reject listed) | Inline diff in chat plus an "Open diff" button for the native VS window |

| Debugger access | Reads call stacks, variables and threads; can step and set breakpoints with an opt-in toggle (managed .NET) | Sends unhandled exceptions with their stack trace while debugging (opt-in); F5, Ctrl+F5 and Shift+F5 forwarded from the embedded terminal. No variable or breakpoint access listed | Reads call stack, locals and exception when paused (verified on C#/.NET) |

| License | MIT | MIT per listing, plus a no-derivative-extensions clause | MIT |

Sources for the table: the firish README and listing,[3][4] the dliedke listing,[5] and the nachum-shmilovitz-66 README.[6]

firish: the closest to the VS Code experience

This one rebuilds the editor half of Anthropic's protocol inside Visual Studio. On launch it starts a localhost WebSocket server, writes the lock file to ~/.claude/ide/<port>.lock, and launches claude with ENABLE_IDE_INTEGRATION and the bridge port, so the CLI connects and speaks MCP over the socket.[3] Then it adds two more MCP servers: vs-debug for the debugger, tests and builds, and vs-semantic, a read-only server backed by the live Roslyn workspace for find-references, go-to-definition, call hierarchies and decompile.

For .NET work, the debugger access stands out. While you are paused at a breakpoint, Claude can read the call stack, locals and threads, and with an opt-in toggle it can step and set breakpoints itself. Test Explorer integration lets it re-run only failing tests.[3]

The README is honest about the limits. The protocol is "undocumented and version-fragile, so a claude update could change it." It was tested against claude 2.1.223, which is older than current CLI releases, so check the extension's release notes before updating the CLI. Debugger features target managed .NET code, so native C++ runtime inspection is not covered, even though C++ compiler diagnostics are. Diagnostics need a loaded project, and ARM64 Windows support is labeled experimental.[3] If you are the Win32 and drivers developer who opened issue #15942, that debugger gap is the one that matters.

dliedke: the most installed, and not only for Claude

With about 345,000 installs at version 298.0, this is the extension most Visual Studio users actually have.[5] New installs default to "Native mode", a chat in its own document tab. You can switch to an embedded terminal that runs the agent inside a Visual Studio tool window, which is also the fallback for agents that cannot run in native mode. Claude Code is the only agent shown in the picker by default. The others, Codex and Grok among them, are opt-in.

It does more Visual Studio-specific chores than the others: TFVC checkout, a git pull before the first prompt, opt-in sending of build errors, a commit-message generator, and a GitHub Issues window that fixes issues on separate branches. It also covers VS 2022, which firish does not. The trade-off is depth. Its debugger hooks are thin: while you debug, it can send unhandled exceptions with their stack trace to the agent (opt-in, under Settings > Automation), and since version 9.0 it forwards F5, Ctrl+F5 and Shift+F5 from the embedded terminal to Visual Studio's debug commands.[5] The listing does not mention reading locals, setting breakpoints or Roslyn lookups, so outside those exception reports Claude sees your code the way the CLI does, not the way Visual Studio does.

nachum-shmilovitz-66: for teams stuck on older Visual Studio

If your solution still builds only in Visual Studio 2017 or 2019, this is the only option of the four. It ships a separate VSIX per Visual Studio family and runs the claude CLI as a long-lived process, exchanging stream-json over stdin and stdout. Because it drives the real CLI, it inherits your login, CLAUDE.md, MCP servers and settings. It offers four permission modes (Ask before edits, Edit automatically, Plan mode and Auto mode), and in Ask before edits every tool call raises an allow or deny card.[6] With 9 stars it is also the least battle-tested. Read the source before you deploy it to a team.

cv4vs Agents (Corsinvest): the fourth extension in the thread

Its author posted it to issue #15942 on August 5, 2026 as "VS 2022 and 2026, GPL-3.0".[2] The Marketplace listing, published by Corsinvest Srl, shows version 1.15.0, 415 installs and a free price tag. That is far behind firish's 10,600 and dliedke's 345,000.[11] The listing says the real claude.exe runs in an embedded terminal "connected to the IDE over the same channel the official VS Code extension uses", and the author's issue comment lists /ide support.[11][2] The README says the extension "drives the real claude.exe" instead of forking the CLI, through a WebView2 chat pane and a ConPTY terminal pane. Visual Studio reaches the agent as 80 MCP tools covering navigation, references, rename, diagnostics, build, Test Explorer and the live debugger. Every edit shows as an inline diff and opens in Visual Studio's native side-by-side diff.[10]

On VS 2022 it fills the gap firish leaves. Its listing names breakpoints, tracepoints, stepping, locals and the call stack, which neither dliedke's listing nor the nachum-shmilovitz-66 README mentions for breakpoints or stepping.[11] The listing says its diagnostics keep working in C++, F# and TypeScript, but it does not say which runtimes the debugger supports. Two cautions. The license is GPL-3.0-only, not MIT, so check it against your company's tooling policy first. And the README does not say which files the extension writes into your workspace, so run the git status check below after the first launch.[10]

What these extensions write into your repo

Here is the part that bites teams later. The firish extension installs a PreToolUse hook into your workspace's .claude/settings.json to route edits to the Visual Studio diff, and registers its debugger shim in the workspace .mcp.json.[3] Both files usually live in version control, and the extension also writes PowerShell helper scripts (.ps1 files) into .claude/. Commit them unreviewed and every teammate's Claude Code session picks up a hook and an MCP server that points at an extension they may not have installed.

Check what changed right after the first launch:

# From the solution root, after launching the extension once
git status --short .claude/ .mcp.json
git diff -- .claude/settings.json .mcp.json

Then decide on purpose. Either commit the entries and make the extension a team requirement, or keep them out of your commits. Per the README, the extension writes its helper scripts (including the vs-mcp-shim.ps1 registered in .mcp.json) into your workspace's .claude/ folder and merges its hook into .claude/settings.json on every launch and connect. It overwrites the scripts unless you delete their vs:auto-managed marker line.[3] So the git status check above will list the .ps1 files too, and they come back after every launch. The diff checker helps when you are comparing a teammate's settings file against yours.

The README also flags a trust change. Since CLI 2.1.222, project hooks are tied to workspace trust, so after an update the hook can stop firing until you trust the folder again. The README's fix for a related issue is to remove duplicate project entries in ~/.claude.json that differ only by path casing.[3] Windows paths are case-insensitive, but that JSON file treats C:\Repos\App and c:\repos\app as two projects.

On the network side, the firish bridge binds to 127.0.0.1 only, checks the lock-file token on every connection, never logs the token, and makes no network or LLM calls of its own.[3] That matches the protection model in Anthropic's own docs, where the lock file sits at 0600 permissions inside a 0700 directory.[1] To see which bridges are live on your machine:

# PowerShell: list active IDE lock files (one per running bridge)
Get-ChildItem "$env:USERPROFILE\.claude\ide" -Filter *.lock

If the firish panel says "Waiting for CLI", its troubleshooting section says to click Launch Claude Code, or to run /ide in a claude terminal and pick Visual Studio.[3]

GitHub Copilot's Claude support is a different product

This causes a lot of confusion. VS Code can run Claude as a third-party agent harness inside Copilot Chat, controlled by the chat.agentHost.claudeAgent.enabled setting and billed either through a Copilot subscription or your own API key.[9] That page covers VS Code only. We found no Microsoft or GitHub documentation of the same Claude harness in Visual Studio 2026.

What Copilot in Visual Studio does share with Claude Code is the skills folder. GitHub's April 30, 2026 changelog says Visual Studio now discovers agent skills from .claude/skills/ and .agents/skills/ as well as .github/skills/.[8] So a skill you write for Claude Code in that folder also shows up for Copilot in Visual Studio. That is useful if half your team uses each tool. It is not the same as running Claude Code.

Which one to install

Your situation	Pick

| .NET on VS 2026, want native diffs and debugger context | firish, Claude Code for Visual Studio |

| VS 2022, want native diffs plus breakpoints and stepping, GPL-3.0 is acceptable | Corsinvest, cv4vs Agents (newest, 415 installs) |

| VS 2022, or a team that also uses Codex or another agent | dliedke, Claude Code Extension for Visual Studio |

| Solution pinned to VS 2017 or 2019 | nachum-shmilovitz-66, claude-code-visualstudio |

| Native C++ or drivers, where the nachum-shmilovitz-66 README verifies its debugger on C#/.NET only and says C/C++ is expected to work but not yet tested | Terminal route plus a strict CLAUDE.md; revisit when issue #15942 moves |

| Locked-down machine, no third-party VSIX allowed | Terminal route |

Whichever you choose, pin the CLI if your bridge is protocol-fragile. Setting "autoUpdatesChannel": "stable" in settings.json gives you a build that is about a week old and skips releases with major regressions,[7] which leaves the extension author time to catch up after a protocol change. Our October Claude Code changelog breakdown shows how often those releases land. For agent sessions that run unattended while you are in the debugger, set a hard budget first (see the Claude Code Spend Guard). If you are still choosing between agents rather than editors, start with our roundup of the best AI coding tools for 2026, and see the plugin marketplace guide for packaging the skills and hooks you build along the way. For a ready-made set of settings, hooks and rules, see the Claude Code Production Pack.

Install one extension, launch it once, and run git diff -- .claude/settings.json .mcp.json before your next commit. Whatever shows up there is now part of your team's setup.

Frequently asked questions

Is there an official Claude Code extension for Visual Studio 2026?

No. Anthropic ships plugins for VS Code (and forks such as Cursor) and for JetBrains IDEs, and points other editors to the CLI in an integrated terminal. Feature request #15942 for Visual Studio 2026 is still open.[1][2][12]

Does the VS Code Claude Code extension work in Visual Studio?

No. Visual Studio uses its own VSIX extension model, so VS Code extensions do not install in it. The Claude Code extension installs in VS Code and its forks only.[1]

Do I need a paid Claude plan to use these extensions?

Usually. All four extensions drive the Claude Code CLI, and the CLI needs a Pro, Max, Ultra, Team, Enterprise or Console account, or a third-party provider such as Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry.[7] cv4vs Agents also documents profiles for other Anthropic-compatible endpoints, with OpenRouter and Ollama among its examples.[10]

Does any extension support Visual Studio 2022?

Yes. The dliedke and cv4vs Agents extensions support 2022 and 2026, and the nachum-shmilovitz-66 project supports 2017 through 2026. The firish extension is 2026 only, with a 2022 build "planned if there is demand".[3][5][6][11]

Can Claude Code debug native C++ in Visual Studio?

None of these extensions documents tested native C++ debugger inspection. The firish debugger features are documented for managed .NET code. The nachum-shmilovitz-66 README verifies its debugger on C#/.NET only and says C/C++ is expected to work but not yet tested. The dliedke listing only promises to send unhandled exceptions with their stack trace, without naming a language. The cv4vs Agents listing names breakpoints, stepping and locals but not which runtimes they cover. Claude can still read C++ compiler errors through firish's Error List integration, and cv4vs Agents says its diagnostics work in C++.[3][5][6][11]

Will a Claude Code update break my extension?

It can. The firish README calls the IDE protocol "undocumented and version-fragile". Use the stable update channel and check the extension's release notes after a CLI update.[3][7]

Sources

12. JetBrains IDEs, Claude Code Docs, Anthropic (accessed November 2, 2026)

Originally published at wowhow.cloud

Claude API OpenTelemetry Tracing: Console Setup for 2026

Anup Karanjkar — Tue, 20 Oct 2026 19:16:46 +0000

Since 14 October 2026 the Claude API can send one OpenTelemetry trace per request or Managed Agents session to the observability backend you already run, and the first thing to decide is the destination's content mode: Metadata only or Full content.[4] Metadata only exports identifiers, timing, status and token counts. Full content also exports prompts and responses, and they then live under your backend's retention rules, not Anthropic's.[2] The feature is in public beta. An organization admin adds a destination in the Claude Console, you need no code changes for the server-side half, and an optional SDK half adds client spans that join the same trace. This post covers what each half does, the exact Console fields, a Honeycomb walk-through, the span names worth knowing, and what the docs say about limits and delivery.

TL;DR

Two independent halves: API spans (emitted by Anthropic, delivered to a destination you register) and SDK spans (emitted by the anthropic package in your process).
Only an organization admin can add a destination. Developers can view them.[1]
The destination content mode and the SDK content mode are separate settings. The SDK setting has no effect on API spans.[3]
Delivery is at least once and best effort. Do not build billing from spans; use the Usage and Cost API.
Up to 10 destinations per organization, HTTPS on port 443, a hostname rather than an IP, and no /v1/traces suffix in the base URL.
Claude Code and Agent SDK telemetry is a different system with different environment variables.

What you get: server-side spans and client-side spans

Anthropic describes the feature as OpenTelemetry trace export from Claude Managed Agents, the Messages API and the Claude SDKs, with traces following the OpenTelemetry GenAI semantic conventions.[4] In practice that is two separate pipelines that you can run alone or together.[2]

	SDK spans	API spans

| Emitted by | The anthropic package inside your process | The Claude API, inside Anthropic |

| Configured | In code or with ANTHROPIC_OPEN_TELEMETRY_* variables, plus your own OTel exporter | As a destination in the Claude Console, Admin API or CLI |

| Who can turn it on | Anyone who can change the application | Organization admin |

| Covers | Each request your client sends, tools run by the tool runner, other calls such as file uploads | Each model run, server tools such as web search, compaction, Managed Agents turns |

| Span kind | CLIENT for requests, INTERNAL for tools | SERVER for requests, INTERNAL for steps |

| Content control | traces.content_mode on the client | Content mode on the destination |

| Coverage | Clients that use the SDK | Any client, SDK or not |

The SDK sends a W3C traceparent header and the API parents its spans under it, so both halves land in one trace when they go to the same backend.[3] If your sampler drops a trace, the sampled flag in that header is off and the API emits nothing for the request. A request that arrives with no traceparent still gets API spans, in a new trace.[3]

Which half do you want? If you only need to know why a Managed Agents session went sideways or what a model run cost in tokens, the destination alone is enough, and it covers every client including ones you do not control. If you want the span for your own tool code, or the request wrapped inside your web handler's span, add the SDK half. Teams already tracking agent behavior at the application layer can pair this with the AI Agent Observability and Failure-Mode Instrumentation Pack for the alerting side.

Decide the content mode before you click Add destination

Every destination and every SDK client has a content mode.[2]

Metadata only (metadata_only in the SDK) is the default. Spans carry identifiers, timing, status, token counts, and text you choose to expose, such as agent and tool names and MCP server names.
Full content (content in the SDK) adds model prompts and responses, including the system prompt, the input messages and the output messages.
Attributes that hold prompts and responses are tagged Content in the span reference.[8]

Full content is what makes traces useful for debugging and for building evals from real traffic. It is also a copy of your users' conversations, sitting in a third-party system. The docs say plainly that the platform stores it under its own access and retention settings and that you should check those meet your requirements.[2] The cookbook's production checklist is blunter: keep metadata_only until your data policy allows otherwise.[3]

Three details that change the decision:

Even in Metadata only, the SDK still exports tool names and descriptions, agent names, MCP server names and the conversation_id you set, so do not put user data in that ID.[3]
If your organization has a HIPAA, FERPA or K-12 data-handling restriction with Anthropic, destinations export only metadata whatever the setting says. SDK spans are not affected by that rule.[2]
With zero data retention, Full content is still allowed for Messages API requests, and the API holds the exported content in memory only until delivery. Claude Managed Agents is not ZDR eligible, and its retention is unchanged by OpenTelemetry.[2]

The fourth thing is size. With Full content each span holds up to 0.75 MB of content by default. Over the limit, request spans drop the system prompt and the earliest messages first and set anthropic.content.truncated to true.[2] If your backend rejects large payloads, lower the cap.

Set up a Console destination

You need the admin role in the Console organization, an OTLP/HTTP endpoint that accepts protobuf at an HTTPS URL on port 443, and credentials for it. If you run your own OpenTelemetry Collector, its OTLP/HTTP receiver listens on port 4318 by default, so put HTTPS on 443 in front of it or reconfigure the receiver.[1]

Open the organization's OpenTelemetry settings page in the Console, click Add destination, and fill in the fields below.[1]

Field	What to enter

| Provider | A listed platform, or Custom. A listed platform replaces the endpoint and headers fields with its own details, such as an API key. |

| Name | Optional label. |

| OTLP endpoint URL | Base HTTPS URL with a hostname, not an IP. A path prefix is allowed. Do not add /v1/traces, because the API adds it. |

| Request headers | Your platform's auth header. The Console does not show the values again after you save. |

| Content mode | Metadata only or Full content. |

| Workspaces | All, Selected, or All except. |

| OTLP traces endpoint URL | Optional, under Advanced settings. Use it when your platform receives traces somewhere other than the base URL plus /v1/traces. Same host as the base URL. |

| Maximum content size in MB | Optional, Full content only. Empty means as much as the API allows. |

Save it, open the destination's More actions menu and click Test. A test span named anthropic.test should reach your platform.[1] Then send a real request from the playground or your app. The Delivery column should read Healthy within about a minute, and in your backend you filter on service.name equal to claude-platform to find the API spans.[1]

Prefer code over clicking? The same settings exist in the Admin API behind the telemetry-destinations-2026-08-11 beta header, with a matching CLI command and SDK methods. The create call takes endpoint_url, headers, traces.content_mode and workspaces.type.[1]

Choosing workspaces

A destination only receives spans from workspaces it covers, and the API sends to every enabled destination that covers the workspace where the request or session runs. All includes the Default Workspace and workspaces created later. That is a useful privacy lever: send the production workspace with Metadata only to your main backend and a staging workspace with Full content to a separate project.[1]

One backend end to end: Honeycomb

Honeycomb has a Claude Platform page, and it is the cleanest example because the Console has a built-in Honeycomb provider.[6]

In the Console, open the OpenTelemetry settings and clear any workspace filter so it shows All.
Click Add destination and pick Honeycomb as the Provider. Optionally name it, for example Honeycomb production.
Keep the default US region, which uses https://api.honeycomb.io.
Paste a Honeycomb Ingest API key. Honeycomb notes that the key needs permission to create datasets.
Leave Dataset empty. Honeycomb names it claude-platform.
Choose the content mode and the workspaces, then click Add destination.

EU teams cannot pick EU in the region picker. Honeycomb documents two workarounds: edit the destination and set the OTLP endpoint URL to https://api.eu1.honeycomb.io, or choose Custom with that URL and a request header named x-honeycomb-team holding the ingest key.[6]

To find a trace, open the environment that matches your key, go to Query, choose the claude-platform dataset and run the query, then click a point and View trace. Managed Agents conversations show up in Honeycomb's Agent Timeline, while Messages API requests carry no conversation ID, so you find those as plain traces.[6]

Grafana Cloud has a dedicated guide for Claude Platform traces, linked from Anthropic's overview.[2] Its general OTLP page shows the endpoint pattern https://otlp-gateway-<REGION>.grafana.net/otlp and says to take the exact OTLP endpoint and a generated token from your stack's OpenTelemetry tile.[7] Anthropic's overview lists Datadog, Langfuse, LangSmith, New Relic, PostHog, Sentry, Splunk, Arize AI, Braintrust and Databricks as partner platforms too, each with its own setup page. Follow each vendor's own page for its exact endpoint and headers.[2]

What a trace looks like

Span names follow one rule. They start with anthropic. followed by the API method with dots and without beta, so client.messages.create() becomes anthropic.messages.create and client.beta.sessions.events.send() becomes anthropic.sessions.events.send.[3] Under a Messages API request, the API adds spans for each model request and for each server tool or MCP connector tool it runs.[2]

Span	Emitted by	What it marks

| anthropic.messages.create | SDK (CLIENT) and API (SERVER) | One Messages API request |

| anthropic.model_request | API | One model run inside a request or turn |

| anthropic.messages.tool_runner | SDK | The whole tool-runner loop |

| anthropic.custom_tool_use <name> | SDK | A tool you run yourself |

| anthropic.tool_use <name> | API | A server tool such as web search, or a prebuilt toolset tool such as bash |

| anthropic.mcp_tool_use <name> | API and SDK | An MCP tool; the API span carries anthropic.mcp.server.name |

| anthropic.session.turn | API | One agent turn in a Managed Agents session |

| anthropic.session.outcome_evaluation | API | An outcome evaluation in a session |

| anthropic.compaction | API | Context compaction |

Attribute names come from the GenAI conventions plus an anthropic. namespace. The ones you will actually query on:[3]

gen_ai.operation.name with values chat, invoke_agent and execute_tool
gen_ai.request.model and gen_ai.response.model
gen_ai.usage.input_tokens and gen_ai.usage.output_tokens
anthropic.message.stop_reason, which the cookbook says to alert on when it equals max_tokens
anthropic.request.id, which matches the request-id header and joins SDK spans to API spans
anthropic.session.id and gen_ai.conversation.id for grouping a whole session or one thread of it

One gotcha will bite anyone building cost dashboards. gen_ai.usage.input_tokens already includes cache-read and cache-creation tokens, so adding the cache attributes on top double counts.[3] Token usage also repeats across several spans of one request. For a Messages API request, sum either the API anthropic.messages.create spans or their anthropic.model_request children, never both, plus anthropic.compaction if present. For a Managed Agents session, sum anthropic.model_request and anthropic.session.outcome_evaluation.[2] If you want a dollar figure before you build any of that, the agent run cost simulator gives a quick estimate from run length and token assumptions.

To read a Managed Agents session as a transcript, group spans by gen_ai.conversation.id for one thread, or by anthropic.session.id across traces for the whole session, since a session's spans can sit in several traces.[2] For background on the sandbox those sessions run in, see our Managed Agents self-hosted sandbox guide.

Adding the SDK half

The Python cookbook registers a tracer provider before the first traced call and then builds the client with no tracing arguments. The OTLP exporter reads the standard OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS variables.[3] To switch the client to Full content, pass open_telemetry={"traces": {"content_mode": "content"}} or set ANTHROPIC_OPEN_TELEMETRY_TRACES_CONTENT_MODE=content. Defaults are propagation on, metadata_only, and a 750,000-byte content cap.[3]

Version check: the cookbook installs anthropic>=1.14.0 (its sample output still prints 1.13.0).[3] PyPI shows 1.14.0 published on 14 October 2026, the launch day, and 1.16.0 as the latest on 20 October, so run pip show anthropic and upgrade if you are below 1.14.0.

Claude Code and the Agent SDK are a different setup

Do not mix these up. Claude Code and the Agent SDK export their own telemetry from the CLI process, enabled with CLAUDE_CODE_ENABLE_TELEMETRY=1 and a per-signal exporter variable, with traces additionally needing CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1.[5] Their spans are named claude_code.interaction, claude_code.llm_request and claude_code.tool, and the service name defaults to claude-code.[5] The Agent SDK docs add one hard rule: never set the console exporter, because the SDK uses standard output as its message channel.[5] Content there is opt-in through separate variables such as OTEL_LOG_USER_PROMPTS.[5] If you track what Claude Code itself changes between releases, our Claude Code 2.1.293 to 2.1.302 changelog is the place to start.

Limits, delivery and beta caveats

Item	What the docs say

| Destinations per organization | 10, including disabled ones |

| Selected workspaces per destination | 1,000 |

| Request headers per destination | 20; name up to 128 bytes, value up to 4,096 bytes, all together 16,384 bytes |

| Endpoint URL length | 2,048 characters |

| Delivery guarantee | At least once, best effort. Spans can arrive twice or be lost. |

| Compression | First request is gzip. On a 400 or 415 the API resends without compression. |

| Retries | A limited number of later retries after timeouts, connection, TLS or DNS failures, and 408, 429 or 5xx responses |

| Timeouts | 5 seconds for the TLS handshake, 5 seconds for response headers, 10 seconds per delivery in total |

| Auto-disable | On any 3xx redirect, on a hostname that resolves to a non-public IP, or after 24 hours of failed deliveries |

All of that comes from the API setup page.[1] Two practical consequences. First, deduplicate on trace ID plus span ID if your backend does not do it for you. Second, a redirecting endpoint is fatal, so use the final URL, not the one your vendor forwards from.

On sampling, the docs say nothing about Anthropic-side sampling rates. What they do say is that the sampled flag in your traceparent controls whether the API emits spans for a request at all.[1] On cost, neither the launch article nor the docs state a price for the export, so treat that as unconfirmed and watch your backend's ingest bill instead.[4]

The beta wording is direct: span names and attributes can change during the beta, and the feature is provided under your agreement with Anthropic including the Beta Services section of the Service Specific Terms.[8] Pin your dashboards to a small set of attributes and expect to touch them again. And do not bill from spans. The overview says exported spans are not a complete record of API usage; use the Usage API for that.[2]

Frequently asked questions

Do I need to change my application code to get API spans?

No. The destination is configured in the Console and covers every client in the organization, SDK or not. Code changes are only needed if you also want SDK spans or want API spans nested under your own spans.[1]

Who can add a destination?

The admin role in the Console organization. With the developer role you can view destinations. A developer who is also a Workspace Admin can add or remove their own workspace on a Selected destination.[1]

Does setting the SDK to metadata_only stop prompts reaching my backend?

Not for API spans. The destination content mode is independent, and the SDK content setting has no effect on API spans. Set both deliberately.[3]

Can I use these spans to calculate my bill?

No. Delivery is best effort, callers can switch off sampling per request, and Anthropic points to the Usage API for accounting.[2]

Sources

8. OpenTelemetry span reference (Claude docs)

Originally published at wowhow.cloud

Muse Spark Open: Hardware, License and Cost to Self-Host

Anup Karanjkar — Tue, 20 Oct 2026 19:16:11 +0000

Almost nobody should self-host Muse Spark Open: the model card asks for at least 700 GB of VRAM even in NVFP4, so for anything under billions of tokens a month the hosted endpoint at $1.25 per million input tokens is the cheaper and simpler route. Meta released the open-weight 816B-parameter mixture-of-experts model on 15 October 2026[1]. Only 42B parameters are active per token, which helps speed but does nothing for memory: every expert still has to sit in RAM. Below: the weight arithmetic with the real file sizes, a comparison of three ways to run it, what the license says, and how Meta's benchmark numbers stack up against the reported competition.

TL;DR

816B total parameters, 42B active, 1M-token context, BF16 and NVFP4 weights[2].
The BF16 repo holds 1.64 TB of safetensors across 65 shards[3]; the NVFP4 repo is 533 GB across 127 shards[8]. The card lists 700 GB of VRAM for NVFP4 and 2 TB for BF16.
Two M5 Ultra Mac Studios (up to 512 GB unified memory each) can hold the model in an MLX quant, per Meta[1]. Eight 80 GB H100s (640 GB) fall under the card's 700 GB line, and the NVFP4 build targets Blackwell GPUs anyway[8].
OpenRouter listed it at $1.25 input and $4.25 output per million tokens on 20 October 2026[4].
License: use, fine-tuning, distillation and redistribution are allowed. Selling it as a Model-as-a-Service (API access to outputs) once you and your affiliates pass $20 million in gross revenue in any consecutive 12 months needs a separate agreement with Meta[7].
Meta's own table has it trailing Kimi K3, GLM 5.3 and Qwen3.8 on Terminal-Bench 2.1 and the Artificial Analysis Intelligence Index[5].

What Meta actually released

Muse Spark Open is the open-weight sibling of the earlier closed Muse Spark; our earlier Muse Spark post covers that one. This release is natively multimodal, built for coding and agentic work, and carries a 1M-token context window[1].

The model card gives the architecture: a mixture-of-experts with 256 experts and 8 activated per token, 62 layers, a hidden dimension of 8192, and a 1.8B-parameter perception encoder. The Hugging Face metadata reports 822B parameters, the headline figure of 816B comes from Meta, and the gap is probably the encoder and embeddings, though the card does not say so[2].

Weights ship in BF16 and NVFP4. Inference support listed on the card covers SGLang, vLLM, Hugging Face Transformers, TensorRT-LLM, Unsloth and llama.cpp, with MLX for the Mac Studio setup[2]. Meta lists API hosting on Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI, with weight downloads also offered through Amazon SageMaker AI, Google Cloud Model Garden, Hugging Face and Microsoft Foundry Models[1].

The memory math, with the real file sizes

Weight memory is parameter count times bytes per parameter. It is the floor, not the total.

BF16: 816 billion x 2 bytes = 1,632 GB, about 1.63 TB.
NVFP4: 816 billion x 0.5 byte = 408 GB is the floor. The real NVFP4 repo (Muse-Spark-Open-816B-A42B-NVFP4) is 533 GB across 127 shards, because of the per-block scale factors and tensors kept at higher precision[8].

The arithmetic lines up with the repo. The safetensors shards total 1,644,333,393,864 bytes, or 1.64 TB (1.50 TiB), spread over 65 files: 62 shards of roughly 26 GB (two at about 29.6 GB), two of about 0.55 GB and one of about 3.8 GB[3]. The extra 12 GB or so over the 816B x 2-byte estimate is the roughly 6B parameters the headline figure leaves out (the 1.8B perception encoder and the two 1.66B embedding matrices); the Hugging Face metadata counts 822B parameters, almost all BF16 plus about 0.13B in F32[2].

The card then asks for more than the weights alone: at least 700 GB of VRAM for NVFP4 and 2 TB for BF16[2]. The NVFP4 checkpoint is 533 GB, so the card's 700 GB figure leaves roughly 167 GB for KV cache, activations and runtime overhead (the card does not break the number down). Push toward the 1M-token window and the cache grows with it. No KV-cache size per token is published in the model card or launch posts, so treat any long-context budget as a guess until measured.

One point that trips people up: 42B active parameters means each token touches about 5% of the weights, which makes decoding far cheaper per token than a dense 816B model. It does not let you load 42B worth of experts. The router can pick any expert on any token, so all of them stay resident.

Three ways to run it, side by side

Option	Memory available	What fits	Cost basis	Makes sense when

| 2x Mac Studio (M5 Ultra, MLX) | Up to 512 GB each, 1,024 GB pooled[1] | A 3-bit or 4-bit MLX quant (Hugging Face points to the oQ3e and oQ4e community builds[8]). Not BF16 (2 TB). The NVFP4 checkpoint targets NVIDIA Blackwell, not Apple silicon. | Hardware purchase, then power. Meta publishes no tokens-per-second figure; Hugging Face's launch post reports 18 tokens/s for a 2-bit llama.cpp quant on a Mac Ultra. | Private local work, one or two users, data that cannot leave the building |

| 8x 80 GB H100-class server | 640 GB total | Neither build by the card numbers. NVFP4 needs 700 GB and Blackwell-class GPUs. | Hourly GPU rental or purchase | Not on its own. Step up to 141 GB H200-class parts (8x = 1,128 GB), the NVFP4 recipe Hugging Face validates for the full 1M-token context. |

The H100 row is plain arithmetic: 8 x 80 GB = 640 GB, which is under the 700 GB the card lists. That does not mean it is impossible with aggressive tuning, only that the card does not claim it. A node of 141 GB accelerators clears the bar, and Hugging Face validates it: its Inference Endpoints recipe runs the NVFP4 build on 8 x H200 141 GB at the full 1,048,576-token context, or on 8 x RTX Pro 6000 98 GB at 131,072 tokens[8]. The vLLM reference for NVFP4 needs Blackwell-class GPUs, so an H100 box is out. Check the vLLM and SGLang docs for the current tested configuration before you rent anything.

On the Mac route, Meta calls it "the first model in its class to run on your desktop using two Apple M5 Ultra Mac Studios with the latest MLX framework" and says the two machines behave "like one supercomputer with a terabyte of unified memory"[1]. Read that as a capability claim, not a speed claim. Memory bandwidth on the chip is listed at 1.2 TB/s, which sets the ceiling for decoding. The only measured figure published is Hugging Face's 18 tokens/s for a 2-bit llama.cpp quant on a Mac Ultra[8], a lossy build, so it does not extrapolate to the MLX setup.

What hosted access costs

On 20 October 2026 the OpenRouter model list showed Muse Spark Open at $1.25 per million input tokens and $4.25 per million output tokens, with a context of about 1.05M tokens. Five providers were listed (Modal, Together, Nebius, Fireworks and BaseTen), all at the same price[4]. Providers reached directly rather than through OpenRouter (Groq, Baseten, Modal and the rest) may price differently; their own rate cards were not checked, so confirm before you commit. OpenRouter's model page also notes the model is not currently available through EU in-region routing[6].

A worked example with those listed prices: a coding agent that reads 10 million input tokens and writes 2 million output tokens in a month pays 10 x $1.25 + 2 x $4.25 = $12.50 + $8.50 = $21.00. Use the AI model cost calculator to plug in your own volumes, and the AI token counter to measure what your prompts really weigh before you estimate.

Where self-hosting breaks even

The break-even is a division you can do yourself: monthly hardware cost divided by your blended price per million tokens. At a 4:1 input-to-output mix, the listed prices blend to (4 x $1.25 + $4.25) / 5 = $1.85 per million tokens. Take a hypothetical $10,000 per month of dedicated GPU capacity. You would need to push about 5.4 billion tokens through it every month, with the cluster busy, just to match the API bill. That is the figure of $10,000 divided by $1.85, rounded. The $10,000 is an illustration, not a quote; substitute your real rental or amortised cost.

Two things push the number against you. Idle GPUs bill the same as busy ones, and you also carry the engineering time for upgrades, batching and failure handling. Two things push it for you: a hard data-residency requirement, and traffic so steady that the hardware never idles.

The license, clause by clause

The weights ship under the Muse Model License, a version titled "Muse Spark Open" and dated 15 October 2026[7]. The clauses below are taken from the full LICENSE.md text (8,299 bytes[3])[7]. The weights are also gated: you must accept the license on Hugging Face and submit a form before you can download. Read the file itself before you build a product on this.

What the license allows: use, modification including fine-tuning, distillation, merging, publishing, sublicensing and selling copies, subject to conditions. Meta claims no ownership of outputs.

What it restricts:

Attribution. You must prominently display "Built with Muse Spark Open" in the user interface of each product or service that uses the model or any Derivative, or in its documentation, website or settings menu. Derivatives include any model fine-tuned, distilled or otherwise improved using the weights or their outputs.
Model-as-a-Service threshold. If you or your affiliates give third parties API-style access to the model (or a Derivative) where they receive its outputs, and your combined gross revenue passes $20 million in any consecutive 12 months, you must notify Meta and sign a separate written agreement before offering it. Internal use, research, any commercial activity that is not Model as a Service, and using it to power features of your own product are excepted.
Usage Policy. It is incorporated into the license and prohibits illegal activity, harassment, unlicensed professional practice, malware and deceptive content.
Age. Not intended for individuals under 18.
No warranty. The software is provided "AS IS" and Meta disclaims liability for derivatives.

Meta describes the terms as limited commercial terms that let many developers use the model for free[1]. The practical read: a startup, an agency or an internal tool is comfortably inside the line. A company reselling hosted inference at scale is not. This is a custom license, not Apache 2.0 or MIT, so it will not pass a procurement checklist that only whitelists OSI-approved licenses.

Benchmarks: Meta's numbers and the competition

Everything in this table comes from the comparison table on Meta's model card (Muse Spark Open at xhigh reasoning; rival scores as Meta lists them, with some self-reported per MarkTechPost)[2][5]. Treat all of it as vendor-reported until independent evaluations land.

Benchmark	Muse Spark Open	Kimi K3	GLM 5.3	Qwen3.8

| MCP-Atlas | 89.2 | 82.3 | 84.2 | 84.5 |

| Terminal-Bench 2.1 (Terminus 2) | 76.4 | 85.0 | 83.9 | 82.0 |

| DeepSWE 1.1 | 60 | 68 | 67 | 57 |

| Toolathlon Verified | 72.8 | 76.5 | 73.0 | 72.5 |

| HLE with tools | 61.0 | 56.0 | 62.5 | 56.2 |

| Artificial Analysis Intelligence Index | 39 | 44 | 45 | 40 |

The pattern: Muse Spark Open leads on MCP-Atlas, which measures tool use over the Model Context Protocol, and on HLE-Diamond without tools (26.1 against Kimi K3's 22.2) and ZeroBench with tools (50.0 against 41.0)[5]. It trails on the terminal and software-engineering tests that matter most for a coding agent. MarkTechPost's own conclusion is that the most-capable-US-open-weight claim holds while Chinese open models still lead overall on the intelligence index, and it flags that the headline claim comes from Meta[5].

The card also reports a GPQA Diamond score of 89.0, OSWorld Verified at 80.4 and Terminal-Bench 2.1 at 76.4[2]. On safety, the card lists FORTRESS adversarial scores (ARS 5.8, ORS 17.4, lower is better) and StrongREJECT v2 at 0.5[2].

When it beats paying for a closed model

Pick it over a closed API when you need weights you control: fine-tuning on private data, a fixed model version that cannot be deprecated under you, or a data-handling rule that forbids third-party inference. Pick it for tool-use-heavy agents, where the MCP-Atlas result is the strongest in the table.

Skip it when your workload is a terminal-driven coding agent and you can get a higher Terminal-Bench score elsewhere, or when your volume sits well under the billions-of-tokens break-even above. For the cost side of the closed-versus-open choice, our DeepSeek V4.1 Flash pricing guide works through the same per-token arithmetic for another open-weight model.

A sensible first step costs almost nothing: send your real prompts to the hosted endpoint, measure quality on your own tasks, and only then price hardware. Benchmark tables decide very little; your own eval set decides most of it.

Frequently asked questions

How much memory does Muse Spark Open need?

The model card lists at least 700 GB of VRAM for the NVFP4 build and 2 TB for BF16[2]. The raw BF16 weights are 1.64 TB on disk[3]; the rest of the requirement is KV cache and runtime overhead.

Can I run it on a single GPU or a laptop?

No. Even at 4-bit the NVFP4 checkpoint is 533 GB on disk before any cache or overhead[8]. Meta's showcase hardware is two M5 Ultra Mac Studios with up to 512 GB of unified memory each[1]. Hugging Face's launch post lists llama.cpp GGUF quants (Q2_K, Q4_K_S and Q8 tested on Apple Silicon), but even a 2-bit file of an 816B model needs hundreds of gigabytes[8].

Is Muse Spark Open free for commercial use?

Mostly. Per the license, commercial use is allowed with attribution, and the main restriction is a separate agreement if you sell it as a Model-as-a-Service and you and your affiliates pass $20 million in gross revenue in any consecutive 12 months[7]. Read the full LICENSE.md before relying on this summary.

How much does the hosted API cost?

OpenRouter listed $1.25 per million input tokens and $4.25 per million output tokens on 20 October 2026[4]. Prices change, so recheck on the day.

Does 42B active parameters mean I only need 42B worth of memory?

No. The router can send any token to any expert, so all 816B parameters stay loaded. The 42B figure governs compute per token, not memory.

Sources

8. Hugging Face blog, Muse Spark Open launch post (NVFP4 repo, deployment recipes, GGUF and MLX quants)

Originally published at wowhow.cloud

.NET 11 RC2: What Is New and Whether to Upgrade From 8 or 10

Anup Karanjkar — Tue, 20 Oct 2026 19:15:38 +0000

.NET 11 RC2, published on 13 October 2026, is the final release candidate and ships with a go-live license, but the practical advice is split by where you start: .NET 8 teams must move before 10 November 2026 and should land on .NET 10, while .NET 10 teams have until November 2028 and can wait for .NET 11 GA.[1] .NET 11 is a Standard Term Support release, so it gets two years of patches, from 10 November 2026 to 9 November 2028.[2] This post covers what is new in RC2, the support table for .NET 8 to 11, the upgrade steps and the breaking-changes list, and how to decide between shipping on RC2 and waiting.

TL;DR

RC2 (11.0.0-rc.2, 13 Oct 2026) is production-usable under the go-live license, but Microsoft has not published a GA date on the RC2 post.
.NET 11 is STS: supported from 10 Nov 2026 to 9 Nov 2028 per the release notes README.
.NET 8 and .NET 9 both reach end of support on 10 Nov 2026. .NET 10 (LTS) runs to 14 Nov 2028.
C# 15 adds union types, closed hierarchies, collection expression arguments, extension indexers and labeled break and continue, all still marked preview on the docs page.
On .NET 8: go to .NET 10 now. On .NET 10: stay put, test on RC2 in CI, move after GA if you want the new features.

What RC2 is and what the go-live license means

The .NET team published the RC2 announcement on 13 October 2026. It is the second release candidate, it includes a go-live support license, and the post says it can be used in production.[1] The release notes list the sequence: preview 1 on 10 February, preview 7 on 11 August, RC1 on 8 September, and 11.0.0-rc.2 on 13 October.[2]

One thing matters for planning: the support policy page lists RC2 under go-live releases with an end-of-support date of 10 November 2026, the same day .NET 8 and 9 expire.[3] So RC2 is not a version you can sit on. If you deploy it, you commit to moving to the GA build when it appears.

The same day, Microsoft shipped the October servicing releases: .NET 10.0.13 (SDK 10.0.402), .NET 9.0.21 (SDK 9.0.319) and .NET 8.0.32 (SDK 8.0.426), each dated 13 October 2026. Their release metadata lists 44, 42 and 40 CVE fixes respectively.[7] Patch whatever you run today before you plan the bigger move.

The RC2 post lists tooling support in Visual Studio 2026 Insiders and in Visual Studio Code with the C# Dev Kit. It names no exact GA date.[1]

What is new in RC2 that a working team will notice

RC2 is a polish release, not a feature drop. The announcement is organised by area, and most items are small. Here are the ones that change day-to-day work.

Libraries and runtime

The libraries section lists incremental CBOR reading, experimental composite ML-KEM and HPKE APIs, DataAnnotations messages formatted with attribute-specific arguments, and a configurable initial HTTP/2 concurrency.[1] The ML-KEM and HPKE items are the post-quantum cryptography work; the post labels them experimental, so do not build a production protocol on them yet. On the runtime side, the only listed change is that file locking on iOS and tvOS is disabled by default.

SDK, MSBuild and NuGet

The SDK now accepts quoted values in file-level directives and allows MSBuild properties inside launch-profile arguments. MSBuild gets faster wildcard matching during project evaluation, which helps repositories with large glob-heavy projects. NuGet lets you set a minimum package publication age from the CLI, a useful guard against grabbing a package version that was published minutes ago, which is the window supply-chain attacks rely on.[1]

ASP.NET Core, MAUI, Windows Forms and F

In ASP.NET Core, the QuickGrid virtualization APIs are no longer experimental. .NET MAUI gains a way to create apps with C# UI, Apple Icon Composer asset support, XAML authoring and Hot Reload work, and updates for .NET for Android and Apple platforms. Windows Forms adds a KioskModeManager component, deferred form reveal, suspension of painting and layout during bulk updates, and new analyzers that guide the Designer. F# gets runtime async support, reraise in computation expressions, fewer allocations in FSharp.Core collections and lower compiler memory use.[1]

The RC2 post does not list C# features itself. It points to the C# 15 page, which is where the language changes live.

C# 15 in one table

The Microsoft Learn page for C# 15 lists six feature areas and calls C# 15 the latest preview release.[4] Treat that wording as the status: the page last updated on 14 September 2026, before RC2, so check it again before you depend on any of these.

Feature	What it does	Status note on the docs page

| Collection expression arguments | A with(...) first element passes capacity or a comparer to the collection constructor | Listed under C# 15 |

| Union types | The union keyword declares a value that is one of several case types, with exhaustive switch checking | Some proposal features not yet implemented |

| Closed hierarchies | A closed class can only be derived in its own assembly, so switches over it need no default arm | Listed under C# 15 |

| Extension indexers | Declare an indexer inside an extension block | Listed under C# 15 |

| Labeled break and continue | Name a loop or switch to exit or continue, instead of a flag or goto | Listed under C# 15 |

| Memory safety | Pointer relaxations and an unsafe(expression) form | Needs the preview language version |

Union types are the headline. The docs example declares public union Pet(Cat, Dog, Bird); and the compiler then checks that a switch expression covers all three cases.[4] The docs also say the runtime has included UnionAttribute and IUnion since .NET 11 Preview 5. Closed hierarchies solve the same exhaustiveness problem for class trees you control.

Labeled break and continue is the one you will use the first day. The docs show continue outer; and break outer; against a labeled outer for loop, replacing the Boolean flag pattern. A new style rule, IDE0410, flags the flag and goto patterns it replaces.[4]

Support windows for .NET 8, 9, 10 and 11

The support policy page states that LTS releases get three years of free support and patches, and STS releases get two years.[3] Here are the dates from the policy page and the .NET 11 release notes README.

Version	Release type	Original release	End of support

| .NET 8 | LTS | 14 Nov 2023 | 10 Nov 2026 |

| .NET 9 | STS | 12 Nov 2024 | 10 Nov 2026 |

| .NET 10 | LTS | 11 Nov 2025 | 14 Nov 2028 |

| .NET 11 | STS | Support starts 10 Nov 2026 (README) | 9 Nov 2028 (README) |

Two details to read carefully. First, .NET 11 does not appear in the policy page support table yet; the dates for it come from the release notes README, which says it will be supported from 10 November 2026 to 9 November 2028.[2] Second, .NET 8 loses support in the same week .NET 11 is expected to ship, so the 8 to 10 move is a deadline, not a preference.

On GA timing: the .NET Conf 2026 page lists the conference for 10 to 13 November and says it will celebrate the launch of .NET 11, but it gives no release date.[5] The README support start of 10 November lines up with day one of the conference. Treat GA at .NET Conf as expected, not announced.

Upgrade path: what to change in the repo

The mechanics are the same for every move. Pin the SDK, retarget, build with warnings visible, then read the breaking-changes list for the areas you use.

{
  "sdk": {
    "version": "11.0.100-rc.2.26504.105",
    "rollForward": "latestFeature",
    "allowPrerelease": true
  }
}

That is the RC2 SDK build listed in the dotnet/core release notes (runtime 11.0.0-rc.2).[2] Install it from get.dot.net/11 and confirm with dotnet --list-sdks. Then change the project file:


  net11.0
  false

Leave warnings-as-errors off for the first build so you can see the full list, then turn it back on once the list is clean. To check that global.json is valid JSON before CI does, paste it into the JSON formatter.

What the breaking-changes page lists

Microsoft's .NET 11 breaking-changes page groups entries by area and tags each as binary incompatible, source incompatible or a behavioral change. It carries a note that it is a work in progress and not a complete list.[6] The areas that most apps touch:

Core libraries: CborReader and CborWriter enforce a default maximum nesting depth; TAR-reading APIs verify header checksums; CRC32 validation is added when reading ZIP archive entries; Math.Round and MathF.Round return correctly rounded results; DateOnly and TimeOnly TryParse methods throw for invalid input.
Extensions: IHost.RunAsync and IHost.StopAsync throw when a BackgroundService fails; synchronous access to async-validated options throws.
JIT: floating-point conversions to small integral types are saturating, and minimum hardware requirements are updated.
Networking: SslStream server-side AIA certificate downloads are disabled by default.
SDK and MSBuild: dnx scripts bypass global.json SDK selection; the template engine packages no longer support netstandard2.0; VSTest drops its Newtonsoft.Json dependency.
.NET MAUI: the minimum Android API level is raised to 24.
Cryptography: DSA is removed from macOS.

Of these, the BackgroundService change is the one most likely to bite a service: a worker that used to fail quietly now surfaces the failure through the host. That is arguably better behavior, but it will change how your process exits and how your orchestrator restarts it.

Ship on RC2 or wait for GA

The go-live license answers the legal question. It does not answer the engineering one. Use this decision table.

You run	Deadline	Recommendation

| .NET 8 in production | 10 Nov 2026 | Move to .NET 10 now. It is LTS to Nov 2028 and has a year of fixes behind it. Do not jump to an STS preview to beat a deadline. |

| .NET 9 in production | 10 Nov 2026 | Move to .NET 10 if you want the longest runway, or to .NET 11 GA if you need a C# 15 feature. Either way, plan for November. |

| .NET 10 in production | 14 Nov 2028 | Stay. Add a CI job that builds against RC2 so the breaking-changes list becomes a known quantity before GA. |

| New internal service, short lifespan | None | RC2 is acceptable if you accept moving to GA the week it lands. |

The case against shipping RC2 to customers is simple: an RC build is a moving target until GA, and the policy page gives RC2 the same end-of-support day as .NET 8. The case for it is also real. If you are building something that needs union types and exhaustive switches today, the compiler support is there, with the caveat that parts of the union proposal are unimplemented and the language is still labeled preview.[4]

For teams on .NET 10 the better move is cheap: build against net11.0 in a side branch, count the warnings, and read only the breaking-changes entries for APIs you call. If you also run Node or Python services, the same deadline thinking applies there; see our Node 26 LTS upgrade guide and the Python 3.15 migration checklist for how those release trains compare. The MCP breaking-changes migration guide is a reminder that protocol-level breaks hit harder than language ones.

Frequently asked questions

Can I use .NET 11 RC2 in production?

Yes. The RC2 announcement says it includes a go-live support license and can be used in production.[1] The policy page lists RC2 support ending 10 November 2026, so you need to update to the GA build.

When is .NET 11 GA?

No date is stated on the RC2 post. The .NET Conf 2026 page, 10 to 13 November, says it will celebrate the launch of .NET 11, and the release notes README starts support on 10 November. GA at the conference is expected, not confirmed.[5]

Is .NET 11 LTS?

No. The README calls it a Standard Term Support release, supported for two years, to 9 November 2028.[2] .NET 10 is the current LTS.

When does .NET 8 support end?

10 November 2026, per the support policy page. .NET 9 ends the same day.[3]

Is C# 15 final in RC2?

The Microsoft Learn page still calls C# 15 the latest preview release, and some union proposal features are not implemented. Check the page again before relying on a feature.[4]

Where is the full list of breaking changes?

learn.microsoft.com/dotnet/core/compatibility/11. Microsoft notes the list is incomplete and still growing.[6]

Sources

7. dotnet/core release notes: releases.json for 8.0, 9.0 and 10.0 (October 2026 servicing, accessed 20 October 2026)

Originally published at wowhow.cloud

Google Replaces pytype With Pyrefly: Which Type Checker in 2026

Anup Karanjkar — Tue, 20 Oct 2026 19:15:05 +0000

Google has made Pyrefly, Meta's Rust-based Python type checker, its type checker across the company and is dropping pytype, and if your CI still runs pytype you are on a tool whose own README says Python 3.12 is the last supported version. Google's announcement dated 6 October 2026 reports Pyrefly as "an order of magnitude faster than Pytype" on its internal benchmarks and scoring roughly 97% on the official typing conformance suite[1]. The pytype repository was archived on 3 September 2026[2]. Below: what Google actually said, a four-way comparison of mypy, Pyright, Pyrefly and ty, a bug that a sound checker catches and a lenient one lets through, and a migration path you can run this week.

TL;DR

pytype is finished: its README names 3.12 as the last supported Python version and the repo is archived. Plan a move now, not when your next Python upgrade breaks it.
Pyrefly is the closest drop-in for pytype and mypy users who want speed: it ships pyrefly init to convert mypy or Pyright config, and runs next to your old checker while you review.
ty from Astral is fast too, but its own README calls it beta with no stable API yet, so treat it as something to trial rather than gate releases on.
Stay on mypy or Pyright if your team already has clean runs, plugins or editor setup you rely on. Speed alone is a weak reason to churn a green pipeline.
Migrate in this order: install, init, check locally, suppress the flood, add to CI beside the old checker, then remove the old one.

What Google announced, and what it did not

The post, "Adopting Pyrefly as the Python type checker at Google", was published on 6 October 2026 by the Google Python team[1]. It says Google used pytype internally for more than a decade, and gives its reasons for the switch. The reasons, summarised:

Speed. Pyrefly is written in Rust, and Google's internal benchmarks found it "an order of magnitude faster than Pytype". The post also reports incremental rebuilds up to 98% faster with a warm daemon, and a drop of more than 80% in daily peak compute used for Python type checking.
Spec conformance. Pyrefly tracks new Python versions and typing PEPs, which matters because pytype analysed compiled bytecode, and bytecode changes between Python releases. That design made new typing features hard to add.
Diagnostics. Pyrefly's errors point at the offending code with inline annotations and sometimes suggest a fix.
Soundness. Google's example is a function that wants an int being called with a value typed int | None. Pytype accepted it because one member of the union fit. Pyrefly rejects it and suggests narrowing with an is not None check.

The pytype side is stated just as plainly. The README says the team is making 3.12 the last supported Python version, attributes this to a bytecode-based design that has made new features hard, and encourages users to "investigate the mature and excellent alternative solutions for Python typing"[2]. It does not name a replacement. Google naming Pyrefly is a statement about Google's monorepo, not a recommendation for yours.

What the announcement does not give you is a deadline. There is no date after which pytype stops working on your code. The practical clock is your Python version: the day you move to 3.13 or later, pytype has nothing to say. If you are planning that upgrade, see our Python 3.15 migration checklist and put the type checker on the same list.

mypy, Pyright, Pyrefly and ty side by side

Every cell below comes from the project's own pages or its release metadata.

Checker	Written in	Maintainer	Status	Conformance	Config file

| Pyrefly | Rust[1] | Meta (default checker for Instagram's codebase, now also Google's)[1][8] | README: "current development status is stable"; latest release v1.4.0, 15 October 2026[8][9] | roughly 97% on the typing conformance suite, per Google[1] | pyrefly.toml or [tool.pyrefly] in pyproject.toml[4] |

Editor support: Pyrefly lists extensions for VS Code, Neovim and Zed[8]. ty ships a language server with completions, code actions and inlay hints, with integrations for VS Code, PyCharm and Neovim[10]. Pyright's README describes a command-line tool plus a Visual Studio Code extension[7].

Two readings of this table. First, only one tool in it has a published conformance number and it comes from Google, a user with an obvious interest in the result. Run the conformance suite yourself if the number decides your pick. Second, "stable" and "beta" are the projects' own labels; they say nothing about how many errors each will raise on your code.

The class of bug a sound checker catches

The example below is ours, not Google's, but it has the shape their post describes: a value that might be None flows into a function that needs a real number.

def discount_for(age: int) -> float:
    return 0.2 if age >= 65 else 0.0

def checkout_total(ages: dict[str, int], name: str, price: float) -> float:
    age = ages.get(name)          # int | None
    return price * (1 - discount_for(age))   # flagged: None is not an int

If name is missing from the dict, ages.get returns None, and age >= 65 raises a TypeError at runtime. It only fires for unknown customers, so tests with seeded data never hit it. A checker that treats int | None as acceptable because one half of the union fits will pass this file. A sound union check will not. The fix is to narrow before the call:

def checkout_total(ages: dict[str, int], name: str, price: float) -> float:
    age = ages.get(name)
    if age is None:
        return price
    return price * (1 - discount_for(age))

Expect the first run on a mature codebase to turn up dozens of these. Most are real latent bugs; some are places where an invariant you know about is invisible to the checker. That split is the whole migration problem, and the next section is about handling it without freezing the team.

Migrating from pytype or mypy to Pyrefly

The steps below follow Pyrefly's migration page[3]. Pyrefly documents conversion from mypy and Pyright configs; it does not document a pytype importer, so a pytype project starts from a fresh config.

1. Install beside your current checker

uv add --dev pyrefly
# or
python -m pip install pyrefly

2. Generate a config

If you have a mypy or Pyright config, run pyrefly init to convert it. The migration page warns that unrecognised settings are skipped without a warning, so diff the generated file against your old one before committing[3]. Pyrefly reads pyrefly.toml at the project root, or a [tool.pyrefly] section in pyproject.toml. Without an explicit -c flag it searches upward for pyrefly.toml, pyproject.toml, setup.py, mypy.ini and pyrightconfig.json, and if it finds no Pyrefly config it may migrate a nearby mypy or Pyright config in memory[4]. A minimal pytype-era start looks like this:

# pyrefly.toml
project-includes = ["src"]
python-version = "3.12"

Those two keys are the ones the configuration docs use in their own example. If you do not set python-version, Pyrefly queries your interpreter and falls back to 3.13.0 when that fails[4], which is worth pinning explicitly in CI.

Create the config before your first check. With no pyrefly.toml or [tool.pyrefly] section and no mypy or Pyright config nearby, Pyrefly falls back to its basic preset, which only reports high-confidence error kinds and stays silent on the None-to-int mismatch above. A pytype project has nothing to migrate, so run pyrefly init (it writes a pyrefly.toml, or a [tool.pyrefly] entry if you point it at pyproject.toml) or write the file by hand[4]. We ran Pyrefly 1.4.0 on the example from this post: 0 errors under the basic preset, then one bad-argument-type error once a pyrefly.toml with project-includes existed.

3. Run it

pyrefly check

Your old config stays in place, so both checkers can run while you review[3].

4. Handle the error flood

Pyrefly documents two routes[5]:

Suppression comments. Add # pyrefly: ignore on a line, or target one error kind with # pyrefly: ignore[bad-return]. For a whole file, # pyrefly: ignore-errors at the top. To add them in bulk, run pyrefly suppress (equivalent to pyrefly check --suppress-errors), and add --comment-location=same-line if you want comments on the error line.
A baseline file. This records current errors so CI reports only new ones, with no edits to source. Generate it with pyrefly check --baseline="baseline.json" --update-baseline and check against it with pyrefly check --baseline="baseline.json". The docs label this feature experimental, so read the current page before you depend on it.

Bulk suppression is the fast route and it leaves a visible to-do list in the diff. The baseline keeps the diff clean but hides the debt. Pick one per repo; mixing them makes it hard to say what is left. Later, pyrefly suppress --remove-unused clears suppressions that no longer match an error[5].

5. Put it in CI, then retire the old checker

Run pyrefly check as a second job beside pytype or mypy for a sprint. The migration page says you can keep both in CI, and its last step is removing the old checker and any ignore comments it left behind once you are ready[3]. It gives no CI snippets, so wire it into whatever job runner you already use. If you also manage AI-assisted Python work, a pinned checker command in your agent instructions stops an assistant from "fixing" errors by adding ignores; our Claude Code configuration pack for Python backends is one place to put that rule.

When to stay on mypy or Pyright

Google's move solves Google's problem: a monorepo, a bytecode-based tool that could not keep up, and a compute bill measured in thousands of cores. Few teams have that problem. Stay put when:

Your mypy or Pyright run is green, fast enough, and trusted. A migration that produces 400 suppressions and no new bugs found is a cost with no return.
You depend on a mypy plugin for a framework or library. Whether a plugin has a Pyrefly equivalent is something to check against your own dependency list before you start; this post does not claim parity for any specific plugin.
Your editor experience is built on Pylance or Pyright and the team likes it.
You need a stable-labelled tool today and ty's beta status rules it out, while your goal is just speed. Pyrefly's README calls it stable; ty's calls itself beta.

The reverse case is real too. If your type-check step is the slowest thing in the pre-commit loop, or you are still on pytype, trialling Pyrefly costs an afternoon: install it, run pyrefly check, and count the errors. That number tells you more than any benchmark. If it is a handful, switch. If it is thousands, suppress, baseline, and schedule the fix-up work. Related reading for a typed Python service: FastAPI production API best practices. For quick diffs of config files while you migrate, the diff checker and JSON formatter run in the browser.

Frequently asked questions

Is pytype still usable?

Yes, on Python 3.12 and earlier. Its README says 3.12 is the last supported version, and the repository is archived and read-only[2]. It will not gain support for newer typing features.

Does Pyrefly import my mypy config?

It converts mypy and Pyright configs with pyrefly init, but unrecognised settings are skipped without a warning, so review the output[3]. It does not document a pytype config importer.

What version is Pyrefly at, and is it stable?

The newest release is v1.4.0, published 15 October 2026. Pyrefly 1.0.0 was tagged on 12 May 2026[9]. The README says its development status is stable[8].

Should I use ty instead?

ty is a Rust checker and language server from Astral and is worth trialling, but its README says it is in beta and does not yet have a stable API[11]. Try it locally; do not make it a release gate yet.

How do I stop CI from failing on hundreds of old errors?

Use pyrefly suppress for one-time bulk comments, or the experimental baseline file so CI reports only new errors[5].

Is the 97% conformance figure independent?

No. It is the figure Google reports in its own announcement[1]. Run the typing conformance suite on the versions you plan to use.

Sources

14. ty configuration docs

Originally published at wowhow.cloud

OVHcloud CLI Release Hijack: Verify Downloads, Lock Releases

Anup Karanjkar — Tue, 20 Oct 2026 19:00:32 +0000

If you installed or updated the OVHcloud CLI (ovhcloud) between 12:47 and 14:21 UTC on 19 October 2026 and ended up on v0.11.0 through v0.15.0, treat every secret readable from that machine as stolen. An attacker used a hijacked developer account to replace the release archives, and OVHcloud's own advisory says the build was meant to harvest secrets from disk[1]. The fix for maintainers is one checkbox: GitHub immutable releases lock a published release's assets and tag[7]. Below: who is affected, what to do tonight, why mutable release assets made this possible, a table of defences, how to switch immutability on, and how to verify a CLI before you run it.

TL;DR

Affected: ovhcloud-cli v0.11.0 to v0.15.0 downloaded 12:47 to 14:21 UTC on 19 Oct 2026 (macOS, Linux, Windows x86_64 archives). v0.10.0 and v0.16.0 are listed as clean[1].
Do not run the binary to check it. Hash it and compare against the five MD5 values in OVHcloud's advisory, or look for an envchecker- folder in your temp directory.
If you are affected: rotate cloud, SSH, Git, Docker, Kubernetes and AI tooling credentials from a different machine, delete the binary, then install v0.16.0.
Root cause: release immutability was off, so a privileged account could overwrite assets on old releases without touching CI[5].
Maintainers: Settings, Releases, Enable release immutability. It only applies to future releases[8].
Users: pin a hash in CI and run gh release verify-asset. A checksums file inside a mutable release proves nothing, because it was swapped too[6].

What happened on 19 October 2026

The advisory (GHSA-862f-55f5-vmvw, severity High, no CVE) says a compromised OVHcloud developer GitHub account was used to replace release binaries with malicious builds. Source code and the build chain were not affected, and no other repositories were touched[1]. The Hacker News adds a detail that matters for defenders: the bad build was a plain go build from a later commit, uploaded on top of existing releases, so the release workflow never ran during the window[5].

A downstream user caught it. Their CI pinned the SHA-256 of the Linux arm64 tarball, the pin started failing, and they opened issue #300 on the repository at about 13:50 UTC[2][6]. A maintainer replied that all binaries involved were deleted at 16:21 GMT+2 (14:21 UTC), and v0.16.0 followed as an immutable release with a signed tag[2][3].

Versions, platforms and the time window

Item	Detail	Source

| Affected releases | v0.11.0, v0.12.0, v0.13.0, v0.14.0, v0.15.0 | OVHcloud advisory[1] |

| Clean releases | v0.10.0 and earlier, v0.16.0 and later | OVHcloud advisory[1] |

| Affected platforms | Darwin arm64, Darwin x86_64, Linux arm64, Linux x86_64, Windows x86_64 | OVHcloud advisory[1] |

| Not replaced | Linux i386, Windows i386, Windows arm64, WASM build | OpenSourceMalware[6] |

| Exposure window | 12:47 to 14:21 UTC (14:47 to 16:21 UTC+2) on 19 Oct | OVHcloud advisory[1] |

Press coverage disagrees on timing, so here is how to read it. BleepingComputer reports the compromised release appearing at 14:47 and being blocked at 16:21 with no timezone stated[4]. Those are Paris times. The Hacker News gives 12:47 to 14:21 UTC[5]. OpenSourceMalware's 12:47 to about 13:12 is the span in which the five releases were overwritten, not how long the files stayed up[6]. The advisory's UTC window of 12:47 to 14:21 is the one to use. Anything downloaded from those five releases before 12:47 UTC is outside it, per the advisory.

How people actually got hit

According to The Hacker News, the exposed paths were the official install script (which does not check a hash), manual downloads from the five release pages, CI jobs fetching without a pinned hash, and the CLI's own upgrade command from v0.12.0 to v0.14.0 on macOS and Linux. The same report lists Homebrew (the cask pinned the original SHA-256), go install and source builds, and the Docker image as not exposed[5]. Sources disagree on Homebrew: OpenSourceMalware lists the cask as an exposed path[6], while The Hacker News says it checked the tap history and the pinned hash would have made brew refuse the swapped file. OVHcloud's advisory does not mention Homebrew. That split is the whole story of this post: every path that verified a hash held up, and every path that trusted the release URL did not.

Is it GlassWorm?

OpenSourceMalware links the compromised account to the GlassWorm malware family. The evidence: a Solana wallet in the account's earlier force-pushed repositories that appears in public GlassWorm indicator lists. The researchers themselves call the link to the October swap their inference, and no October binary has been tied to GlassWorm because no copy was preserved[6]. Treat the attribution as tentative. It does not change what you do.

What to do tonight if you may be affected

Work through this in order. Rotation comes before the upgrade, because installing v0.16.0 does nothing about keys that were already copied.

Find the binary and hash it without running it. The advisory lists MD5 values for the malicious binaries: Darwin arm64 6f2f086239f3d88eb2750e871901927d, Darwin x86_64 347e65eb7f2d78d1c6872690272a6cc3, Linux arm64 01f57206d37c28cf711677f612052913, Linux x86_64 301bff0b51980b9e76c93633e7cfd3bd, and Windows 6a3cf153338c416169cda2fe704c8848[1].
Look for the dropped folder. A directory named envchecker- followed by random digits in your temp directory means the malware ran[1].
Rotate from a different machine. The advisory names cloud, SSH, Git, Docker, Kubernetes and AI assistant tooling credentials[1]. OpenSourceMalware's list adds package-manager tokens and .env files[6]. OVHcloud's CEO told affected users to change every secret on disk, per BleepingComputer[4].
Delete the binary, then install v0.16.0.
Check CI. Any pipeline that downloaded the CLI in the window without a pinned hash ran the swapped build on a runner that holds deploy credentials.

Hashing a binary is the easy part. Knowing what was on disk is the hard part. If you need an inventory, the AI Provider Key Hygiene Kit scans files and git history for AI provider keys and ships a rotation runbook. The same rotate-what-was-on-disk logic applied in the OpenCode console breach checklist, and the order of operations is identical: revoke first, investigate second.

Why it worked: release assets were mutable

A GitHub release is a page with files attached. Unless the repository opts in to immutability, anyone with write access can delete an attached file and upload a different one under the same name. The tag keeps pointing at the same commit, the source archive looks fine, and the release date does not change. OVHcloud's CEO said the cause was the immutability option being disabled, which let a sufficiently privileged account modify existing releases directly, bypassing the CI/CD checks, per BleepingComputer[4]. The advisory's own scope line fits: the pipelines were not the weak point[1].

OpenSourceMalware lists the contributing weaknesses beyond mutability: releases published under personal accounts, a peripheral contributor holding release-asset write permission, an install script that skips checksum verification, no provenance or signing before v0.16.0, and no private vulnerability reporting channel, so disclosure happened in a public issue[6]. The checksum file was no help either. The same report says checksums.txt was one of the six files replaced on each affected release[5][6]. A hash that lives next to the file it vouches for is only a typo check.

Defences compared: what each stops and who has to act

Defence	What it stops	What it does not stop	Who acts

| GitHub immutable releases | Replacing or deleting assets, and moving or deleting the tag, on a published release[7] | Releases published before it was switched on[8]. A compromised account cutting a brand-new release, which is a new, separately visible event | Maintainer |

| Release attestation (generated automatically for immutable releases) | Lets anyone confirm a local file matches an asset on the release[7] | Malicious code that was in the release when it was published | Maintainer publishes, user verifies |

| Checksum or signature published somewhere the uploader cannot edit | A swap by anyone who can only touch the release page | A compromised maintainer machine or signing key | Maintainer publishes, user checks |

| Hash pinned in your CI or install script | Any swap after you recorded the hash. This is what exposed the incident[2] | A release that was already bad when you pinned it | User |

| Package manager with pinned hashes (Homebrew cask) | Same swap, because the cask held the original SHA-256, per The Hacker News[5] | A maintainer who updates the pin to a bad file | Packager |

Two rows deserve a sentence each. Immutability is not a malware filter: it freezes whatever you published, good or bad, and it cannot stop an attacker from publishing a new release under a new tag. What it removes is the quiet rewrite of a trusted old release, which is exactly what let a v0.11.0 download from April turn hostile in October. And the signed-checksums row is a general pattern, not something OVHcloud shipped. Where a signature key lives matters more than the format.

For maintainers: turn on immutable releases

GitHub's documentation gives the steps[8].

One repository

Open the repository, then Settings (under the ⋯ menu if it is hidden).
Scroll to the Releases section and select Enable release immutability.

A whole organization

Open the organization, then Settings.
In the sidebar, under Code, planning, and automation, open Repository and click General.
In the Releases section, change the No policy dropdown to All repositories or Selected repositories.
For Selected repositories, click the gear icon, pick the repositories, and click Select repositories.

Read the caveat before you celebrate: the docs say immutability applies only to future releases[8]. Enabling it today does not retroactively lock last year's releases. The docs say nothing more about releases published before the switch, so for anything you must stand behind, cut a fresh release and point people at it. That is what OVHcloud did with v0.16.0, which its release page labels as an immutable release where only the title and notes can be edited[3].

The docs also describe a publishing order that fits immutability: create the release as a draft, attach every asset, then publish, so nothing is missing at the moment it locks[7]. Creating an immutable release automatically generates a release attestation that records the tag, the commit SHA and the assets[7].

What else to change on the same afternoon

Audit who holds write access on release-publishing repositories. In this incident the account was a contributor, not a core maintainer[6].
Publish releases from a bot or organization-owned identity driven by your workflow, not from a person's account.
Turn on private vulnerability reporting. OVHcloud enabled it after the incident[2], and the reporter here had to use a public issue.
Make your install script check a hash, or delete it and point people to a package manager that pins one.
Sign tags. The v0.16.0 tag is signed, though its page flags the signing key as expired[3]. A signature you cannot trust the key for is weaker than it looks, so keep keys current.

For users: verify a CLI before you run it

You have three checks, from cheapest to strongest. None requires running the download.

1. Hash it

On Linux, sha256sum ovhcloud-cli_Linux_arm64.tar.gz. On macOS, shasum -a 256 ovhcloud-cli_Linux_arm64.tar.gz. Compare against a value you got from somewhere other than the release page you downloaded from: the maintainer's docs, a package manager, or the value you recorded last time. If you only have a browser, the hash generator has a file mode that computes MD5, SHA-1, SHA-256 and SHA-512 for a file you drop in, which is handy for matching the advisory's MD5 list. For the incident here, OpenSourceMalware published SHA-256 values for the v0.15.0 Linux arm64 archive: the swapped file ended in ...28933cb and the original in ...b80e0[6].

2. Verify against the release itself

GitHub's documentation shows two commands for releases that are immutable[9]:

# confirm the release exists and is immutable
gh release verify v0.16.0 --repo ovh/ovhcloud-cli

# confirm a local file is an exact match for an asset on the release
gh release verify-asset v0.16.0 ./ovhcloud-cli_Linux_arm64.tar.gz --repo ovh/ovhcloud-cli

Run them inside a clone of the repository, or add gh's repository flag. The first command answers whether the release can still change under you. The second answers whether your file is the one attached to it. The docs add that source zip and tarball downloads cannot be checked this way, because GitHub generates them on request[9]. In the web interface, an immutable release shows an Immutable label below its title[9]. OpenSourceMalware also recommends gh attestation verify for v0.16.0[6]. We ran gh attestation verify ovhcloud-cli_Linux_arm64.tar.gz --repo ovh/ovhcloud-cli on 20 October and got an HTTP 404: v0.16.0 has no build-provenance attestation, only the release attestation that GitHub creates for immutable releases. gh release verify-asset checks that one, and it passed on the same file. So use verify-asset for this CLI, and do not read a failed gh attestation verify as proof of tampering.

3. Pin it where an attacker cannot edit it

The reporter of issue #300 never ran a verify command. They had a SHA-256 in CI, and the build broke when the file changed[2]. Pin the hash in your repository, in a Dockerfile, in a bootstrap script. Update it by pull request, with a person reading the diff. A failing pin is the cheapest intrusion detector most teams will ever deploy.

Pipelines deserve extra attention because they hold the most valuable secrets and the least human supervision. If your CI downloads tools with curl and pipes to a shell, you have the exposure OVHcloud users had. The SecretsSafe CI/CD secrets audit pack is a checklist for finding which jobs hold which credentials, which tells you the blast radius before an incident does.

Frequently asked questions

Am I affected if I installed the CLI with Homebrew?

Sources disagree. The Hacker News reports the Homebrew cask pinned the original SHA-256 and was not exposed, along with go install, source builds and the Docker image[5]. OpenSourceMalware lists the cask as exposed[6], and the advisory does not mention Homebrew. The advisory's own scope is anyone who downloaded the five releases in the 12:47 to 14:21 UTC window[1]. If you cannot say which route your machine used, hash the binary.

Does updating to v0.16.0 fix it?

It replaces the binary. It does not revoke credentials that a malicious build already read. Rotate first, from a clean machine, then upgrade.

Would immutable releases have prevented this?

The CEO's stated cause is that the setting was off and a privileged account could edit existing releases[4]. With it on for those releases, overwriting their assets would not have been possible, per GitHub's description of what is locked[7]. It would not stop a hijacked account from publishing a new release, which is why verification on the user side still matters.

Why not trust the checksums.txt on the release page?

Because in this incident it was swapped along with the archives, per The Hacker News and OpenSourceMalware[5][6]. A checksum is only evidence if the attacker could not have edited it.

Is the GlassWorm link confirmed?

No. The researchers call it inference from shared account identity, and no copy of the October binary has been analyzed publicly[6]. OVHcloud's advisory does not attribute the attack to any named group[1].

Does the advisory say what the malware sent out?

The advisory calls the builds malicious and tells affected users to treat secrets as compromised[1]. The Hacker News notes OVHcloud has not said which files the binary read or where it sent data[5]. Assume the worst for anything on the disk.

Sources

9. GitHub Docs: verifying the integrity of a release (accessed 20 October 2026)

Originally published at wowhow.cloud

TaxGst.in Free Income Tax Calculator, Free GST Tools & Finance Guides India

Anup Karanjkar — Tue, 20 Oct 2026 09:47:17 +0000

Why TaxGst.in is the Go‑to Free Income Tax Calculator for Indian Developers

Developers building payroll, finance, or fintech applications need a reliable, zero‑cost income tax calculator that reflects the latest Indian tax slabs, cess, and deductions. TaxGst.in offers a web‑based calculator that instantly computes federal tax liability, handles HRA, home‑loan interest, and even capital‑gains nuances. Because it’s free, you can embed its logic, call its API, or simply direct users to the Income Tax Calculator page without worrying about licensing fees. This article walks you through the tool’s core features, integration patterns, and complementary GST utilities that keep your codebase tax‑compliant.

Core Features of the Free Income Tax Calculator

TaxGst.in’s calculator is built on the same rules the Indian Income Tax Department publishes each FY. The engine supports:

All individual tax slabs for FY 2024‑25 (including the new 30 % top rate).
Standard deduction, professional tax, and Section 80C‑80U deductions.
HRA exemption calculation based on rent paid, city tier, and basic salary.
Home‑loan interest deduction under Section 24(b).
Capital gains from equity, debt, and real‑estate assets.
Automatic inclusion of health and education cess (4 %).

Example: Calculating Tax for a Bangalore Engineer

Assume a software engineer in Bangalore earns ₹15,00,000 per annum, receives ₹1,80,000 HRA, pays ₹2,40,000 annual rent, and has a home‑loan interest of ₹1,20,000. The following JavaScript snippet demonstrates how to call TaxGst.in’s public endpoint (hypothetical) to fetch the tax liability:

const payload = {
  financialYear: "2024-25",
  grossSalary: 1500000,
  hraReceived: 180000,
  rentPaid: 240000,
  cityTier: "II",
  homeLoanInterest: 120000,
  deductions: {
    section80C: 150000,
    section80D: 25000
  }
};

fetch('https://api.taxgst.in/v1/income-tax', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(payload)
})
.then(res => res.json())
.then(data => console.log('Tax payable:', data.taxPayable))
.catch(err => console.error(err));

The API returns a JSON object with taxPayable, taxBreakup, and effectiveRate. You can then store the result, display it in a UI, or feed it into downstream payroll processing.

Integrating the Calculator into a Payroll Service

For a SaaS payroll product, you’ll need to run the tax computation for hundreds of employees each month. Below is a Node.js micro‑service outline that pulls employee data from a MongoDB collection, runs the calculation, and writes the result back.

const { MongoClient } = require('mongodb');
const fetch = require('node-fetch');

async function computeTaxes() {
  const client = await MongoClient.connect(process.env.MONGO_URI);
  const db = client.db('payroll');
  const employees = await db.collection('employees').find({}).toArray();

  for (const emp of employees) {
    const response = await fetch('https://api.taxgst.in/v1/income-tax', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        financialYear: "2024-25",
        grossSalary: emp.annualCtc,
        hraReceived: emp.hra,
        rentPaid: emp.rent,
        cityTier: emp.cityTier,
        homeLoanInterest: emp.homeLoanInterest,
        deductions: emp.deductions
      })
    });
    const result = await response.json();
    await db.collection('taxes').updateOne(
      { employeeId: emp._id },
      { $set: { taxPayable: result.taxPayable, computedAt: new Date() } },
      { upsert: true }
    );
  }
  client.close();
}

computeTaxes().catch(console.error);

This pattern scales horizontally; you can spin up multiple instances behind a queue (e.g., RabbitMQ) to handle spikes during year‑end processing.

Beyond Income Tax: Free GST Tools for Developers

When you build e‑commerce or B2B platforms, GST compliance is equally critical. TaxGst.in hosts a suite of free GST utilities that you can call directly from your backend:

GST Calculator

Use the GST Calculator to compute tax on invoice amounts, handle CGST, SGST, and IGST splits based on the buyer’s state, and round off to the nearest rupee. Here’s a quick Python example:

import requests

def calculate_gst(amount, seller_state, buyer_state):
    payload = {
        "invoiceAmount": amount,
        "sellerState": seller_state,
        "buyerState": buyer_state,
        "gstRate": 18  # default GST rate for most goods
    }
    r = requests.post('https://api.taxgst.in/v1/gst', json=payload)
    return r.json()

print(calculate_gst(5000, "Karnataka", "Maharashtra"))

GST Late Fee & Interest Calculator

If you need to display penalties for delayed filing, the GST Late Fee & Interest Calculator provides the exact interest amount based on the number of delayed days. The endpoint expects principalAmount and delayDays as inputs.

Capital Gains Tax Calculator

For asset‑management apps, the India Capital Gains Tax Calculator computes short‑term and long‑term gains on equities, mutual funds, and property. Example request:

curl -X POST https://api.taxgst.in/v1/capital-gains \
  -H "Content-Type: application/json" \
  -d '{
        "assetType": "Equity",
        "purchaseDate": "2021-04-10",
        "saleDate": "2024-03-15",
        "purchasePrice": 250000,
        "salePrice": 400000,
        "indexationBenefit": false
      }'

Choosing the Right Tool for Your Product Roadmap

TaxGst.in’s free suite covers most tax scenarios, but you may need additional modules for specific use‑cases. Browse the product recommendations page to see premium APIs, bulk upload utilities, and compliance dashboards that integrate with the free calculators.

Best Practices for Accuracy and Performance

Tax rules change every budget. To keep your application up‑to‑date:

Cache the tax‑rate JSON payload for 24 hours, then refresh.
Validate user inputs on the client side to avoid unnecessary API calls.
Log every calculation request with a correlation ID for audit trails.
Run integration tests against the sandbox endpoint before production releases.

Here’s a Node.js middleware that enforces these practices:

const rateCache = { data: null, expires: 0 };

async function taxRateMiddleware(req, res, next) {
  if (Date.now() > rateCache.expires) {
    const r = await fetch('https://api.taxgst.in/v1/rates');
    rateCache.data = await r.json();
    rateCache.expires = Date.now() + 24 * 60 * 60 * 1000; // 24h
  }
  req.taxRates = rateCache.data;
  next();
}

Real‑World Use Cases from the Developer Community

Below are three short case studies that show how teams incorporated TaxGst.in tools:

FinTech Startup “PayBuddy”

PayBuddy needed to show users their projected tax liability when they created a savings goal. By embedding the Income Tax Calculator in a React component, they reduced manual calculations by 90 % and cut support tickets related to tax queries.

E‑Commerce Platform “CartKart”

CartKart integrated the GST Calculator into its checkout service. The API handled state‑wise IGST/CGST splits automatically, eliminating errors that previously caused order cancellations.

Real Estate Investment App “PropGain”

PropGain used the Capital Gains Tax Calculator to provide investors with a “post‑sale net profit” figure, accounting for indexation benefits. The feature boosted user engagement by 35 %.

Testing Tax Logic with Unit Tests

Because tax calculations are deterministic, you can write straightforward unit tests. Here’s a Jest test for the Bangalore engineer example:

test('calculates tax for Bangalore engineer', async () => {
  const payload = {
    financialYear: "2024-25",
    grossSalary: 1500000,
    hraReceived: 180000,
    rentPaid: 240000,
    cityTier: "II",
    homeLoanInterest: 120000,
    deductions: {
      section80C: 150000,
      section80D: 25000
    }
  };
  const response = await request(app)
    .post('/api/tax')
    .send(payload)
    .expect(200);
  expect(response.body.taxPayable).toBeCloseTo(158700, -2);
});

The expected tax payable (₹158,700) matches the manual calculation using the Income Tax Calculator UI, confirming that the integration behaves correctly.

Future Enhancements You Might Want to Track

While the current free tools cover most statutory requirements, keep an eye on upcoming features:

Support for the new optional tax regime introduced in FY 2025‑26.
Batch processing endpoints for large payroll runs.
GraphQL wrapper for selective field retrieval, reducing payload size.

Subscribe to TaxGst.in’s developer newsletter to receive release notes and migration guides.

The GST Late Fee & Interest Calculator returns the exact interest based on the principal amount and days of delay, so you can display the penalty directly without custom logic.

Originally published at wowhow.cloud

Node 26 Becomes LTS on 28 October: Upgrade Guide from 24 and 22

Anup Karanjkar — Mon, 19 Oct 2026 13:15:05 +0000

Node.js 26 is scheduled to enter Long Term Support on 28 October 2026, eight days after Node 24 drops from Active LTS to Maintenance on 20 October, and it is supported through 30 April 2029.[1] Node 22 stays in Maintenance until 30 April 2027, and Node 20 has been end-of-life since 30 April 2026. As of 19 October the latest 26.x release is 26.12.0, shipped 14 October with V8 14.6 and npm 11.20.0[2]. This post gives you the full schedule table from the official file, the changes in Node 26 that can actually break an upgrade, the exact commands for nvm, fnm, Volta, GitHub Actions and Docker, and a plain answer to whether you should move now or wait. Nothing here is true until the release team flips the switch, so every date below is the planned one.

TL;DR

Node 26 becomes LTS on 28 October 2026 (planned). The schedule file lists no codename yet, so none is stated here.
Node 24 enters Maintenance on 20 October 2026 and reaches end-of-life on 30 April 2028. Staying on 24 is safe for production.
Node 22 is already in Maintenance and ends on 30 April 2027. It is the line that needs a plan first.
Node 20 is end-of-life since 30 April 2026 and gets no security fixes.
What bites in 26: removed http.Server.prototype.writeHeader(), removed legacy _stream_* modules, runtime deprecations for module.register(), and the removal of --experimental-transform-types.
Run your tests on 26 with --trace-deprecation this week; switch production after 28 October, not before.

Node.js release schedule as of 19 October 2026

The Node.js Release working group publishes its schedule as a JSON file, and the README table in the same repository is generated from the same dates[1][3]. The table below is copied from that file. The README adds the caveat that dates are subject to change, and that the exact date of an LTS move is chosen no later than the first day of the month it happens in.

Line	Status on 19 Oct 2026	First release	LTS start	Maintenance start	End-of-life

| Node 20 (Iron) | End-of-life | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 |

| Node 22 (Jod) | Maintenance LTS | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 |

| Node 24 (Krypton) | Active LTS until 20 Oct | 2025-05-06 | 2025-10-28 | 2026-10-20 | 2028-04-30 |

| Node 26 | Current | 2026-05-05 | 2026-10-28 | 2027-10-20 | 2029-04-30 |

Two readings of that table matter. First, the working group says an even-numbered line stays in Active LTS for 12 months and then spends 18 months in Maintenance[3]. Node 24 and 26 both fit that pattern: 28 October to 20 October is the 12 months, 20 October to 30 April the 18. Second, the Node 27 row carries no LTS date and no codename in the schedule file. The file does not say what that means for the odd/even rule, so check the file again before you plan anything around 27.

What Maintenance means for Node 24

The README defines Maintenance as critical bug fixes and security updates, with new features added only at the release team's discretion, typically when they help migration to a later line[3]. It does not mean abandoned. Node 24 will keep getting security releases for another 18 months. The practical difference is that you should stop expecting backports of new APIs, and you should treat the line as a place you are leaving, not a place you are settling.

Why Node 22 is the line that needs a decision

Node 22 has about six months of life left (30 April 2027). If you run it, the question is not whether to move but whether to go to 24 or straight to 26. Going to 24 buys you until April 2028. Going to 26 buys you until April 2029 and one fewer migration. The catch is that 26 has been out for five months as a Current release, and the changes in the next section apply to you in full.

What changed in Node 26 that matters when you upgrade

The 26.0.0 release notes, dated 5 May 2026, list the headline items as the Temporal API enabled by default, V8 updated to 14.6 and Undici updated to 8.0[4]. Version numbers from the release feed: 26.12.0 ships V8 14.6.202.34 and npm 11.20.0, while Node 24.22.0 ships V8 13.6 and npm 11.19.1, and Node 22.23.3 ships V8 12.4 and npm 10.9.9[2]. The npm major jump matters if you move from 22, because npm 10 to 11 is a separate set of changes to read.

New in 26.0.0

Temporal API on by default. The modern date and time API is available without a flag, contributed by Richard Lau in PR 61806[4]. Your Date code keeps working. Nothing forces you to migrate, but libraries that feature-detect Temporal may change behavior once it exists.
V8 14.6. The notes call out Map.prototype.getOrInsert() and getOrInsertComputed() (also on WeakMap) plus Iterator.concat()[4]. Both are small, but getOrInsertComputed removes the common get-check-set pattern in caches.
Undici 8.0.2 in the 26.0.0 release, which backs fetch. If you pin a custom undici dispatcher or agent, retest it.

Removed and deprecated in 26.0.0

These are the entries that break builds, taken from the Deprecations and Removals section of the changelog[4]:

http.Server.prototype.writeHeader() is gone. Use writeHead().
The legacy _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform and _stream_passthrough modules are removed. Old packages that require('_stream_readable') will throw. Import from node:stream.
--experimental-transform-types is removed, which hits anyone running TypeScript files through that flag.
module.register() is now runtime-deprecated, so loader setups built on it print a warning.
DEP0182 moved to end-of-life, DEP0203 and DEP0204 became runtime deprecations in crypto, and DEP0201 in stream became a runtime deprecation. I did not look up what each DEP number covers in the deprecations page, so grep your warnings for those codes.
Platform floor: the build now needs GCC 13.2 and drops Python 3.9[4]. That matters if you compile Node yourself or build native addons on old CI images.

One more change that is easy to miss: localStorage now returns undefined when no storage file is configured, per the semver-major list in the same release[4]. Code that assumed an object will fail at the first property access.

Useful additions since 26.0.0

Node 26 already has twelve minor releases (26.1.0 to 26.12.0), so some features you may want are not in 24. These are the ones listed under Notable Changes, with the release that added them[4]:

Version	Date	Addition

| 26.1.0 | 2026-05-07 | Experimental node:ffi module, behind --experimental-ffi |

| 26.2.0 | 2026-05-20 | stream.compose marked stable; writeInformation for 1xx responses |

| 26.8.0 | 2026-08-26 | TracingChannel in diagnostics_channel marked stable |

| 26.9.0 | 2026-09-16 | node:ffi enabled by default |

| 26.11.0 | 2026-10-07 | Buffer.stringLength(), isLatin1, Alpine Linux promoted to tier 2 support |

| 26.12.0 | 2026-10-14 | http.websocketMask() and websocketUnmask() |

The ffi row deserves a second look. The 26.1.0 notes say the API is inherently unsafe, since bad pointers or wrong signatures can crash the process or corrupt memory[4]. Being on by default in 26.9.0 does not make it safe. Treat it as something you do not use in production code until it has a track record. Also from the notes: the 26.3.0 release flags a risk that macOS Universal Binaries may not be maintained for the full life of Node 26, though the stated intention is to keep shipping them as long as practical.

Upgrade checklist: Node 24 or 22 to Node 26

1. Install 26 beside your current version

Do not replace anything yet. Install 26 next to what you run, so you can switch per shell.

# nvm: install, then carry global packages over from 24
nvm install --reinstall-packages-from=24 26
nvm use 26

# fnm
fnm install 26
fnm use 26

# Volta (pins the version in package.json)
volta install node@26
volta pin node@26

The --reinstall-packages-from flag is documented in the nvm README[5], and fnm install [VERSION] and fnm use [VERSION] are in the fnm command reference[6]. The Volta commands are from memory of its docs and I did not re-verify them today, so run volta --help if one fails. After 28 October, nvm install --lts should resolve to 26, but check node -v rather than trusting it.

2. Declare what you support in package.json

{
  "engines": {
    "node": ">=24 <27"
  }
}

Widening engines to cover both 24 and 26 lets you run both in CI during the transition without npm complaining. Add "engine-strict=true" to .npmrc if you want npm to enforce it. Also drop a .nvmrc or .node-version file: the actions/setup-node action reads either through its node-version-file input[7]. If you use Corepack for package managers, run corepack --version after installing 26 to confirm it is present, because Corepack distribution has changed across recent Node releases and I did not trace the details.

3. Run a CI matrix on both lines

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [24, 26]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test

The current major of actions/setup-node is v7; its latest release, v7.1.0, was published on 8 October 2026[7]. The README also notes that automatic package-manager caching is on by default and can be turned off with package-manager-cache: false for workflows that handle sensitive data. For a full pipeline around this step, see our GitHub Actions CI/CD pipeline for Node.js.

4. Update Docker base images

Docker Hub already carries the 26 tags: node:26, node:26-slim, node:26-alpine, node:26-bookworm-slim and node:26-trixie-slim, plus pinned forms like node:26.12.0[8]. Pin a major (node:26-slim) in production, and pin the full version if you need byte-identical rebuilds. I could not confirm from a primary source whether Docker will add an lts alias pointing at 26 on 28 October, so do not depend on one. If your image builds native addons on Alpine, remember that 26.11.0 promoted Alpine to tier 2 support[4], which is good news but not a reason to skip a test build. Our production Docker Compose guide for Node.js covers the rest of the stack.

How to test before you switch

Run the full suite on 26. Start with unit tests, then integration tests against real databases and queues. Failures from removed APIs show up as thrown errors, so they are loud.
Surface deprecations. Run node --trace-deprecation your-entry.js or set NODE_OPTIONS=--trace-deprecation in CI. Runtime deprecations print a warning with a stack, and the stack usually points at a dependency, not your code. To make the suite fail on them, use --throw-deprecation.
Grep for the removed names. Search your source and node_modules for writeHeader(, _stream_, module.register and experimental-transform-types. Dependencies are the usual source of old stream imports.
Rebuild native addons. Delete node_modules and run npm ci on 26 so every addon compiles against the new V8. Anything built with node-gyp needs a toolchain that supports GCC 13.2 on Linux; addons that ship prebuilt binaries need a release that targets Node 26's ABI. If a package has no 26 build, that is your blocker, not Node.
Diff your fixtures and configs. When a test fails on a data shape, normalize the sample before comparing. Paste it into the JSON formatter to normalize them before comparing, or run YAML configs through the YAML to JSON converter.
Soak in staging. Run 26 under real traffic in staging for a week and watch memory and latency. A new V8 changes garbage collection behavior in ways unit tests do not show.

If your project is a command-line tool, our Node.js and TypeScript CLI guide has patterns for testing across several runtime versions.

When to upgrade now, and when to wait

Your situation	Recommendation	Reason

| Production on Node 20 | Move now, to 24 at minimum | End-of-life since 30 April 2026; no security fixes |

| Production on Node 22 | Plan the move before spring 2027; test on 26 now | Ends 30 April 2027 |

| Production on Node 24 | Wait. Test on 26, switch in 2027 | Supported until 30 April 2028 |

| New project | Start on 24 today, or 26 after 28 October | 26 is the longer runway (to April 2029) |

| Library author | Add 26 to your CI matrix now | Users will adopt 26 as soon as it is LTS |

The reason to wait on 24 is boring and sound: LTS lines get fixes that have been audited by the release team, and a Current line that has just changed status has had less production exposure than the fifth month of a stable one. Node 26 has had five months of Current releases, and the 26.3.1 and 26.5.1 releases each shipped a list of CVE fixes[4]. Active patching counts in its favor, though it also shows the line has had real security work to do.

If you do move before the LTS date, treat it as a normal Current-line adoption: pin an exact version, watch the changelog for each minor, and be ready to roll back.

Frequently asked questions

What date does Node 26 become LTS?

The official schedule file lists 28 October 2026 as the LTS start for Node 26[1]. The README says dates are subject to change, so confirm on the day. This post was written on 19 October, before that date.

Is Node 24 still safe to use after 20 October?

Yes. From 20 October 2026 it is in Maintenance, which means critical bug fixes and security updates, until 30 April 2028[1]. You lose new-feature backports, not security fixes.

When does Node 22 reach end-of-life?

30 April 2027, according to the schedule file[1]. It has been in Maintenance since 21 October 2025.

Is Node 20 end-of-life already?

Yes. The schedule lists 30 April 2026 as its end date[1]. If you still run it, upgrade to 24 or 26 rather than hunting for patched builds.

Does Node 26 have a codename?

Not in the schedule file as of 19 October 2026, where the codename field for v26 is empty[1]. Earlier LTS lines got element names such as Jod and Krypton, but I will not guess one for 26.

Can I skip Node 24 and go from 22 straight to 26?

Yes, and many teams will. You inherit every removal and deprecation between the two lines, plus the npm 10 to 11 change, so read the changelogs for 24 and 26 and run the test steps above. I only reviewed the 26 changelog for this post.

Sources

8. Docker Hub: official node image tags (read 19 October 2026)

Originally published at wowhow.cloud

UPI MDR Deferred Past Diwali: What Merchants Should Check Now

Anup Karanjkar — Mon, 19 Oct 2026 13:08:39 +0000

UPI MDR on larger merchant payments is deferred, not cancelled: NPCI said on 13 October 2026 that it will start "immediately post Diwali at a date to be notified separately", and as of 19 October 2026 no date has been notified.[1] The rule that was due on 15 October was a Merchant Discount Rate of up to 0.4% on UPI person-to-merchant (P2M) payments above ₹2,000, paid by the merchant, never the customer.[2] Diwali Laxmi Pujan is on Sunday 8 November 2026,[6] and a date straight after the festival is consistent with NPCI's wording, but none has been notified. This guide separates what two primary documents confirm from what only news outlets have reported, then walks a freelancer, online seller or shop through what to check before the date lands.

This is general information, not tax, legal or financial advice. Nothing here is a statement of what will be charged on any date, because no effective date is notified. Rates, caps and exemptions marked "as reported" come from news summaries, not from an NPCI circular I could open. Confirm against your bank, payment gateway agreement or a qualified professional before changing prices or contracts.

TL;DR

Status: deferred. NPCI's steering committee postponed MDR on "select" P2M UPI transactions to "immediately post Diwali"; no new date is notified as of 19 October 2026.
Described in Paytm's stock-exchange filing, which cites the circular: NPCI circular OC-No.237/2026-27 of 15 September 2026 set an MDR of up to 0.4% on P2M UPI payments above ₹2,000, and customers pay nothing.
Reported only (not read in the original): a ₹300 cap per transaction, flat ₹5 for some categories, 0.02% for capital markets, and an exemption for small merchants collecting up to ₹1 lakh a month on a UPI QR.
Your job this week: tag every receipt as P2P, P2M via QR, or P2M via gateway; add up your monthly UPI QR total; read your gateway agreement for UPI fees.
Do not reprice yet. Model the cost with the examples below and wait for the notified date and the final rate card.

What is actually decided, and what is not

Only two things in this story rest on documents anyone can open. The first is NPCI's press release dated Mumbai, 13 October 2026. Its operative sentence reads: "UPI and Services Steering Committee today decided that, keeping in mind the festive season, Merchant Discount Rate (MDR) on select Person-to-Merchant (P2M) UPI transactions, shall be implemented immediately post Diwali at a date to be notified separately."[1] It contains no rate, no threshold and no date. I opened it through a text mirror because the NPCI site refused a direct download.

The second is a disclosure that One 97 Communications (Paytm) filed with BSE and NSE on 15 September 2026. It says NPCI, through circular no. NPCI/UPI/OC-No.237/2026-27 dated 15 September 2026, "introduced a Merchant Discount Rate of upto 0.4% on UPI Person-to-Merchant (P2M) transactions exceeding ₹2,000", that the circular "shall be effective from October 15, 2026", and that "no charge is levied on customers for UPI payments, which shall continue to remain free of charge for them."[2] The 15 October date has since been overtaken by the deferral. I could not open the circular itself, so everything beyond the Paytm filing's description is second-hand.

That second-hand layer is large. Law-and-business outlets summarised an NPCI FAQ and a government notification, and their summaries are where the ₹300 cap and the ₹1 lakh exemption come from. They are plausible and they agree with each other on most points, but a summary of a FAQ is not the FAQ. The table keeps the source visible for every line.

Item	What is stated	Source	Status

How the timeline reads

The sequence matters because search results still show the old date. Anyone who read "from 15 October" in mid-September is now out of date.

14 September 2026: a Department of Financial Services notification is reported, covering charges on UPI and RuPay debit card payments up to ₹2,000.[5]
15 September 2026: NPCI circular OC-No.237/2026-27, effective 15 October according to Paytm's filing; NPCI FAQs follow, as summarised by SCC Online.[2][3]
13 October 2026: NPCI defers the start to immediately after Diwali, date to be notified separately.[1]
19 October 2026: no new date is notified.
8 November 2026: Diwali Laxmi Pujan; NSE also lists 10 November as a trading holiday for Diwali Bali Pratipada.[6]

"Immediately post Diwali" does not map to a single calendar day. Diwali is a multi-day festival, so the first working day after the last festival holiday, the first of the next month, or a mid-month date are all consistent with the wording. Plan for the earliest case: assume the charge could apply within days of 10 November and make your preparations in October.

The government notification covers payments up to ₹2,000

The reported section 10A notification is the part to treat most carefully. LiveLaw's headline says the Centre prohibits charges on UPI transactions up to ₹2,000 and on RuPay debit cards.[5] That is consistent with the NPCI framework leaving payments up to ₹2,000 free. Only LiveLaw reports the notification, and it covers charges up to ₹2,000; no source cited here says what it means for payments above ₹2,000, and I have not read the gazette text. So this guide does not say that MDR above ₹2,000 is legally settled in any direction. The only fact that is safe to build on is the NPCI circular as described in Paytm's filing, plus NPCI's own statement that the start is deferred.

Step 1: sort your receipts into P2P, P2M by QR and P2M by gateway

MDR, as described in every source above, sits on person-to-merchant payments. Whether you owe anything therefore depends on how the money reached you, not on what you sell.

The three buckets

P2P receipts. A friend or relative sends you money to your personal UPI ID. Reported as exempt whatever the amount.[3] This bucket does not become business income just because you also freelance; it simply is not the target of the rule.

P2M by QR or merchant VPA. A customer scans a merchant QR registered to your shop or business, or pays to a merchant handle. This is where the reported ₹1 lakh a month exemption for small P2PM merchants applies, if it stands.[4]

P2M through a payment gateway or aggregator. Your website checkout, payment link or invoice link opens UPI inside Razorpay, Cashfree, PhonePe PG, PayU or similar. Your contract is with the gateway, not directly with a bank, so the question of who bears NPCI's MDR is a matter of your agreement with them.

A five-minute audit

Export three months of settlement or bank statements and tag each credit. A spreadsheet with four columns is enough: date, amount, bucket, and payer type (individual or business). Then total the P2M QR column per calendar month. The result tells you two things: whether you sit near the reported ₹1 lakh threshold, and how many payments land above ₹2,000.

If you take client payments to a personal handle because it is convenient, flag it. Collecting business payments on a personal VPA is a question about your bank's terms and about clean bookkeeping, and I am not offering an interpretation of how the MDR framework would treat it. Ask your bank. Separately, keeping business and personal money apart is what the freelancer accounting guide recommends for GST and ITR reasons that have nothing to do with MDR.

Step 2: do you count as a small P2PM merchant?

As reported, NPCI's FAQ defines the small-merchant tier as vendors who receive up to ₹1 lakh a month through UPI QR codes directly into their accounts, with GST registration not required to qualify[3], and with the exemption holding even when a single payment is above ₹2,000.[4] SCC Online adds a qualifier: MDR applicability depends on the merchant's overall categorisation and monthly collections.[3]

Practical reading, flagged as unconfirmed: a tea stall, tutor or home baker taking ₹300 to ₹1,500 per sale on a QR will probably never see a charge. A freelancer who gets a handful of ₹25,000 payments, or a shop with a busy month above ₹1 lakh in QR collections, is the person the rule can reach. What is not known is how the monthly total is measured (calendar month, which accounts, whether gateway settlements count) and what happens in a month you cross the line. Those are details for the final circular.

Worked examples (illustrative only)

The arithmetic below applies the reported structure to round numbers. None of it is a quote of a notified rate card. The reported cap of ₹300 is applied to payments of ₹75,000 and above, which is where 0.4% reaches ₹300.

Payment	Calculation (reported rules)	Merchant pays	Net received

| ₹1,500 | Up to ₹2,000, outside MDR | ₹0 | ₹1,500 |

| ₹2,000 | Not above ₹2,000 | ₹0 | ₹2,000 |

| ₹3,000 | 0.4% x 3,000 | ₹12 | ₹2,988 |

| ₹5,000 | 0.4% x 5,000 | ₹20 | ₹4,980 |

| ₹50,000 | 0.4% x 50,000 | ₹200 | ₹49,800 |

| ₹75,000 | 0.4% x 75,000 = 300, equals the cap | ₹300 | ₹74,700 |

| ₹1,00,000 | 0.4% = ₹400, capped at ₹300 | ₹300 | ₹99,700 |

| ₹3,000 fuel or insurance premium | Flat ₹5 (reported) | ₹5 | ₹2,995 |

| ₹1,00,000 mutual fund purchase | 0.02% x 1,00,000 (reported) | ₹20 | ₹99,980 |

Two things stand out. The ₹3,000, ₹50,000 and ₹75,000 and above rows match the NPCI FAQ examples as SCC Online reproduced them (₹12, ₹200 and ₹300).[3] And the percentage drops as tickets grow: ₹300 on ₹1,00,000 is 0.3%, and ₹300 on ₹3,00,000 is 0.1%.

Three business scenarios

The freelance designer. Ten client payments of ₹25,000 in a month, ₹2,50,000 in total. At 0.4% each costs ₹100, so ₹1,000 across the month. If those payments arrive as P2M on a merchant QR and the account is not in the small-merchant tier, that is the exposure. If the same ten payments are bank transfers, the exposure is zero.

The online seller. A store taking 200 orders a month at ₹1,500 pays nothing, because every order is at or below ₹2,000. The same store selling 40 orders at ₹3,000 (₹1,20,000 in total) would pay 40 x ₹12 = ₹480, about 0.4% of revenue, if its UPI payments count as standard P2M. The reported ₹1 lakh a month small-merchant tier is described for UPI QR collections, so it may not apply to gateway checkout at all.

The shop with a counter QR. Most baskets are below ₹2,000, which NPCI says covers over 95% of merchant UPI volume (reported by SCC Online and Outlook India).[3] The risk is concentrated in a few large baskets: an electronics shop with ten ₹20,000 sales pays up to ₹80 each, ₹800 total. To run your own numbers, multiply each payment above ₹2,000 by 0.004 and cap the result at ₹300 if the reported cap holds. To compare card and international gateway fees, the payment fee calculator covers those providers.

The gateway angle

If you sell through a checkout page or send payment links, you are probably not paying NPCI directly. Your gateway collects from the customer's bank and settles to you. Whether and how a gateway passes a new MDR on to you is set by its agreement and pricing page. I did not verify any gateway's current UPI pricing in preparing this guide, and gateway fees change, so I am not quoting numbers. What to look for in your agreement:

Does the plan list a UPI rate today, or does it say "0% on UPI" for a promotional period that may end?
Is there a clause allowing the gateway to pass on "regulatory or network charges"?
Is there notice period before a pricing change, and do you have to accept it to keep processing?
Does the fee apply to the gross amount or the net after GST?
Do refunds return the fee?

The last question is not trivial. If a ₹5,000 payment is refunded, whether the ₹20 comes back depends on the processor. Ask support in writing and keep the answer.

If you receive payments through a link rather than a gateway, the UPI payment link maker generates a link and QR for a given amount and note. Ask your bank whether it classifies your VPA as personal or merchant.

What about GST on the fee?

MDR is a charge for a service. Check whether your gateway or bank invoice shows GST on its fees today. I did not open a CBIC notification for the treatment of MDR on UPI specifically, so I am not stating a rate or a rule. Check the GST line on your gateway or bank statement for the current treatment, and use the GST calculator to split an invoice into base and tax once you know what applies to you. If you claim input tax credit on payment-processing fees, your accountant will want fee invoices rather than bank narrations.

Pricing and passing the cost on

Reported rule: merchants cannot recover MDR from customers, and UPI apps cannot add platform fees.[3][4] So a "UPI surcharge" line on an invoice is exactly what the reports say is not permitted. If the fee matters to your margin, the clean way to recover it is a base-price change, not a visible add-on. At 0.4% the fee is small for most sellers: a 5% margin product gives up 8% of its margin on a payment above ₹2,000 (0.4 divided by 5). A 40% margin service barely notices.

There is also a payment-mix option. For large invoices to businesses, bank transfer (NEFT, RTGS or IMPS) avoids the UPI path entirely. Whether bank-transfer fees are lower for your amounts depends on your bank; look at your fee schedule rather than assuming. UPI is popular with customers for convenience, and pushing large payments elsewhere can cost you sales.

What is still unknown

The effective date. NPCI says "at a date to be notified separately."[1]
Whether the final rate remains "up to 0.4%", and who sets the rate within "up to" when a gateway or bank is in the chain.
Whether the ₹300 cap, the ₹5 flat fee categories and the 0.02% capital-markets rate survive unchanged into the notified rate card.
Whether the small-merchant ₹1 lakh a month tier is unchanged, and how monthly collections are counted.
How the government notification reported by LiveLaw interacts with MDR on payments above ₹2,000.
What the "select" in "select P2M transactions" covers beyond the categories already described.

Checklist before the date is notified

Export the last three months of UPI credits and tag each as P2P, P2M QR, or P2M gateway.
Total the P2M QR receipts per month and compare with ₹1 lakh.
Count the payments above ₹2,000 and multiply by 0.4% to get a worst-case monthly fee; apply the ₹300 cap to any payment of ₹75,000 and above.
Read your gateway pricing page and agreement for UPI fees, pass-through clauses and notice periods.
Decide a payment mix for invoices over, say, ₹50,000: UPI, bank transfer or both.
Ask your bank how it classifies your VPA and whether your QR is on the small-merchant tier.
Set a reminder to check NPCI's website for the notified date, and re-read this post's status line before acting.

If you want a companion read on a different UPI change affecting merchants and freelancers this autumn, the UPI privacy rules guide covers masked mobile numbers and username-based UPI IDs.

Frequently asked questions

Is UPI MDR cancelled?

No. NPCI's 13 October 2026 release says MDR on select P2M UPI transactions "shall be implemented immediately post Diwali at a date to be notified separately." It is postponed, with no new date as of 19 October 2026.[1]

Will customers be charged for UPI payments above ₹2,000?

According to the Paytm filing quoting NPCI's circular, no. The charge is on the merchant side and UPI stays free for customers.[2]

Does the 0.4% apply to money from friends and family?

The sources describe MDR as applying to P2M, not P2P. SCC Online reports P2P transfers as exempt regardless of amount.[3]

I get under ₹1 lakh a month by QR. Do I pay?

Reported as exempt if you fall in the small-merchant P2PM tier, even for single payments above ₹2,000.[4] That detail comes from news summaries of the NPCI FAQ and should be confirmed once the notified framework is published.

Can I add a UPI surcharge to my invoices?

Outlets report that merchants cannot pass MDR on to customers.[3] Treat a visible surcharge as risky and adjust base prices instead if you need to recover cost.

When should I expect the new date?

Nobody has published one. Diwali Laxmi Pujan falls on 8 November 2026,[6] and NPCI's wording points to the period straight after the festival, but treat any specific date you see in a social post as unverified until it appears on NPCI's website.

Sources

6. NSE: trading holidays 2026, Diwali Laxmi Pujan 8 November 2026 and Diwali Bali Pratipada 10 November 2026

Originally published at wowhow.cloud

How the Claude Code Team Reviews Code: A Small-Team Version

Anup Karanjkar — Sun, 18 Oct 2026 19:15:06 +0000

Anthropic reviews Claude Code with seven stacked layers, and a team of one to ten people can copy five of them this week with GitHub branch protection, a short REVIEW.md and one CI workflow. In the post Anthropic published on 15 October 2026, the share of internal PRs that passed after a single review-and-fix round rose from 65% to 78%, PRs needing five or more rounds fell from 8.9% to 1.5%, and the mean number of reviews to pass dropped from 2.08 to 1.32[1]. Claude wrote about 90 percent of Claude Code's own code, so the review system is what keeps that volume safe. The two layers you cannot copy are the risk classifier and the staged release channels at Anthropic's volume. Below: the seven layers, a mapping table, a starter REVIEW.md, a risk-tier rule of thumb, the exact GitHub settings, and the trade-offs.

TL;DR

Anthropic's layers: self-verification, AI review on every PR, blocking security review, blocking checks, risk-tiered human approval, merge queue plus flags plus staged release, fast rollback.
Reported results are internal and come without sample sizes: 65% to 78% one-round passes, 8.9% to 1.5% for five-plus rounds.
A small team can get most of the value from branch protection, a risk-tier rule by path and size, a REVIEW.md, and a rollback switch.
The hosted Code Review product is for Team and Enterprise plans, and Anthropic's docs say it never approves or blocks a PR by itself. Your CI has to do the blocking.
Everything labelled "Anthropic reported" below comes from their post. Everything labelled "my recommendation" is mine and untested at Anthropic's scale.

What Anthropic actually reported

The post describes a goal and a guardrail. The goal is that most PRs merge with at most one human in the loop. The guardrail is that reverts and incidents must not rise. Anthropic reports that from June to September, merged PRs to the Claude Code codebase more than doubled while the share that had to be reverted fell by more than 40 percent[1]. In the wider monorepo, daily landed changes went from about 2,500 in May to more than 30,000 in September.

Those are the company's own numbers. The post gives no sample sizes and nobody outside Anthropic has checked them, so treat them as a direction, not a benchmark. The useful part is the structure, which is seven layers where each one catches what the previous one missed.

The seven layers in Anthropic's words

Verify before anyone looks. Claude runs tests, builds or screenshot comparisons, and a subagent with fresh context reviews the diff.
AI review on every PR. Several agents hunt for bugs in parallel, verifiers vote on each finding, and only findings enough verifiers agree on get posted, tagged Important, Nit or Pre-existing.
Security review that can block. A PR cannot merge while any finding from the bug review or the security review is still open.
Automated checks that block. Lint, type checks, tests on every platform and a build. A typical CLI PR may run dozens of checks.
Human approval scaled by risk. More on this below.
Merge queue, flags and gradual release. The queue re-runs checks against main, new behavior ships behind flags to employees first, and public releases go to the latest channel before stable.
Fast detection and rollback. Flags turn off without a deploy, and there is a weekly on-call rotation.

How the human approvals are tiered

A classifier reads the change and picks the risk tier, so the tier follows what the change touches and not who wrote it. Low-risk changes (docs, copy, internal-only features, additive changes behind a flag) need no human once automated review and security checks are green. Medium risk (ordinary product changes plus sensitive areas such as caching, the auto-updater or system prompts) needs one person. High risk needs two. A second classifier can force a person in even when the tier would not[1].

Three rules in the post are worth copying word for word in spirit. An agent's approval never counts as a person's. On agent-written PRs, the person directing the agent counts as one of the required reviewers. And an approval covers one specific commit, so a push after approval should reset it.

Layer-by-layer: what a small team does instead

This table is my recommendation. The first two columns are Anthropic's design as reported[1]; the last three are what I think a one-to-ten person team can do and when to skip it.

Layer	Anthropic's version	Small-team version	Effort	Skip it if

| 1. Self-verification | Claude runs tests and a fresh-context subagent reviews the diff | Put "run the test command and a diff-review subagent before opening a PR" in CLAUDE.md or a custom subagent | 30 minutes | You do not use an agent to write code |

| 2. AI review on every PR | Multi-agent review with verifier voting | On Team or Enterprise, the hosted Code Review. Otherwise run /code-review locally or Claude in your own CI | 1 hour, plus usage cost | PRs are under about 20 lines and you read every one |

| 3. Blocking security review | Open findings block merge | Run /security-review or a security job in CI, and make that job a required status check | 1 to 2 hours | No auth, payments, file upload or secrets handling in the repo |

| 6. Merge queue, flags, staged release | Queue plus employee flags plus latest then stable | Merge queue if main breaks often; one feature flag for risky work; deploy to staging or a canary first | 1 day | You deploy rarely and can redeploy in minutes |

If you only do three things, do layers 4, 5 and 7. Required checks, a risk rule and a practiced rollback prevent more damage than any AI reviewer.

The small-team setup, step by step

Step 1: Write a short REVIEW.md

Anthropic says REVIEW.md is written by code owners and tells the reviewer what matters in their part of the code. The post recommends keeping it short, stating what failure looks like in your repo, capping nits, listing paths to skip, and asking for a file and line as evidence instead of a guess from a name[1]. Per the Claude Code docs, the hosted review reads REVIEW.md from the base or default branch, never from the PR's own changes[2]. That matters: a PR cannot rewrite its own reviewer's instructions.

Here is a starter I wrote for a typical web app. Edit the first section to match what breaks in your repo.

# REVIEW.md

## What failure looks like here
- Charging or refunding the wrong amount, or charging twice
- A route that returns data for a user who does not own it
- A migration that locks a large table or cannot be rolled back
- A background job that retries a non-idempotent action

## How to report
- Cite the file and line for every finding. If you cannot, drop it.
- Report at most 3 nits per PR. Prefer zero.
- Label each finding: Important, Nit, or Pre-existing.
- Do not comment on formatting. The linter owns that.

## Skip
- generated/**, **/*.snap, package-lock.json, docs/**

## Always flag
- Any change under auth/, billing/, migrations/ or .github/workflows/
- New environment variables or secrets read at runtime
- Any removed test without a replacement

Pair it with a CLAUDE.md that covers how code should be written. I covered what survives in production in CLAUDE.md rules that survive production. REVIEW.md is the reviewer's brief; CLAUDE.md is the author's.

Step 2: Add a risk-tier rule you can compute

Anthropic uses a classifier. You can get a decent first version from file paths and diff size. This is my recommendation, not Anthropic's rule, and you should tune the numbers after a month of data.

Tier	Rule of thumb	Approvals

| Low | Only docs, copy, tests or config comments; or under 30 changed lines in non-sensitive paths; checks green | 0, after green checks and a clean AI review |

| Medium | Everything else, up to about 400 changed lines | 1 person |

| High | Touches auth, billing, migrations, deploy workflows, secrets handling, or exceeds about 400 lines | 2 people, or 1 person plus the author walking through it live |

On a team of three, "2 people" may mean the author is one of the two. That is fine if you keep Anthropic's rule that the person directing an agent counts as a required reviewer, and the AI never counts as a person.

If you would rather not hand-build the tier script, the WOWHOW AI Code Review Pipeline Kit packages a REVIEW.md template, a path-and-size risk-tier classifier, a GitHub Actions approval gate and a findings parser. Everything in this post works without it.

Step 3: Set the GitHub branch protection that makes it real

A rule nobody enforces is a suggestion. In GitHub's protected-branch settings, these are the options that map to the layers[3]:

Require pull request reviews before merging, with the number of required approvals set to 1 on your default branch. GitHub's current UI may label this "Require a pull request before merging"; the page I checked uses the first wording.
Require status checks before merging, with the checkbox "Require status checks to pass before merging". Add lint, types, tests, build and your security job by name.
Require branches to be up to date before merging, so checks run against current main.
Dismiss stale pull request approvals when new commits are pushed. This is the setting that gives you Anthropic's "an approval covers one specific commit".
Require merge queue, if main breaks often enough to justify it.
Code owner review through a CODEOWNERS file for your high-risk paths, so those need a named owner.

GitHub treats rulesets as a separate feature from classic branch protection. Either route works; use one, not both, to avoid conflicting rules.

The two-approval rule for high-risk paths does not exist as a single checkbox. Branch protection applies one approval count to the whole branch. To get tiers, use CODEOWNERS for the sensitive paths, or run a small workflow that reads the changed files, computes the tier, and fails a required check until enough approvals exist. That workflow is the only custom code in this whole setup.

Step 4: Decide where the AI review runs

You have four options, and the docs list them side by side[2]:

The hosted Code Review, for organizations on Team or Enterprise plans with GitHub repositories, turned on by an Owner. Reviews run on Anthropic infrastructure and come in Quick, Standard and Deep levels.
/code-review in your own Claude Code session, on any plan.
Claude in your own CI through GitHub Actions or GitLab CI/CD, using an API key.
Your own reviewer as a subagent or skill.

One detail trips people up. Anthropic's post says its internal setup blocks merge on open findings. The public docs say the hosted review never approves or blocks a PR, and its check run does not conclude as a failure[2]. So if you want blocking findings, you build it: run a security job in CI that fails on findings, and make it a required status check. The post does not give pricing, and I am not quoting any; check the Code Review costs page before turning it on across many repos.

Step 5: Make rollback boring

Layer 7 is the one small teams skip, and the one that saves a Friday evening. Pick a rollback you can run in one command, run it once against staging this week, and write down who is on call. If you ship behind a flag, test that flipping it off actually removes the behavior. Pair this with a regression check on the model itself; WOWHOW built one for that in the 20-task eval canary, and the Model Regression Canary packages it.

Honest trade-offs

AI review is noisy until you tune it. Anthropic's own fix is verifier voting and a nit cap, which is why the REVIEW.md above caps nits at 3. Without a cap, people learn to ignore the bot within a week.

A clean review is not a safe PR. The Claude Code docs say it directly: Code Review uses AI and may miss bugs and vulnerabilities, and a review with no findings does not mean the code is error-free or secure[2]. The docs also note that a review reads the diff and surrounding code without building or running it. Your tests are still the thing that runs the code.

Zero-human tiers carry real risk. The post itself says Anthropic lacks circuit breakers that tighten approval when its numbers move. If you allow zero-approval merges for low-risk changes, keep the definition narrow and review the list of auto-merged PRs weekly.

Cost scales with PR volume. A deeper review level costs more per PR. Use Quick on routine repos and Deep only where a bug is expensive, as the docs suggest.

Your failure modes are not Anthropic's. Agent-written code fails in recognizable ways. The 14-item failure mode taxonomy is a good source for filling in the "what failure looks like here" section of your REVIEW.md.

Frequently asked questions

Is Code Review for Claude Code available on every plan?

No. The hosted Code Review is generally available on Team and Enterprise plans and works with GitHub repositories[1][2]. The local /code-review command runs in your Claude Code session on any plan.

Does the AI reviewer block merges?

The public docs say the hosted review never approves or blocks a pull request, and its check run does not conclude as a failure[2]. Anthropic's post describes its own internal setup, where open findings do block merge. To get that behavior, make your own CI job a required status check.

Can a solo developer use this?

Yes, with a smaller version. Keep required checks, a REVIEW.md, an AI review pass and a tested rollback. Skip human tiers, since you are the only human. Use the risk tier to decide how long you read the diff yourself.

Where does REVIEW.md go and who can edit it?

It lives in the repository. The hosted review reads it from the base or default branch and never from the PR under review, so a PR cannot loosen its own review rules[2].

What does it cost?

Anthropic's post gives no pricing. The docs have a separate page on Code Review costs and usage, and a deeper review level costs more than a lighter one[2]. Check that page for current numbers before enabling it widely.

Sources

3. GitHub docs: about protected branches (accessed 18 October 2026)

Originally published at wowhow.cloud