Osmosis

Pick Osmosis when the model's failure mode is behavioral, not informational. An agent that keeps mis-sequencing tools, or an extractor that nails 80% of a document's schema and improvises the rest, is exactly the shape of problem RL post-training addresses. Their published work on Fused Logprobs is a tell that they're optimizing for the workloads that actually hurt — long-context RL with hundreds of tool calls per trajectory eats memory fast, and anything that trims it changes what's trainable. The concurrent LoRA adapter work points the same direction. Treating adapters as cheap policies sharing one base model means you can run many multi-policy experiments without multiplying your infrastructure bill. For a team iterating on reward functions across a week, that's the difference between three experiments and thirty. Where I'd pass: single-turn classification or summarization with plenty of clean labeled data. That's supervised fine-tuning territory, and RL adds cost and complexity for no return. Same for teams without an evaluation stack — the automated retraining loop is only as good as the signal you feed it, and if you can't measure regressions, hourly retraining is a liability, not a feature. The closest alternative depends on your appetite. General fine-tuning platforms will get you SFT and some preference tuning with less ceremony but less depth on multi-turn tool use. Building it in-house with Megatron-LM and SGLang is genuinely possible — Osmosis's own stack is built on both — but reward engineering and memory tuning are a full-time job, not a side quest. Caveats worth knowing before you sign. This is a forward-deployed engagement, so expect a hands-on vendor relationship rather than a login-and-go product; scope and timelines get discussed with their