anchor.diff:  
   ## Auto-scaling your build agents
   
  -We've provided a number of APIs to allow you to automatically scale your build agents based on build queue.
  +We provide a number of APIs for automatically scaling agents based on you build queue.
   
  -* Using the [Pipelines API](/docs/api/pipelines) you’re able to fetch the `scheduled_jobs_count`, `waiting_jobs_count` and `running_jobs_count` to get an overview of the number of jobs waiting to be run. Based on this you can spin up new agent machines to process the jobs waiting to be run.
  -* Using [agent prioritization](/docs/agent/prioritization) you’ll able to define a core set up agents that are assigned work first, and then lower priority agents which you may spin up and spin down on demand.
  -* Using the [Agents API](/docs/api/agents) you’re able to fetch your agent’s `job` and `last_job_finished_at`, which allow you to see if they have been idle. You can then remotely shut down an agent process using the [agent stop API](/docs/api/agents#stop-an-agent) (passing `"force": false` to ensure it won’t cancel any running job).
  +* Using the [Pipelines API](/docs/api/pipelines) you’re able to fetch the `scheduled_jobs_count`, `waiting_jobs_count` and `running_jobs_count` to get an overview of the number of jobs waiting to be run. Keeping track of this value, you can spin new agent machines up or down to accomodate the job load.
  +* Using [agent prioritization](/docs/agent/prioritization) you’ll able to define which agents are assigned work first, as well as lower priority agents which you may spin up and down on demand.
  +* Using the [Agents API](/docs/api/agents) you’re able to fetch your agent’s `job` and `last_job_finished_at`, which allow you to see if they have been idle. Using the [agent stop API](/docs/api/agents#stop-an-agent) you can remotely shut down idle agent processes (passing `"force": false` to ensure it won’t cancel any running job).
   
   Using these three APIs you can automate your build infrastructure, scale your agents based on demand, and ensure no-one has to wait for their build to start.
  
positive.code: BUILDKITE_PARALLEL_JOB_COUNT=5
  ```
  
  The `BUILDKITE_PARALLEL_JOB` environment variable is the job number starting from 0, in this case each job’s value would be `0`, `1`, `2`, `3`, and `4`.
  
  The `BUILDKITE_PARALLEL_JOB_COUNT` environment variable is the total number of jobs.
  
  You can use these two environment variables to divide your application’s tests between the different jobs.
  
  ## Libraries
  
  The following libraries have built-in support for the `BUILDKITE_PARALLEL_*` environment variables:
  
  * [Knapsack](https://github.com/ArturT/knapsack)
  <br>A ruby gem for that will automatically divide your tests between parallel jobs, as well as making sure each job runs in comparable time. Supports RSpec, Cucumber and Minitest.
  
  ## Isolated jobs
  
  
negative.code: 
  <%= image 'parallelism.png', size: '555x138', alt: 'Step parallelism field' %>
  
  Update the name of the step to use `%n`, like the example below. This will substitute a number in at runtime so that you can differentiate the different build jobs:
  
  <%= image 'name.png', size: '555x80', alt: 'Step name field with %n' %>
  
  Now that the pipeline is configured, create a new build:
  
  <%= image 'build.png', size: '405x204', alt: 'The build' %>
  
  