[PyTorch] Add newton_schulz_tp optimizer step function - #2920

vcherepanov-nv · 2026-04-23T19:15:38Z

Description

Add a newton_schulz_tp utility function on top of the existing newton_schulz. To be used in Muon optimizer step.

Fixes # (issue)

Type of change

Documentation change (change only to the documentation, either a fix or a new content)
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Infra/Build change
Code refactoring

Changes

Please list the changes introduced in this PR:

Add a newton_schulz_tp function
refactor test_newton_schulz.py to do multiple check during a single torchrun

Checklist:

I have read and followed the contributing guidelines
The functionality is complete
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

for more information, see https://pre-commit.ci

greptile-apps · 2026-04-23T19:21:00Z

Greptile Summary

The PR adds tensor-parallel Newton–Schulz orthogonalization and restores compatibility for the former module path.

Supports replicated, row-partitioned, and column-partitioned tensors.
Moves the implementation under the optimizer package while retaining a legacy import shim.
Consolidates distributed numerical coverage into single- and multi-GPU worker runs.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
transformer_engine/pytorch/optimizers/newton_schulz.py	Adds the tensor-parallel wrapper, process-group accessor, replicated gather path, and row/column partition handling without an eligible blocking follow-up issue.
transformer_engine/pytorch/newton_schulz.py	Restores the legacy module path through a public-symbol re-export shim.
transformer_engine/pytorch/init.py	Exposes the new tensor-parallel function from the optimizer implementation.
tests/pytorch/distributed/run_newton_schulz.py	Consolidates distributed numerical cases and adds coverage for tensor-parallel modes and replicated inputs.
tests/pytorch/distributed/test_newton_schulz.py	Launches consolidated one- and multi-GPU worker runs through the active Python interpreter.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A["newton_schulz_tp(x, partition_dim, tp_mode)"] --> B{"Replicated input?"}
  B -- Yes --> C["Shard larger dimension"]
  B -- No --> D{"Duplicated mode?"}
  D -- Yes --> E["Gather full tensor"]
  D -- No --> F{"Row partition?"}
  F -- Yes --> G["Transpose local shard"]
  F -- No --> H["Use column shard directly"]
  C --> I["Distributed Newton–Schulz kernel"]
  E --> I
  G --> I
  H --> I
  I --> J["Gather/transpose/slice as needed"]
  J --> K["Copy result into x"]

_{Reviews (9): Last reviewed commit: "[pre-commit.ci] auto fixes from pre-comm..." | Re-trigger Greptile}

greptile-apps · 2026-04-23T19:21:04Z

+    def step(self, closure=None):
+        """Perform a single optimization step."""
+        loss = None
+        if closure is not None:
+            loss = closure()
+


Closure called inside @torch.no_grad(), preventing gradient computation

closure() is invoked while torch.no_grad() is active. Any loss.backward() call inside the closure will silently produce zero/no gradients. The standard PyTorch pattern (used in SGD, Adam, etc.) is to wrap the closure in with torch.enable_grad():.

Suggested change

def step(self, closure=None):

"""Perform a single optimization step."""

loss = None

if closure is not None:

loss = closure()

@torch.no_grad()

def step(self, closure=None):

"""Perform a single optimization step."""

loss = None

if closure is not None:

with torch.enable_grad():

loss = closure()

greptile-apps · 2026-04-23T19:21:04Z

+    scale_mode: str,
+    extra_scale_factor: float,
+    eps: float,
+) -> torch.Tensor:
+    global_shape = [grad.size(0), grad.size(1)]
+    global_shape[partition_dim] *= world_size


Reference global_shape incorrectly scales an already-full tensor

_reference_orthogonalize receives the full matrix (shape full_shape) but then multiplies global_shape[partition_dim] by world_size a second time. For partition_dim=1 with world_size=2 and full_shape=(96, 128) this gives global_shape=[96, 256], so get_muon_scale_factor returns max(96,256)^0.5 = 16. The optimizer, operating on the shard (96, 64), correctly reconstructs global_shape=[96, 128] and computes max(96,128)^0.5 ≈ 11.3. This √2 discrepancy means the reference cannot correctly validate the optimizer's output.

