Well, you said it. It depends on the context. Precisely, it depends on what the attacker has to do to test an hypothesis on the session key.
If the attacker, to test a key, must talk to your server, then this is an online attack and it won't go faster than what your server can do -- moreover, you could apply countermeasures, e.g. stop talking to clients that obviously engage in attackish behaviour. 33 bits ought to be enough for that. This is, after all, the situation of servers that do password-based authentication of clients.
If the attacker can just do computations on his own machines, to ascertain whether a potential session key is the right one or not, then this is an offline attack, limited only by the computing power available to the attacker. In that situation, 33 bits are way too few to be much of a problem for the attacker. Exact threshold depends on the attacker's motivation, his available computing power, his patience, and the amount of computations needed to verify one session key; but 33 bits are really too low for that.
Whether the context is that of an online or offline attack depends on the details of your protocols. If the "session key" is just sent to the server within a SSL tunnel (e.g. a cookie for an HTTPS Web site), then this is an "online attack" context. Just configure your firewall to block clients that connect too many times within a small time frame, and you should be fine (or, at least, finer than your competitors, so attackers will attack them, not you).