Things appear to be working as designed as far as I can tell.
You have the lower range set to 10% and the upper range set to 100% with a midpoint of 50. Thus, while the non-autotrof population is between 45 and 100, the system will not change the CostX multiplier. When above 100, it is increased as you see (with execptions - see below). When below 45, it is decreased (with exceptions - see below).
Note that the algorithm is more complex than simply increasing and decreasing. I have described it in detail in previous posts but in short, if the popualtion is below the lower threshold, but it happened to increase over the previous cycle, the CostX multipler will *not* be decreased that cycle since the population is moving towards the range. Additionally, if the population is belwo the range and remained the same from one cycle to the next, the CostX multiplier will similarly not be decreased unless it stays the same for 10 consecutive cycles. Then it will get bumped down. How much it gets bumped down is a function of the sensitivity and of how far out of the range it is. Of course, the inverse happens for when the population is above the upper range.
Using the Auto Costs Stats graph is very useful to see what is happening.
The overpopulation problem following when the zero costs threshold is hit and the CostX multipler crashes to 0 has been pointed out previously and I have added the new CostX reinstatement feature described in the first post in this thread to help address it.
Let me know if you still think there is a bug.