You can keep ipython kernel running in background if you want. Quick unscientific test showed that it didn't reduce ipython console startup time significantly. But it should be possible to make a leaner console to connect to the kernel.

edit: my test was flawed, with more accurate test there is almost a full second time difference:

    $ echo -n | time ipython console --existing kernel-29793.json
    1.06user 0.06system 0:01.52elapsed 74%CPU (0avgtext+0avgdata 29968maxresident)k
    0inputs+64outputs (0major+19245minor)pagefaults 0swaps
    $ echo -n | time ipython console
    1.07user 0.08system 0:02.40elapsed 48%CPU (0avgtext+0avgdata 30264maxresident)k
    0inputs+72outputs (0major+20538minor)pagefaults 0swaps

of course two seconds is ridiculously slow either way

If loading the rest of the code and initialization time really matters, yes. But then you're back to square one: you now have to create a CLI to access the server and that new CLI must load quickly. Which would also be the case if you just wrote it that way first, then loading the rest of the code once the command is determined.

And if you're in some project similar to Django, you would have first to query the server to know the possible subcommands...

So what you say makes sense when other parts of the code are slow to initialize and must be accessed frequently, not for the CLI itself.

I think you want a pool of python interpreters read to go.