Think in terms of a “logical unit of packaging” — which may be a single class, but more often will be a set of classes that closely cooperate. Classes (or module-level functions — don’t “do Java in Python” by always using static methods when module-level functions are also available as a choice!-) can be grouped based on this criterion. Basically, if most users of A also need B and vice versa, A and B should probably be in the same module; but if many users will only need one of them and not the other, then they should probably be in distinct modules (perhaps in the same package, i.e., directory with an __init__.py file in it).
The standard Python library, while far from perfect, tends to reflect (mostly) reasonably good practices — so you can mostly learn from it by example. E.g., the threading module of course defines a Thread class… but it also holds the synchronization-primitive classes such as locks, events, conditions, and semaphores, and an exception-class that can be raised by threading operations (and a few more things). It’s at the upper bound of reasonable size (800 lines including whitespace and docstrings), and some crucial thread-related functionality such as Queue has been placed in a separate module, nevertheless it’s a good example of what maximum amount of functionality it still makes sense to pack into a single module.