Note: This bug is a regression from 2.0.x behavior in mongos. There are no issues with mongod.

mongos returns the wrong value in the startingFrom field of OP_REPLY. The problem appears to be that mongos sets startingFrom to the same value as numberReturned. This causes PyMongo to assert expecting startingFrom to be 0 on the initial batch:

>>> cur = c.test.test.find()
>>> cur.next()
startingFrom: 100
numberReturned: 100
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pymongo/cursor.py", line 747, in next
    if len(self.__data) or self._refresh():
  File "pymongo/cursor.py", line 698, in _refresh
    self.__uuid_subtype))
  File "pymongo/cursor.py", line 668, in __send_message
    assert response["starting_from"] == self.__retrieved

The output should look like this (and does with mongod in 2.1.1):

>>> cur = c.test.test.find()
>>> cur.next()
startingFrom: 0
numberReturned: 101
{u'i': 0.0, u'_id': ObjectId('4fb1a26cb59381ba9dc941c8')}

The problem appears to be in src/mongo/s/cursors.cpp. At line 136 in ShardedClientCursor::sendNextBatch we have:

_totalSent += docCount;

Then in the calling method ShardedClientCursor::sendNextBatchAndReply we have:

replyToQuery( 0, r.p(), r.m(), buffer.buf(), buffer.len(), docCount,
       _totalSent, hasMore ? getId() : 0 );

At that point docCount and _totalSent are the same.