This paper describes the use of the command, facade and decorator design patterns to alter the interface and add new responsibilities to threads. Termed Project Imperion, the threads are developed with the same design patterns as previously reported for Imperion GUI components [Lyon 2004b]. The benefits of Imperion threading include: simplifying code, easing maintenance, separation of thread management logic from the business logic and improved reliability. Our experience shows that threads are often run more than once. They are frequently stopped and then restarted. However, the present mechanisms for doing this are both low-level and exception-prone. Imperion threads have built-in support for iteration. They support killing and restarting threads by introducing a new class called the RunJob. The RunJob tracks the number of times it has been run, and can be set to run only so many times before it dies. It can be set to start automatically, or be set to wait until explicitly started (or restarted). The Imperion threading system is a more reliable threading system than the normal java.lang.Thread. Imperion removes dangerous methods and guards’ inputs in order to avoid exceptions. For example, the daemon property can only be set during construction, priorities are guarded for correctness and restarting is safe. This avoids a fruitful source of complex run-time errors that have been bugging both novice and seasoned programmers since the release of JDK 1.0. Project Imperion was named for the Latin root, imperium, which means the power to command. Like the Intel use of the word CELERON, the on suffix was added to give the word a high-tech look (like electron, proton or muon). It was first conceived at the skunk works of DocJava, Inc., in the late 1990’s.