Rosetta tasks do not have a strictly predictable runtime, and there is variation from one model to the next. To prevent credit spoofing, and attempt to align credit granted with work performed, Rosetta grants credit based on the number of models actually completed and the credit granted is based on the average completion reports of others working on the same batch of tasks.

So, if your granted credit is consistently around half of your claimed credit, it simply is an indication that your machine is taking more time to do things than other machines have required.

It looks like the machine you observed half credit on was this one:
http://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=1693333

It has 4 CPUs and 8GB of memory, but only a 256K L2 cache reported. So presuming typical BOINC Manager preferences for memory usage, that should be plenty of memory. But if the 256K is accurate on the L2 cache, that may be a chokepoint. Rosetta runs best on CPUs with large L2 cache. This sort of variation between machines is a part of why the work-based credit system was adopted. Your machine might do great running BOINC's benchmarks (which are the basis of the claimed credit figure), but if it doesn't actually crunch Rosetta models better, then it's granted credit will reflect that.

You have another machine here:
http://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=1693326

12 CPUs, 16GB of memory, NICE! It shows 256K L2 cache as well, but I seem to recall there were some BOINC Manager problems in reporting that correctly (which was the reason for some tentative wording above).

If this will be a nearly fulltime cruncher, I'd highly suggest increasing the runtime preference (which is done via the project website in the Rosetta preferences). Changes there WILL impact your current work on deck, so I generally suggest keeping a small cache, working through tasks so you don't have a lot onboard, and changing the preference gradually over the course of a week. This helps BOINC Manager adapt to the changing runtimes and avoids downloading more tasks than you can complete before the 10 day deadline.

The default runtime preference is 3hrs., the max is 24hrs. So why download 96 tasks to have a day of work when you can just get 12 and run them longer? This was another advantage to the per-model basis of the Rosetta credit system. Each user can establish their own runtime objective to help suit the way they like to use their machine. Crunch a task for more hours, you will complete more models, and more credit will be issued for the task. Credit per minute or per hour is the same. It just saves you (and the project) the bandwidth. Also saves a bit of overhead in getting a new task up and running many times per day.

Welcome to Rosetta!