The global_shape[partition_dim] *= world_size line should be removed since the input is already the full matrix.

greptile-apps · 2026-04-23T19:21:06Z

+    if mode == "unit_rms_norm":
+        return (size_out / size_in) ** 0.5


unit_rms_norm mode can divide by zero when size_in == 0

(size_out / size_in) ** 0.5 raises ZeroDivisionError when size_in is 0. While the optimizer validates that the partition dimension is non-empty, it doesn't ensure the other dimension is non-zero. Consider adding a guard or documenting that both dimensions must be strictly positive.

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

skyw

I'd advice NOT to expose it in public API. Keeping it in test only if that is the purpose.

Having an optimizer with most code copied invites fragmentation.

Before this, all optimizer TE provides are more optimized fused version. I'd say a highly optimized Fused Muon with similar concept can be justified, but would need more consideration because it has more dependencies on other part of the training pipeline than elementwise optimizers.

skyw · 2026-04-27T20:33:43Z

+    on tensor-parallel parameter shards. The local parameter shard must represent a
+    partition of a logical 2D matrix across the provided NCCL process group.
+
+    Args:


Q: Does TE use numpy style docstring instead of Google style?

skyw · 2026-04-27T20:34:33Z

+
+    def __init__(
+        self,
+        params: Iterable[torch.nn.Parameter | dict],


Nit: The type here doesn't match PyTorch internal. Should be fine for the purpose of this class.

skyw · 2026-04-27T20:35:30Z

+        scale_mode: MuonScaleT = "spectral",
+        extra_scale_factor: float = 1.0,
+        process_group: Optional[dist.ProcessGroup] = None,
+        partition_dim: int = 1,


Fix: partition_dim is per parameter.

skyw · 2026-04-27T20:36:28Z

+            raise ValueError(f"Invalid weight_decay value: {weight_decay}")
+        if num_ns_steps < 1:
+            raise ValueError(f"num_ns_steps must be at least 1, got {num_ns_steps}")
+        if partition_dim not in (0, 1):


Q: Does this class intend to support non-distributed case? partition_dim would be -1 in TE in such case.

skyw · 2026-04-27T20:37:09Z

+
+        if process_group is None:
+            if not dist.is_initialized():
+                raise RuntimeError("MuonOptimizer requires torch.distributed to be initialized.")


Same question above regarding single GPU support.

skyw · 2026-04-27T20:39:01Z

+        if process_group is None:
+            if not dist.is_initialized():
+                raise RuntimeError("MuonOptimizer requires torch.distributed to be initialized.")
+            process_group = dist.group.WORLD


Suggestion: This silent behavior is dangerous. If user forgot to pass the correct TP group, wrong group will be used.

skyw · 2026-04-27T20:43:42Z

+        global_shape[partition_dim] *= world_size
+
+        orth_grad = grad.clone()
+        transposed = partition_dim == 0


Attn: This is from common Row and Column wise tensor parallelism in most LLM. It would be sub optimal for anything other than that. Add comment if the assumption is made.

vcherepanov-nv · 2026-04-28T19:02:52Z

Having an optimizer with most code copied invites fragmentation.

The idea was to give something to users, who use TE, but not Megatron-LM. By fragmentation you mean that we want to encourage everyone to use Megatron-LM? Or that the optimizer being relatively thin thing on top of newton_schulz call, and the users should have no trouble creating it themselves?

I don't think we gain anything by putting it into tests, since we already have tests for newton_schulz call. So we need to decide whether we want this PR, or should abandon it altogether. @cyanguwa

skyw · 2026-04-28T21:15:03Z

Having an optimizer with most code copied invites fragmentation.

The idea was to give something to users, who use TE, but not Megatron-LM. By fragmentation you mean that we want to encourage everyone to use Megatron-LM? Or that the optimizer being relatively thin thing on top of newton_schulz call, and the users should have no trouble creating it themselves?

I don't think we gain anything by putting it into tests, since we already have tests for newton_schulz call. So we need to decide whether we want this PR, or should abandon it altogether. @cyanguwa

Fragmentation means there will be different flavor of muon in emerging optimizer and TE, also a lot of copied code. TE can have stalled feature when emerging optimizer updates. Megatron-LM will always have its own version because there are implementation specific things need to be hooked together. For example, how QKV is implemetned, or fused swighlu.
For TE, I think an example of how to build a version of emerging optimizer use TE NS backend would be good to have. But providing optimizer (not fusion optimized version) confuses customers.
Having said that, I would love for TE to have a more optimized version. similar idea as fusedAdam, etc.

cyanguwa · 2026-04-30T19:14:56Z

Should we move newton_schulz.py to this directory? Also, how do we expect Megatron to call us for this functionality? Thanks.

Should we move newton_schulz.py to this directory?

No, don't think so.

Should we move newton_schulz.py to this directory?

Megatron will call newton_shulz directly from their optimizers. This one is for other users.

I'd prefer moving them into something like transformer_engine/pytorch/cusolver. But I suppose that is orthogonal to this PR.

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

for more information, see https://pre-commit.ci

cyanguwa · 2026-05-04T22:15:58Z

run CI here "/te-ci torch L1"; add tests to qa/Lx_pytorch_unittest/test.sh?
please create newton_schulz_tp API to include partition_dim/mode params, and for Megatron integration
please test non-distributed cases (per comment above)
please move newton_schulz.py to te/pytorch/optimizers; if we have more solvers to integrate to TE or more use cases of Newton-Schulz, we can definitely restructure the code, but we don't see that in the near future

cyanguwa · 2026-05-04T22:44:04Z

@skyw Just following up on the discussion above - our purpose for this PR was two-fold. One was to provide an equivalent newton_schulz_tp API for Megatron; the other one was to provide a dialed-down version of Muon Optimizer class so direct TE users can access the Newton-Schulz solver. I understand this may cause divergence in TE and Megatron's Muon support, but we do want to expose this feature to direct users of TE as well. Hope that helps. Thanks.

timmoon10 · 2026-05-04T23:01:59Z

I'd prefer moving them into something like transformer_engine/pytorch/cusolver. But I suppose that is orthogonal to this PR.

timmoon10 · 2026-05-04T23:03:14Z

We should make sure to include this in the QA script: https://github.com/NVIDIA/TransformerEngine/blob/main/qa/L1_pytorch_distributed_unittest/test.sh

timmoon10 · 2026-05-04T23:08:33Z

+LAUNCH_CMD = ["torchrun", f"--nproc_per_node={NUM_PROCS}"]
+
+
+def _run_test(dtype: str, partition_dim: int, weight_decay_mode: str) -> None:


Each torchrun launch is somewhat expensive. Instead of launching a separate torchrun for each test case, it's better to launch a single torchrun instance and to perform multiple tests internally. See distributed/test_fusible_ops.py for an example.

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

for more information, see https://pre-commit.ci

skyw · 2026-05-05T03:15:27Z

@skyw Just following up on the discussion above - our purpose for this PR was two-fold. One was to provide an equivalent newton_schulz_tp API for Megatron; the other one was to provide a dialed-down version of Muon Optimizer class so direct TE users can access the Newton-Schulz solver. I understand this may cause divergence in TE and Megatron's Muon support, but we do want to expose this feature to direct users of TE as well. Hope that helps. Thanks.

Megatron is wrapped over emgering-optimizers with megatron specific details, like TP and how QKV are organized. The most optimizer logic is in emerging-optimizers. Could TE do the same? I understand introducing a new dependency may have concern, let me know. The biggest concern is actually large portion of duplicated code.

What I would favor is having newton_schulz_tp in one release, test it out. and have a well optimized version of Muon optimizer class in the next. There are a lot of optimizations (fusion, batch, graph capturability etc.) that can and I believe should go into TE.

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

for more information, see https://pre-commit.ci

cyanguwa · 2026-06-01T12:09:09Z

+    partition_dim: Optional[int] = None,
+    tp_mode: Literal["duplicated", "distributed"] = "duplicated",
+) -> None:
+    """Compute tensor-parallel Newton-Schulz orthogonalization in-place.


Is there some requirement for the operation to be in-place? I see we are doing a few x.copy_()s in the code and was just wondering if it's necessary.

Yes, it's intentional

cyanguwa · 2026-06-01T12:13:17Z

+    ctx : CusolverMpCtx
+        cuSolverMp context created for the tensor-parallel process group.
+    num_iterations : int, optional
+        Number of Newton-Schulz iterations. Default: 5.


Should this be optional, or mandatory? Shouldn't users always be specifying the exact number of iterations they want to run NS with? Otherwise, they might get successful runs but incorrect results silently?

cyanguwa · 2026-06-01T12:33:07Z

+
+    output_shards = [torch.empty_like(local_work) for _ in range(ctx.nranks)]
+    dist.all_gather(output_shards, local_work, group=ctx.group)
+    output = torch.cat(output_shards, dim=1)


I feel the functionality of _orthogonalize_replicated() is a bit odd. In the case of partition_dim is None, we probably don't need any chunking or all-gathering, given that tensor x is local, non-distributed. In the case of tp_mode == "duplicated", we seem to be all-gathering, chunking, and then all-gathering again - is this necessary? Looking at emerging-optimizers, it seems to be all lowering down to a simple newton_schulz() call?

It's necessary for this cuSolverMp. cuSolverMp interprets each rank’s input as a column shard; the wrapper must shard replicated inputs before the call and gather the distributed result afterward. Emerging-Optimizers can avoid this only because its local PyTorch implementation is different.

cyanguwa · 2026-06-01T12:47:49Z

+            tp_mode=tp_mode,
+        )
+    else:
+        newton_schulz(x_local, ctx, num_iterations, coefficients=coefficients)


Non-TP is a special case of TP, right? So we probably can just call newton_schulz_tp() here regardless of whether api == "tp"? We just need to set up partition_dim and tp_mode properly for the non-TP case?

I think it makes sense to test both APIs, even if they end up running the same thing internally.

cyanguwa · 2026-06-01T13:09:53Z

+        return (5e-2, 5e-2)
+    if check == "orthogonality" and world_size == 1:
+        return (2e-2, 2e-2)
+    return (1e-2, 1e-2)


Are the tolerances set a bit high? Usually we have 1e-2 for BF16 and even smaller for FP32. Could you do a bit of research and tighten them up if necessary? A couple of reference points are:

https://github.com/NVIDIA-NeMo/Emerging-Optimizers/blob/main/tests/test_muon_utils.py
https://github.com/vcherepanov-nv/TransformerEngine/blob/3c4dfffb788f01009bf6741d25d4b69078e95d13/tests/pytorch/test_permutation.py#L192

timmoon10 · 2026-06-03T17:08:12Z

Are we committing to only supporting Newton-Shulz, and to only use it for Muon? It would be more general to put this code in a transformer_engine.pytorch.cusolvermp submodule.

I think in principle that's a good idea, but if there's realistically no other use case of it in TE, it might be better to simplify the file structure?

Could you check if there are other optimizers in Emerging-Optimizers that could be using cusolvermp?

timmoon10 · 2026-06-03T17:15:22Z

+            tp_mode=tp_mode,
+        )
+    else:
+        newton_schulz(x_local, ctx, num_iterations, coefficients=coefficients)


I think it makes sense to test both APIs, even if they end up running the same thing internally.

# Conflicts: # tests/pytorch/distributed/run_newton_schulz.py # transformer_engine/pytorch/optimizers/newton_schulz.py

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

for more information, see https://pre-commit.ci

cyanguwa

Looks like the CI is clean as well. Thanks!

* Add distributed Muon optimizer Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Fix Muon closure and reference test Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * Fix Muon optimizer distributed API handling Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * Fix Muon optimizer docs and params typing Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Add tensor-parallel Newton-Schulz wrapper Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * Move Newton-Schulz wrapper into optimizers Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * Use tensor-parallel Newton-Schulz in Muon Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Limit Muon branch to Newton-Schulz TP Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * Run Newton-Schulz distributed cases in one launch Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * Add single-GPU Newton-Schulz coverage Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Fix Newton-Schulz compatibility and replicated coverage Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --------- Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> (cherry picked from commit 5df5a0d)

vcherepanov-nv and others added 2 commits April 23, 2026 18:50

Add distributed Muon optimizer

a2df6f8

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks

e332a8e

for more information, see https://pre-commit.ci

greptile-apps Bot reviewed Apr 23, 2026

View reviewed changes

Fix Muon closure and reference test

1304712

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

vcherepanov-nv changed the title ~~[Draft] [PyTorch] Add distributed Muon optimizer~~ [PyTorch] Add distributed Muon optimizer Apr 27, 2026

vcherepanov-nv requested a review from cyanguwa April 27, 2026 18:12

vcherepanov-nv added the 2.16.0 label Apr 27, 2026

vcherepanov-nv requested a review from timmoon10 April 27, 2026 18:13

skyw reviewed Apr 27, 2026

View reviewed changes

cyanguwa reviewed Apr 30, 2026

View reviewed changes

vcherepanov-nv and others added 3 commits May 1, 2026 07:27

Fix Muon optimizer distributed API handling

958923d

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

Fix Muon optimizer docs and params typing

860d6a7

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks

037375c

for more information, see https://pre-commit.ci

timmoon10 reviewed May 4, 2026

View reviewed changes

vcherepanov-nv and others added 4 commits May 4, 2026 23:21

Add tensor-parallel Newton-Schulz wrapper

6d043e3

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

Move Newton-Schulz wrapper into optimizers

e9758a3

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

Use tensor-parallel Newton-Schulz in Muon

d7597b6

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks

47a02d0

for more information, see https://pre-commit.ci

Limit Muon branch to Newton-Schulz TP

daaa8a6

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

vcherepanov-nv requested a review from ksivaman as a code owner May 18, 2026 19:51

Run Newton-Schulz distributed cases in one launch

610d12d

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

vcherepanov-nv changed the title ~~[PyTorch] Add distributed Muon optimizer~~ [PyTorch] Add newton_schulz_tp optimizer step function May 18, 2026

vcherepanov-nv and others added 2 commits May 18, 2026 22:48

Add single-GPU Newton-Schulz coverage

e961ee0

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks

da27cd5

for more information, see https://pre-commit.ci

vcherepanov-nv added 2.17 and removed 2.16.0 labels May 27, 2026

cyanguwa reviewed Jun 1, 2026

View reviewed changes

cyanguwa requested changes Jun 1, 2026

View reviewed changes

timmoon10 reviewed Jun 3, 2026

View reviewed changes

KshitijLakhani added 2.18 and removed 2.17 labels Jun 25, 2026

vcherepanov-nv added 2.19 and removed 2.18 labels Jul 30, 2026

vcherepanov-nv and others added 3 commits August 21, 2026 20:39

Merge branch 'main' into muon

b4c74ae

# Conflicts: # tests/pytorch/distributed/run_newton_schulz.py # transformer_engine/pytorch/optimizers/newton_schulz.py

Fix Newton-Schulz compatibility and replicated coverage

e5ce647

Signed-off-by: Vladimir Cherepanov <vcherepanov@nvidia.com>

[pre-commit.ci] auto fixes from pre-commit.com hooks

9ff8f6b

for more information, see https://pre-commit.ci

cyanguwa approved these changes Aug 25, 2026

View reviewed changes

vcherepanov-nv merged commit 5df5a0d into NVIDIA:main Aug 25, 2026
12 of 16 checks passed

		if mode == "unit_rms_norm":
		return (size_out / size_in) ** 0.5

		LAUNCH_CMD = ["torchrun", f"--nproc_per_node={NUM_PROCS}"]


		def _run_test(dtype: str, partition_dim: int, weight_decay_mode: str) -> None:

Conversation

vcherepanov-nv commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of change

Changes

Checklist:

Uh oh!

greptile-apps Bot commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Flowchart

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

skyw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vcherepanov-nv commented Apr 28, 2026

Uh oh!

skyw commented Apr 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cyanguwa commented May 4, 2026

Uh oh!

cyanguwa commented May 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skyw commented May 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cyanguwa Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

vcherepanov-nv commented Apr 23, 2026 •

edited

Loading

greptile-apps Bot commented Apr 23, 2026 •

edited

Loading

cyanguwa Jun 1, 2026 •

edited

Loading