I wouldn't say that there's any "rule of thumb" for refactoring large classes. Sometimes a class really encapsulates a lot of business logic and should be as large as it is. However, you might consider asking yourself a few questions:
(Assuming you're writing object oriented code) Is my code truly object-oriented? That is, does it follow the Single Responsibility Principle (thanks, Nebakanezer)? Is this class a helper class? If so, how could I refactor its methods into more appropriate object classes?
Do I have a solid architecture? That is, am I making use of abstraction and inheritance rather than re-inventing the wheel in every class? Are overloaded methods calling base methods as appropriate?
Do I really need all this code? Could some of the logic be externalized using xpath, lambda expressions, or some form of database driven expressions?
Is the code extensible? Is it easy to maintain? Was it well-architected from the beginning, or are we always making small patches to try to fix problems?
I hope that this helps a little; it can be difficult to refactor large classes, but I think if you start looking through my questions, you may find pretty quickly that there is room for improvement in your code...I know I typically do.
Especially look at #1--it's really common for people to create a ton of helper classes all over the place, which is very anti-object oriented (in my opinion). That's a different topic, but you may want to see what really -belongs- in the class you've made and what could/should be somewhere else.
As a rule of thumb, if the class is maintainable and flexible, it may not need to be changed. :)