a lot of the features in open-source rl / inference frameworks will eventually show up in other implementations. the more interesting question is how quickly a framework gets there, and how much work it takes to actually use them.
two related things seem to matter:
1 - the primitives. can you change the part you care about without pulling apart everything around it?
@radixark miles’ async rollout buffer is a good example: you can change which groups of samples reach training and which prompts get retried, while reusing the rollout worker and trainer. the granularity of that interface matters. extension points should let people work on different parts of the system without constantly stepping on each other, and the contracts should be stable enough that those extensions survive upgrades.
2 - contribution velocity. getting a new attention backend running is one step. making it work with the KV cache formats, prefix caching, and speculative decoding your workload needs is more work. what matters is how quickly contributors and maintainers can get an improvement through that process and into something people can depend on.
cheaper code generation makes this more interesting. it gets easier to add features and easier for everyone else to catch up. there’s still the work of integrating changes, checking correctness, and measuring performance on real workloads. good primitives help keep each contribution from turning into a project across the entire stack.
if your framework makes a useful technique practical a couple weeks/months earlier, that’s invaluable time for experiments and learning. the question is whether a framework can keep giving you that head start, without making you do all the integration work yourself.