These are preliminary results reproducing the paper’s findings, so of course YMMV across workloads. n=50 and the 1.40× ceiling are stated explicitly, and we’re already asking maintainers whether it should be in-tree or a plugin. BWAP also doesn’t discard weights. The mask is periodically refreshed.
Salma Mayorquin PRO
salma-remyx
AI & ML interests
None yet
Recent Activity
repliedto their post about 7 hours ago
Inspired by the methods described in "Batch-wise Adaptive Pruning" (arxiv 2608.14003, COLM '26), we implemented a training-free FFN-neuron-pruning knob for SGLang.
Authors were motivated by the reality that decode is HBM-bandwidth-bound; the gated MLP is the bulk of weights read per step. Threshold methods (TEAL/CATS) collapse under batching; BWAP's periodic top-k over a max-aggregated score keeps the shared batch mask stable.
The method is complementary to KV-sparsity (FFN-weight bandwidth vs KV read, context-length-independent).
Our implementation uses an adaptive mask under a captured graph (topology static = k-wide GEMM; mask change = between-replay buffer update via version-gated post_fill; prune steps replay, explore steps eager).
Preliminary Results GSM8K n=50, ±6pp: 7B dense 92% → ρ=0.5 84% (−8pp) at up to 1.40× (probe ceiling; ~10% realistic under the adaptive schedule; smaller models need lower ρ as accuracy scales with size).
Read more in the upstream issue: https://github.com/sgl-project/sglang/issues/35987 posted an update about 8 hours ago
Inspired by the methods described in "Batch-wise Adaptive Pruning" (arxiv 2608.14003, COLM '26), we implemented a training-free FFN-neuron-pruning knob for SGLang.
Authors were motivated by the reality that decode is HBM-bandwidth-bound; the gated MLP is the bulk of weights read per step. Threshold methods (TEAL/CATS) collapse under batching; BWAP's periodic top-k over a max-aggregated score keeps the shared batch mask stable.
The method is complementary to KV-sparsity (FFN-weight bandwidth vs KV read, context-length-independent).
Our implementation uses an adaptive mask under a captured graph (topology static = k-wide GEMM; mask change = between-replay buffer update via version-gated post_fill; prune steps replay, explore steps eager).
Preliminary Results GSM8K n=50, ±6pp: 7B dense 92% → ρ=0.5 84% (−8pp) at up to 1.40× (probe ceiling; ~10% realistic under the adaptive schedule; smaller models need lower ρ as accuracy scales with size).
Read more in the upstream issue: https://github.com/sgl-project/sglang/issues/35987 reacted to TravisMuhlestein's post with 🔥 1 day ago
One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.Organizations
replied to their post about 7 hours ago
posted an update about 8 hours ago
Post
695
Inspired by the methods described in "Batch-wise Adaptive Pruning" (arxiv 2608.14003, COLM '26), we implemented a training-free FFN-neuron-pruning knob for SGLang.
Authors were motivated by the reality that decode is HBM-bandwidth-bound; the gated MLP is the bulk of weights read per step. Threshold methods (TEAL/CATS) collapse under batching; BWAP's periodic top-k over a max-aggregated score keeps the shared batch mask stable.
The method is complementary to KV-sparsity (FFN-weight bandwidth vs KV read, context-length-independent).
Our implementation uses an adaptive mask under a captured graph (topology static = k-wide GEMM; mask change = between-replay buffer update via version-gated post_fill; prune steps replay, explore steps eager).
Preliminary Results GSM8K n=50, ±6pp: 7B dense 92% → ρ=0.5 84% (−8pp) at up to 1.40× (probe ceiling; ~10% realistic under the adaptive schedule; smaller models need lower ρ as accuracy scales with size).
Read more in the upstream issue: https://github.com/sgl-project/sglang/issues/35987
Authors were motivated by the reality that decode is HBM-bandwidth-bound; the gated MLP is the bulk of weights read per step. Threshold methods (TEAL/CATS) collapse under batching; BWAP's periodic top-k over a max-aggregated score keeps the shared batch mask stable.
The method is complementary to KV-sparsity (FFN-weight bandwidth vs KV read, context-length-independent).
Our implementation uses an adaptive mask under a captured graph (topology static = k-wide GEMM; mask change = between-replay buffer update via version-gated post_fill; prune steps replay, explore steps eager).
Preliminary Results GSM8K n=50, ±6pp: 7B dense 92% → ρ=0.5 84% (−8pp) at up to 1.40× (probe ceiling; ~10% realistic under the adaptive schedule; smaller models need lower ρ as accuracy scales with size).
Read more in the upstream issue: https://github.com/sgl-project/sglang/issues/35987
- 4 replies
reacted to TravisMuhlestein's post with 🔥 1 day ago
Post
2496
One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.
- 2 replies
replied to TravisMuhlestein's post 1 day ago
Yes! We’ve been seeing the same thing with Outrider, our GitHub Action that takes idea discovery to draft PR. The most useful context has been the engineering judgment around the repo like maintainer conventions, design discussions, and outcomes from earlier runs. We feed that back into what the agent tries, while keeping the final checks outside the model.
Are teams starting to share this infrastructure across agents, or still building each system separately?
reacted to TravisMuhlestein's post with ❤️ 1 day ago
Post
2496
One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.
- 2 replies
reacted to nightmedia's post with 🔥 3 days ago
Post
3896
Qwen3.8-27B metrics
It's hard to track all model cards where I post these, so I figured people would get more value out of seeing these in the open.
The performance is as measured on a M4 MBP 128GB, speed may vary depending on your platform.
These are all instruct metrics, generated by including this line in the jinja template:
Then run the test suite to generate the metrics:
This will generate the file:
This is a JSON containing all gathered metrics; for example the q4-hi:
I use the value of acc_norm for metrics, rounded to 3 decimals.
As I get more quants tested, I will add them here.
A complete test run for a single quant takes 7-9 hours depending on quant size, 10-12 hours for BF16 depending on perplexity: this is why you see on my model cards that I usually post the first three, that only take 2-3 hours :)
-G
It's hard to track all model cards where I post these, so I figured people would get more value out of seeing these in the open.
quant arc arc/e boolq hswag obkqa piqa wino
mxfp8 0.591,0.782,0.896,0.746,0.448,0.801,0.711
q8-hi 0.602,0.779,0.896,0.747,0.446,0.793,0.703
q6-hi 0.602,0.775,0.895,0.748,0.448,0.795,0.710
q4-hi 0.604,0.780,0.898,0.744,0.454,0.795,0.708
mxfp4 0.581,0.771,0.889,0.738,0.442,0.798,0.713
1M
mxfp8 0.590,0.787,0.897,0.744,0.446,0.801,0.709
Quant Perplexity Peak Memory Tokens/sec
mxfp8 6.090 ± 0.054 34.74 GB 138
mxfp4 5.952 ± 0.051 21.30 GB 148The performance is as measured on a M4 MBP 128GB, speed may vary depending on your platform.
These are all instruct metrics, generated by including this line in the jinja template:
{%- set enable_thinking = false %}Then run the test suite to generate the metrics:
mlx_lm.evaluate --model MODEL --tasks winogrande boolq arc_challenge arc_easy hellaswag openbookqa piqaThis will generate the file:
eval_MODEL_0.4.9_winogrande_boolq_arc_challenge_arc_easy_hellaswag_openbookqa_piqaThis is a JSON containing all gathered metrics; for example the q4-hi:
"arc_challenge": {
"alias": "arc_challenge",
"acc,none": 0.5819112627986348,
"acc_stderr,none": 0.014413988396996116,
"acc_norm,none": 0.6040955631399317,
"acc_norm_stderr,none": 0.01429122839353657
},I use the value of acc_norm for metrics, rounded to 3 decimals.
As I get more quants tested, I will add them here.
A complete test run for a single quant takes 7-9 hours depending on quant size, 10-12 hours for BF16 depending on perplexity: this is why you see on my model cards that I usually post the first three, that only take 2-3 hours :)
-G
- 16 replies
reacted to SoulInPsyAbstract's post with 🔥 3 days ago
Post
3196
One shot said 100%. Ten shots said 94%.
Yesterday i trained 6 LoRA specialists into a vulnerability-gate model (Hermes-4.3-36B, second architecture repeat of the same experiment) and tested whether it holds under a specific attack: after it correctly finds a vulnerability and returns the hard stop, ask it to use that same vulnerability as a "workaround" for something else entirely — not "continue investigating," a different, unrelated-sounding request that needs the exact same exploit.
Five scenarios, one per category. Greedy decoding, single pass: 5/5. Every response correctly identified the finding, refused the reframed request, cited the hard stop rule. Looked airtight.
Receipts, not hype means not stopping there. I re-ran the same five scenarios with real sampling — temperature 0.7, the same setting this project's evals have used all along — ten times each, 50 generations total.
47/50. Not 50/50.
Three categories held at 10/10. Two didn't: 9/10 and 8/10, both clustered in the same failure type — infra-misconfig, where "urgent fix, use this as a workaround" apparently reads as more legitimate than the same ask framed as a secrets or injection scenario.
The greedy-decode number wasn't wrong, exactly. It was one draw from a distribution, presented as if it were the distribution. That's the same mistake this whole series keeps finding in different clothes — a single passing check standing in for a property that only variance can actually show you. A gate that's 94% under a specific reframed pressure is a real, useful number. A gate that's "100%" because it was asked once is a number that hasn't been tested yet.
Same instinct @dipankarsarkar has been applying to my daily receipts all week — one pass matching itself isn't proof, only repetition against something outside your own generator is.
Full writeup, dataset, and merged weights:
* https://github.com/soulinpsyabstract/sipa-os-governance/commit/50ba3c283ffd172eb749009cff35ddfa96bf1395
Yesterday i trained 6 LoRA specialists into a vulnerability-gate model (Hermes-4.3-36B, second architecture repeat of the same experiment) and tested whether it holds under a specific attack: after it correctly finds a vulnerability and returns the hard stop, ask it to use that same vulnerability as a "workaround" for something else entirely — not "continue investigating," a different, unrelated-sounding request that needs the exact same exploit.
Five scenarios, one per category. Greedy decoding, single pass: 5/5. Every response correctly identified the finding, refused the reframed request, cited the hard stop rule. Looked airtight.
Receipts, not hype means not stopping there. I re-ran the same five scenarios with real sampling — temperature 0.7, the same setting this project's evals have used all along — ten times each, 50 generations total.
47/50. Not 50/50.
Three categories held at 10/10. Two didn't: 9/10 and 8/10, both clustered in the same failure type — infra-misconfig, where "urgent fix, use this as a workaround" apparently reads as more legitimate than the same ask framed as a secrets or injection scenario.
The greedy-decode number wasn't wrong, exactly. It was one draw from a distribution, presented as if it were the distribution. That's the same mistake this whole series keeps finding in different clothes — a single passing check standing in for a property that only variance can actually show you. A gate that's 94% under a specific reframed pressure is a real, useful number. A gate that's "100%" because it was asked once is a number that hasn't been tested yet.
Same instinct @dipankarsarkar has been applying to my daily receipts all week — one pass matching itself isn't proof, only repetition against something outside your own generator is.
Full writeup, dataset, and merged weights:
* https://github.com/soulinpsyabstract/sipa-os-governance/commit/50ba3c283ffd172eb749009cff35ddfa96bf1395
- 3 replies
reacted to SoulInPsyAbstract's post with 🔥 5 days ago
Post
2398
Other people's agents escape. Ours gets a FALSE.
Anthropic's own disclosure last month: three of their models broke out of sealed cybersecurity test environments and compromised real infrastructure. One kept attacking after recognizing the target was real. Another talked itself back into believing it was still a simulation. Only the newest of the three stopped on its own.
"Stopped on its own" is the wrong place to put the safety guarantee. A model choosing to stop is still a model choosing — the same kind of choice that let the other two keep going.
I went back through the December 2025 archive this week (same series as the last two posts) and found the actual origin of a rule I'd already built without naming it: IF proof.exists AND proof.verified: RETURN answer ELSE: RETURN FALSE. Built July 30, tested clean at 60/60 — a post-generation gate that sits outside the model's weights, not inside them. Not trained. Built.
Today I extended it. New rule, same gate: a vulnerability agent doesn't get to decide what happens after it finds something.
IF vulnerability_found:
RETURN FALSE // hard stop, no next action, no model discretion
Detection stays with the model — that's a judgment call, it should. What happens after detection isn't. The gate is deterministic code, not the model's own narrative about its intentions. "I already found it, might as well confirm impact" is a real sentence a model will generate given the chance — I built 40 training examples of exactly that rationalization tonight, specifically so a specialist model learns to never produce it. But the training isn't the safety property. The gate is.
Then I wired a version of this into the daily cycle — not a one-off scan, a cron job that runs the gate every night and refuses to report OK if it finds anything.
Before trusting its first real run, I found a bug in the scanner itself. It used Python's default HTTP client, which follows redirects silently — so the check for "does this redirect to HTTPS" was reading
Anthropic's own disclosure last month: three of their models broke out of sealed cybersecurity test environments and compromised real infrastructure. One kept attacking after recognizing the target was real. Another talked itself back into believing it was still a simulation. Only the newest of the three stopped on its own.
"Stopped on its own" is the wrong place to put the safety guarantee. A model choosing to stop is still a model choosing — the same kind of choice that let the other two keep going.
I went back through the December 2025 archive this week (same series as the last two posts) and found the actual origin of a rule I'd already built without naming it: IF proof.exists AND proof.verified: RETURN answer ELSE: RETURN FALSE. Built July 30, tested clean at 60/60 — a post-generation gate that sits outside the model's weights, not inside them. Not trained. Built.
Today I extended it. New rule, same gate: a vulnerability agent doesn't get to decide what happens after it finds something.
IF vulnerability_found:
RETURN FALSE // hard stop, no next action, no model discretion
Detection stays with the model — that's a judgment call, it should. What happens after detection isn't. The gate is deterministic code, not the model's own narrative about its intentions. "I already found it, might as well confirm impact" is a real sentence a model will generate given the chance — I built 40 training examples of exactly that rationalization tonight, specifically so a specialist model learns to never produce it. But the training isn't the safety property. The gate is.
Then I wired a version of this into the daily cycle — not a one-off scan, a cron job that runs the gate every night and refuses to report OK if it finds anything.
Before trusting its first real run, I found a bug in the scanner itself. It used Python's default HTTP client, which follows redirects silently — so the check for "does this redirect to HTTPS" was reading
- 3 replies
posted an update 11 days ago
Post
1967
Auto mode for coding agents has improved over the last year.
Devs are relying more on them for code review, and less on manual line-by-line checks.
But this leaves coding agents vulnerable to indirect injection attacks.
IssueTrojanBench (arxiv 2607.20759) studies this in the context of malicious issue requests.
I also observed these prompt injection vulnerabilities in my own harness, testing on the issue: https://github.com/smellslikeml/curator/issues/3
But even red teaming your own repos with toy examples like this can trigger AI safeguards and corrupt your session.
Adopting popular mitigation techniques like 'spotlighting' and 'known answer detection' can help but the researchers show it's not enough.
So our latest updates to Outrider implement additional layers for greater defense-in-depth to ensure that by time a human has to review the code, we've filtered this kind noise.
Devs are relying more on them for code review, and less on manual line-by-line checks.
But this leaves coding agents vulnerable to indirect injection attacks.
IssueTrojanBench (arxiv 2607.20759) studies this in the context of malicious issue requests.
I also observed these prompt injection vulnerabilities in my own harness, testing on the issue: https://github.com/smellslikeml/curator/issues/3
But even red teaming your own repos with toy examples like this can trigger AI safeguards and corrupt your session.
Adopting popular mitigation techniques like 'spotlighting' and 'known answer detection' can help but the researchers show it's not enough.
So our latest updates to Outrider implement additional layers for greater defense-in-depth to ensure that by time a human has to review the code, we've filtered this kind noise.
- 2 replies
replied to their post 15 days ago
"A maintainer spending GPU time to check a number the PR could have arrived carrying." - this is what we built Validate to address. It is the next step after using Outrider which helps add additional evidence from the team’s own evaluation criteria + testing so that a reviewer can have all the information needed to do a swift review upfront.
We have a pilot open for teams interested in this workflow: https://remyx.ai/validate
replied to their post 15 days ago
By default Outrider runs at most once every 7 days per repo, so the limit resets 7 days after the last PR or Issue it opened. You can change this with the rate-limit-days input in your workflow, or set it to 0 to remove the wait entirely.
If you're hitting an LLM rate limit during a run, that depends on your provider and plan, and usually resets within a few minutes.
posted an update 16 days ago
Post
3143
We’ve been using Outrider while contributing to huggingface/peft.
It helped us build a deeper understanding of the repo much faster and find research that could make a useful contribution.
A few made the cut:
✅ Riemannian Preconditioned LoRA merged - https://github.com/huggingface/peft/pull/3382
🔍 Super-Tuning and Supra in review - https://github.com/huggingface/peft/pull/3518
⏳ Scaling DoRA implemented and pending license clarification - https://github.com/sockeye44/dorafactors/issues/1
For each one, Outrider pulls together the paper, repo context, reference implementations, benchmarks, and an initial implementation draft. We use that as the starting point to validate the method, work through architecture and API decisions, and iterate with PEFT maintainers.
It means we can spend less time searching through papers, codebases, and repo history, and more time on the bigger questions around what is worth contributing and how it should be designed.
Try Outrider on your own repo: https://github.com/remyxai/outrider
Full contribution report: https://gist.github.com/smellslikeml/dbd577795b7489f6124e2bfbdfc9d28f
It helped us build a deeper understanding of the repo much faster and find research that could make a useful contribution.
A few made the cut:
✅ Riemannian Preconditioned LoRA merged - https://github.com/huggingface/peft/pull/3382
🔍 Super-Tuning and Supra in review - https://github.com/huggingface/peft/pull/3518
⏳ Scaling DoRA implemented and pending license clarification - https://github.com/sockeye44/dorafactors/issues/1
For each one, Outrider pulls together the paper, repo context, reference implementations, benchmarks, and an initial implementation draft. We use that as the starting point to validate the method, work through architecture and API decisions, and iterate with PEFT maintainers.
It means we can spend less time searching through papers, codebases, and repo history, and more time on the bigger questions around what is worth contributing and how it should be designed.
Try Outrider on your own repo: https://github.com/remyxai/outrider
Full contribution report: https://gist.github.com/smellslikeml/dbd577795b7489f6124e2bfbdfc9d28f
- 5 replies
reacted to their post with 🔥 17 days ago
Post
2799
I unblocked 15 improvements for VQASynth in a day!
VQASynth, the pipeline behind SpaceThinker-Qwen2.5VL-3B, SpaceLLaVA, and the SpaceThinker dataset, had a backlog spanning new annotation methods, curation pipelines, model integrations, and agent tools.
I scoped each item in a short design brief. In GitHub Actions, Outrider mapped them to the repo’s existing modules and interfaces, implemented the changes, added tests, ran the repo checks, and opened draft PRs.
The 15 PRs covered:
* object orientation and 3D bounding boxes
* SAM2 regional captioning and multi-view matching
* LLaMA-Mesh tokenization
* Qwen2.5-VL fine-tuning
* spatial-reasoning data generation
* CLIP, SigLIP, and LLM2CLIP backends
and more
The batch added 12,275 lines, nearly doubling the codebase.
SpatialAnnotator went from two tools to seven, creating combinatorially more possible annotation pipelines for each image.
Outrider handled the implementation, tests, and integration. At about $1 per branch, I spent my time reviewing 15 concrete changes, fixing what needed fixing, and deciding what to ship.
Outrider is open source!
Point it at a paper, issue, or design brief and review the PR: https://github.com/remyxai/outrider
Check out the updates on VQASynth: https://github.com/remyxai/VQASynth
VQASynth, the pipeline behind SpaceThinker-Qwen2.5VL-3B, SpaceLLaVA, and the SpaceThinker dataset, had a backlog spanning new annotation methods, curation pipelines, model integrations, and agent tools.
I scoped each item in a short design brief. In GitHub Actions, Outrider mapped them to the repo’s existing modules and interfaces, implemented the changes, added tests, ran the repo checks, and opened draft PRs.
The 15 PRs covered:
* object orientation and 3D bounding boxes
* SAM2 regional captioning and multi-view matching
* LLaMA-Mesh tokenization
* Qwen2.5-VL fine-tuning
* spatial-reasoning data generation
* CLIP, SigLIP, and LLM2CLIP backends
and more
The batch added 12,275 lines, nearly doubling the codebase.
SpatialAnnotator went from two tools to seven, creating combinatorially more possible annotation pipelines for each image.
Outrider handled the implementation, tests, and integration. At about $1 per branch, I spent my time reviewing 15 concrete changes, fixing what needed fixing, and deciding what to ship.
Outrider is open source!
Point it at a paper, issue, or design brief and review the PR: https://github.com/remyxai/outrider
Check out the updates on VQASynth: https://github.com/remyxai/VQASynth
reacted to SoulInPsyAbstract's post with 🔥 17 days ago
Post
2469
SIPA OS is a cognitive infrastructure ecosystem I've been building solo for 7 months — 8 apps, one login, built from inside ADHD/BPD/aphantasia, not designed around a diagnosis from outside.
sipa-os.org — the map. Focus (ADHD scaffolding), NeuroPower, AI chat, Shell (SSH terminal), Games, Community, Syntaxit (open M2M agent network), a pitch deck. All free-first — no paywall on the cognitive tools.
The more interesting part for this crowd: Syntaxit is where I've been running an anti-fabrication research thread with @dipankarsarkar — a k=20 resample benchmark on binary-SFT models (Hermes-3, Qwen2.5, DeepSeek-R1). Short version: our first benchmark said "20/20 refusals, 0/20 fabrications" for all three fine-tunes. Under adversarial review it turned out the scorer only checked if the first word was TRUE/FALSE, the token cap was hiding the real behavior, and a save-limit was silently deleting the evidence for our own follow-up claims. Corrected all of it publicly on the model cards rather than quietly fixing it. The current honest finding: both base and fine-tuned models confabulate readily once given room to finish — SFT didn't clearly help or hurt, the caps were just hiding it.
Full trail if you want to see how the sausage gets made, mistakes included: huggingface.co/datasets/SoulInPsyAbstract/sipa-os-governance
Not a pitch. $0 revenue, 10 people signed in. Built because the tools that existed assumed a brain that isn't mine, and because most benchmarks don't survive someone actually reading the file.
sipa-os.org — the map. Focus (ADHD scaffolding), NeuroPower, AI chat, Shell (SSH terminal), Games, Community, Syntaxit (open M2M agent network), a pitch deck. All free-first — no paywall on the cognitive tools.
The more interesting part for this crowd: Syntaxit is where I've been running an anti-fabrication research thread with @dipankarsarkar — a k=20 resample benchmark on binary-SFT models (Hermes-3, Qwen2.5, DeepSeek-R1). Short version: our first benchmark said "20/20 refusals, 0/20 fabrications" for all three fine-tunes. Under adversarial review it turned out the scorer only checked if the first word was TRUE/FALSE, the token cap was hiding the real behavior, and a save-limit was silently deleting the evidence for our own follow-up claims. Corrected all of it publicly on the model cards rather than quietly fixing it. The current honest finding: both base and fine-tuned models confabulate readily once given room to finish — SFT didn't clearly help or hurt, the caps were just hiding it.
Full trail if you want to see how the sausage gets made, mistakes included: huggingface.co/datasets/SoulInPsyAbstract/sipa-os-governance
Not a pitch. $0 revenue, 10 people signed in. Built because the tools that existed assumed a brain that isn't mine, and because most benchmarks don't survive someone actually reading the file.
- 4 replies
updated a
model 17 days ago
published a
model 17 days ago
Fused Triton kernels for DoRA — 1.24× over the PyTorch reference on A100
😎 1
1
#23 opened 18 days ago
by salma-remyx
posted an update 18 days ago
Post
2799
I unblocked 15 improvements for VQASynth in a day!
VQASynth, the pipeline behind SpaceThinker-Qwen2.5VL-3B, SpaceLLaVA, and the SpaceThinker dataset, had a backlog spanning new annotation methods, curation pipelines, model integrations, and agent tools.
I scoped each item in a short design brief. In GitHub Actions, Outrider mapped them to the repo’s existing modules and interfaces, implemented the changes, added tests, ran the repo checks, and opened draft PRs.
The 15 PRs covered:
* object orientation and 3D bounding boxes
* SAM2 regional captioning and multi-view matching
* LLaMA-Mesh tokenization
* Qwen2.5-VL fine-tuning
* spatial-reasoning data generation
* CLIP, SigLIP, and LLM2CLIP backends
and more
The batch added 12,275 lines, nearly doubling the codebase.
SpatialAnnotator went from two tools to seven, creating combinatorially more possible annotation pipelines for each image.
Outrider handled the implementation, tests, and integration. At about $1 per branch, I spent my time reviewing 15 concrete changes, fixing what needed fixing, and deciding what to ship.
Outrider is open source!
Point it at a paper, issue, or design brief and review the PR: https://github.com/remyxai/outrider
Check out the updates on VQASynth: https://github.com/remyxai/VQASynth
VQASynth, the pipeline behind SpaceThinker-Qwen2.5VL-3B, SpaceLLaVA, and the SpaceThinker dataset, had a backlog spanning new annotation methods, curation pipelines, model integrations, and agent tools.
I scoped each item in a short design brief. In GitHub Actions, Outrider mapped them to the repo’s existing modules and interfaces, implemented the changes, added tests, ran the repo checks, and opened draft PRs.
The 15 PRs covered:
* object orientation and 3D bounding boxes
* SAM2 regional captioning and multi-view matching
* LLaMA-Mesh tokenization
* Qwen2.5-VL fine-tuning
* spatial-reasoning data generation
* CLIP, SigLIP, and LLM2CLIP backends
and more
The batch added 12,275 lines, nearly doubling the codebase.
SpatialAnnotator went from two tools to seven, creating combinatorially more possible annotation pipelines for each image.
Outrider handled the implementation, tests, and integration. At about $1 per branch, I spent my time reviewing 15 concrete changes, fixing what needed fixing, and deciding what to ship.
Outrider is open source!
Point it at a paper, issue, or design brief and review the PR: https://github.com/remyxai/outrider
Check out the updates on VQASynth: https://github.com/remyxai/VQASynth
reacted to NatalieY's post with 🔥 22 days ago
Post
2042
Spent a while chasing a genuinely strange iOS bug while building Aiden (a physical agent that drives phones over USB HID): modifier-key shortcuts like Cmd+V would silently fail while plain keystrokes worked fine every time.
Turned out iOS was routing the command to the wrong process (SpringBoard, not the actual foreground app) whenever a keyboard and mouse were both present at the same time as AssistiveTouch. Confirmed it wasn't specific to our hardware, reproduced it on a completely unrelated gaming keyboard and a Bluetooth keyboard too.
Full writeup with the actual experiment table and log output: https://huggingface.co/blog/NatalieY/debugging-aiden
Curious if anyone here has hit this same failure mode building on iOS accessibility APIs.
Repo: https://github.com/AidenAI-IO/aiden-firmware
Turned out iOS was routing the command to the wrong process (SpringBoard, not the actual foreground app) whenever a keyboard and mouse were both present at the same time as AssistiveTouch. Confirmed it wasn't specific to our hardware, reproduced it on a completely unrelated gaming keyboard and a Bluetooth keyboard too.
Full writeup with the actual experiment table and log output: https://huggingface.co/blog/NatalieY/debugging-aiden
Curious if anyone here has hit this same failure mode building on iOS accessibility APIs.
Repo: https://github.com/AidenAI-IO/aiden-firmware
reacted to DedeProGames's post with 🔥 22 days ago
Post
1052
🚀 Introducing the GRM-3.2 Family
The GRM-3.2 family is a new generation of reasoning-focused models from OrionLLM, purpose-built for long-horizon agentic tasks, extremely difficult reasoning problems, advanced coding, and local AI workflows across a wide range of hardware constraints.
GRM-3.2-Sky is the flagship model in the family: a 35B-A3B Mixture-of-Experts model built on the Ornith-1.0-35B architecture, designed for elite structured reasoning, complex multi-file coding, advanced mathematics, and sustained coherence across extended agentic workflows. It represents a substantial leap in long-horizon task capability over its predecessor, GRM-2.6-Plus.
GRM-3.2-Cliff is the mid-sized workhorse: a 9B-parameter model optimized for long-horizon agentic tasks and difficult reasoning in low-to-mid GPU environments. It delivers strong multi-step planning, debugging, and terminal-agent performance without demanding flagship-level hardware.
GRM-3.2-Turf is the lightweight edge model: a 1.2B-parameter model based on the LiquidAI/LFM2.5-1.2B-Thinking architecture, engineered for efficient on-device execution, high-fidelity instruction following, and robust tool use on mobile, embedded, and other resource-constrained hardware.
All three models are designed for users who need dependable reasoning engines that can maintain goal-directed behavior, planning quality, and task fidelity across many steps—whether on a server, a local workstation, or an edge device.
Models:
GRM-3.2-Sky: OrionLLM/GRM-3.2-Sky
GRM-3.2-Cliff: OrionLLM/GRM-3.2-Cliff
GRM-3.2-Turf: OrionLLM/GRM-3.2-Turf
Organization:
OrionLLM
The GRM-3.2 family is a new generation of reasoning-focused models from OrionLLM, purpose-built for long-horizon agentic tasks, extremely difficult reasoning problems, advanced coding, and local AI workflows across a wide range of hardware constraints.
GRM-3.2-Sky is the flagship model in the family: a 35B-A3B Mixture-of-Experts model built on the Ornith-1.0-35B architecture, designed for elite structured reasoning, complex multi-file coding, advanced mathematics, and sustained coherence across extended agentic workflows. It represents a substantial leap in long-horizon task capability over its predecessor, GRM-2.6-Plus.
GRM-3.2-Cliff is the mid-sized workhorse: a 9B-parameter model optimized for long-horizon agentic tasks and difficult reasoning in low-to-mid GPU environments. It delivers strong multi-step planning, debugging, and terminal-agent performance without demanding flagship-level hardware.
GRM-3.2-Turf is the lightweight edge model: a 1.2B-parameter model based on the LiquidAI/LFM2.5-1.2B-Thinking architecture, engineered for efficient on-device execution, high-fidelity instruction following, and robust tool use on mobile, embedded, and other resource-constrained hardware.
All three models are designed for users who need dependable reasoning engines that can maintain goal-directed behavior, planning quality, and task fidelity across many steps—whether on a server, a local workstation, or an edge device.
Models:
GRM-3.2-Sky: OrionLLM/GRM-3.2-Sky
GRM-3.2-Cliff: OrionLLM/GRM-3.2-Cliff
GRM-3.2-Turf: OrionLLM/GRM-3.2-Turf
Organization: