A cookie jar to store cookies is for something else: it does not create "keepalive" HTTP sessions, but allows restarting sessions that have been already closed by proving again the stored cookies.
No, there's NO need at all of ANY cookie jar storage in HTTP to use "keepalive" sessions.
So this just looks like a limit of the current "http.*" package you use which terminates all sessions immediately after each request instead of maintaining it (note: maintaing a session is not warranties: the server may close it at any time if your session is idle for too long, or for various reasons, but for HTTP sessions you want to use for example to performed streamed requests in a queue, reusing the session will always be faster than creating one new outgoing session for each request in your queue (including the cookies exchange which also add to the data volume transmitted).
Without "keepalive", if you want to perform a lot of small queries in a long series of requests, or want to do streaming, your client would rapidly exhaust its number of available TCP ports (because each new HTTP session allocates a new port number, and even if it is closed and the server has acknowledge that closure, that port number cannot be reused immediately before a delay which is generally about 30 seconds (this varies if you have proxies, or depending on your ISP or router, or depending on security thresholds: for security and privacy of TCP, this delay should never be reduced too much: there are security routers that force outgoing TCP port numbers to remain in FIN_WAIT state for more than 3 minutes, and if your Internet connection is shared by multiple users or other services, you'll fall to a case where you no longer have any usable local TCP ports to allow more connection, and your repeated HTTP queries will rapidly then fail to connect after a few thousands queries performed rapidly).
The "keepalive" feature was made a *standard* part of HTTP/1.1 (instead of being optional and not working very well in the now very old HTTP/1.0 protocol) exactly to preserve network resources, and get much better performance and lower bandwidth usage. Without it, most modern websites would be extremely slow.
Using "curl" to create a cookie jar does not mean that you are using keepalive, but at least it allows all requests you send using the same cookie jar file to reopen new sessions using the same resident cookies that were exchanged in the previous requests (so this "simulates" sessions, but still you'll see many outgoing TCP sockets that are "half-terminated" in FIN_WAIT state and that still block the unique port numbers that were assigned to that socket).
So I suggest instead using a virtual "local HTTP proxy" package that will maintain a session opened on an unterminated HTTP session, overwhich you'll queue one or multiple http requests. Such thing is used in (de)muxing subprotocols (of multimedia streaming protocols, or in VPN protocol managers), but it is even part of classic web browsers that queue the many queries that are performed in the background when visiting a website (generally a browser can create up to 4 HTTP sessions working in parallel, each one having its own queue of queries). All of these use the keepalive feature of HTTP/1.1.
