Redux was developed to achieve hot reloading global state and state changing logic. To achieve that it was necessary for state changes to be run with pure functions and the state has to be immutable. Now you can change the logic inside your reducer and when the application reloads Redux will put it in its initial state and rerun all the actions again, now running with the new state changing logic.
Cerebral had no intention of achieving hot reloading. Cerebral was initially developed to give you insight into how your application changes its state, using a debugger. In the Redux debugger you see what actions are triggered and how your state looks after the action was handled. In Cerebral you see all actions fired as part of a signal. You see asynchronous behaviour, paths taken based on decisions made in your state changing flow. You see all inputs and outputs produced during the flow and you even see what paths were not taken. In addition to this you also see exactly what state was updated with what values.
What also differs is that Cerebral remembers the result of asynchronous requests, meaning that reproducing the state of your application does not trigger new asynchronous requests. When reproducing state it just outputs whatever the asynchronous action did when it was run the first time. This also allows you to safely move back and forth in time without firing off asynchronous requests.
Hot reloading is an amazing tool, though we must not forget that the main goal of hot reloading is to avoid loosing the state of your application when you make changes to your code. With Cerebral you will not loose the state making code changes, but you will have to reload the page to see the change. That said, you can combine Cerebral with hot reloading React components.
A really cool part of Redux is the middleware. The library itself is very small, but allows developers to extend it very easily. This has given birth to lots of middleware in Redux. Cerebral is flexible in the way that it can be used with any view and immutable model layer, but it exposes a default API surface for changing the state. That means the community around Cerebral orbits the library itself, which gives a slower and more opinionated evolution. For better and for worse :-)
It is really good to see that Redux also affected the ideas of the router actually producing state, not just controlling your component tree. That said, this idea is taken further with Cerebral. The Cerebral Router just binds a url to a signal and makes it completely transparent. It does not matter if you trigger a signal or trigger the url, it will run the signal and put your application in the correct state. When a url is triggered the payload is created by parsing the url. When a signal is manually triggered with a payload the url is created by serializing the payload. It is actually extremely cool :-)
Redux and Cerebral also differs when it comes to accessing state. Redux manages state by separating it into different reducers. This is really great because when you look at a reducer you see what actions and logic that affects that specific piece of state. That said an action could potentially be handled in multiple reducers and you might need state in a reducer from an other reducer. That causes some challenges in Redux. With Cerebral you define a flow of state changes and you can access all your existing state at any point in the flow. You also define the state as one big state tree. Personally I think this is better because you can never go wrong in how you structure your state. So it is easier to read state changes in Cerebral from the perspective of a component changing your state, but it is harder to read in regards of "what can affect this piece of state?". One might say that from the "inside out" Redux reads better. From the "outside in" Cerebral reads better.
I hope this gave you some insight into how Cerebral and Redux differs. If you have an application that has complex asynchronous state changing flows I would suggest looking into Cerebral. If not, Redux might be what you are looking for! Thanks for reading :-)
Thanks for the succinct comparison!