It's similar in a number of ways. The communications protocols both are asynchronous, but capn'proto isn't inherently bidirectional (where commands can be sent both ways). Cap'n proto data is schema-based, whereas Concise encoding is ad-hoc.
Then again, Streamux is VERY low level, and I haven't written the higher level RPC mechanism yet (so it won't do a lot of things the Capn proto RPC layer does without some help). I'll be stealing a lot of high level ideas once I get to that level, but the primary thing is that Streamux is a communication layer designed to be built upon, since not everything requires the same heavy duty RPC treatment. Streamux will fit just fine in a tiny i2c environment or full on TCP or whatever comms channel you're using because you can tune it to use as much or as little of space/time/range resources as you need. And endpoints can negotiate these without even needing round-trips.
As for the binary format itself, Capn'proto relies upon schemas for decoding the data, whereas CBE encodes the basic data type so that it can be decoded without a schema (like JSON, XML, etc) so that you can encode ad-hoc data without needing to specify how it's decoded. Capn'proto only has void, bool, int (signed/unsigned), float, binary, list, and map types. Concise encoding has nil, bool, int (signed unsigned), float (binary and decimal), string, date, URI, binary, list, map, markup, comments, metadata, and references. References are important because they handle cyclic and repeating data in an elegant manner. Capn'proto doesn't support float compression.
That's off the top of my head. Capn'proto has a lot of good ideas and looks very nice for its niche, but the biggest issues I have are the need for a schema, lack of types, and the lack of a twin text format (and this is by design, because it's competing with Protobufs, not JSON). However, it supports mmap, so it can be blindingly fast for certain applications that concise encoding won't even try to compete in.
