Above any suggestions here, ask your pair what they think, or how they feel about any given situation.
Maybe you're in your comfort zone and being super-productive. If things slow down when you stop driving, maybe that's a sign that your pair could do with more practice.
It is vital that people are allowed to work at their own pace without explicit or implicit pressure. We pair so that people can learn and gain context on systems; if one half of the pair can't keep up, then they're not learning anything and not gaining context. Any slowdown is a cost that EngineerBetter is willing to absorb.
If there's a speed discrepancy between you, consider setting a timer and taking turns.
Sometimes its easier to type than to explain an idea. It's more socially awkward to remove something that's already been written than it is to critique an idea that is merely being discussed. Writing first and explaining after may put your pair on the back foot.
This point is most pertinent when pairing with someone of lesser experience.
People are less likely to remember a fact if they are told it than if they discover it for themselves. Whilst it might be quicker in the short term to tell people answers, in the long term it may be better to let them think, try something, and find out for themselves why it is wrong.
When pairing with someone with less experience, it can be tempting to give them very direct instructions "type 'git pull origin master'; hit return..." Giving goals instead allows your pair to problem solve for themself, eg "Next we need to get the latest code onto this machine.".
When was the last time I drove? It's not so much about 'doing your fair share' as making sure that you strengthen the right neural pathways to ensure that you really understand what's going on. Could I take over if my pair had to disappear somewhere?
Is your pair responding with "yeah", "uh-huh", and not a lot else? Maybe they understand enough to tenuously follow what you're doing, but not enough if you asked them to drive.
If your pair doesn't get what you're doing, perhaps you can try explaining the issue in a different way. Although the idea of learning styles is largely discredited, the notion of 'multiple intelligences' continues to be useful as a framing tool. If you've tried explaining with words, perhaps a diagram would help? If describing the details of an API isn't helping, maybe try talking through the flow of calls?
It takes courage to slow someone down and to tell them that you don't understand. Keeping quiet won't make anything better, and the only solution to not understanding something is to take the time to understand it!
Do you always take control after a certain point? Is there a pattern to the parts you take the keyboard for?
There can be many pitfalls when developers with different skill levels try pairing. The natural instinct for the senior developer is to explain everything without allowing time for the junior developer to discover answers for themselves. Try using open ended questions instead of jumping straight into explanations.