Update pages around usage

docs/guides/allocation-limits.mdx

@@ -30,6 +30,6 @@ When you set the allocation limit for an instance in IBM Quantum Platform, the s
 
 <Admonition type="tip" title="Recommendations">
     - Learn about [instances](/docs/guides/instances).
-    - Review suggestions to [minimize job quantum time](minimize-time).
+    - Review suggestions to [minimize job quantum usage](minimize-time).
     - Understand the [fair-share scheduler](/docs/guides/fair-share-scheduler).
 </Admonition>

docs/guides/estimate-job-run-time.ipynb

@@ -30,11 +30,11 @@
    "metadata": {},
    "source": [
     "<span id=\"usage\"></span>\n",
-    "Usage is a measurement of the amount of time the QPU is locked for your workload, and it is calculated differently, depending on which execution mode you're using.\n",
+    "Usage is a measurement of the amount of resource consumption. This resource consumption maps to different cost based on the plan type.\n",
     "\n",
-    "* Session usage is the wall-clock time the session is active. See [Session length](/docs/guides/run-jobs-session#session-length) for more information about session status transition.\n",
-    "* Batch usage is the sum of quantum time (time spent by the QPU complex to process your job) of all jobs in the batch.\n",
-    "* Single job usage is the quantum time the job uses in processing.\n",
+    "- Session usage is the wall clock time the session is active. See [Session length](/docs/guides/run-jobs-session#session-length) for more information about session status transition.\n",
+    "- Batch usage is the sum of quantum usage (quantum resource consumption) for all jobs in the batch.\n",
+    "- Single job usage is the quantum usage the job consumes in processing.\n",
     "\n",
     "Note that failed or canceled jobs count toward your usage in certain circumstances - see the [Failed and canceled jobs](#failed-job) section for details.\n",
     "\n",
@@ -44,7 +44,7 @@
     "## Usage for failed and canceled jobs\n",
     "When a job is failed or canceled, the reported usage is as follows:\n",
     "\n",
-    "* Job or batch mode: The reported usage is the time the QPU was locked for executing your workload until the time it failed or was canceled. Therefore, if the failure or cancellation occurred before the lock, the reported usage is zero. Otherwise, the workload's reported usage is the amount of usage before the workload failed or was canceled. Thus, some failed jobs do not appear in your reported usage and others do.\n",
+    "* Job or batch mode: If the failure or cancellation occurred before resource consumption began, the reported usage is zero. Otherwise, the workload's reported usage is the usage before the workload failed or was canceled. Thus, some failed jobs do not appear in your reported usage and others do.\n",
     "\n",
     "* Session mode: The reported usage is the wall-clock time the session is active, regardless of the number of jobs that fail or are canceled.\n",
     "\n",
@@ -63,31 +63,12 @@
     "You can view an instance's usage on the [Instances](https://quantum.cloud.ibm.com/instances) page, or, for those with the proper authority, the [Analytics](https://quantum.cloud.ibm.com/analytics) page.  Note that the pages might show different usage numbers because they calculate usage differently.\n",
     "\n",
     "The Instances page shows real-time usage for the last 28 days (rolling), up to the current time on the current day.  The Analytics page usage is re-calculated hourly and includes the last 28 full days; that is, it shows usage from 00:00 28 days ago to today, at the top of the hour.\n",
-    "\n",
-    "## Estimate usage before submitting a job\n",
-    "\n",
-    "While getting an accurate local estimation is complicated by the extra operations done for error suppression and mitigation, you can use this baseline formula to get an approximation of estimated usage:\n",
-    "\n",
-    "`<per sub-job overhead> + (rep_delay + <circuit length>) * <num executions>`\n",
-    "\n",
-    "- `<per sub-job overhead>` is an overhead of approximately 2s per sub-job. This includes operations such as loading the payload into control electronics. Your primitive job may be divided into multiple sub-jobs if it is too large for the execution engine to process all at once.\n",
-    "- `rep_delay` is a [user-customizable](/docs/api/qiskit-ibm-runtime/options-execution-options-v2#rep_delay) option, and the default is given by `backend.default_rep_delay`, which is 250 microseconds on most IBM Quantum backends. Note that lowering `rep_delay` decreases the total QPU execution time, but at the expense of increased state preparation error rate; see the [Dynamic repetition rate execution](/docs/guides/repetition-rate-execution) guide for more information.\n",
-    "- `<circuit length>` is the total instruction length. Each instruction takes different amount of time on the QPU, so the total length varies from circuit to circuit. A measurement, for example, can take 56 times longer than an `x` gate. `backend.target[<instruction>][<qubit>].duration` can be used to find the exact duration for each instruction. A typical circuit length is likely between 50-100 microseconds. If you are using error suppression or mitigation techniques with the primitives, extra instructions might be inserted into your circuit, which would increase the total circuit length.\n",
-    "    <Admonition type=\"note\">\n",
-    "    The [experimental `scheduler_timing` option](/docs/guides/visualize-circuit-timing) returns the total circuit time, but this is NOT the time used for billing.\n",
-    "    </Admonition>\n",
-    "- `<num executions>` is the total number of circuits times the number of shots, where the circuits are those generated after PUB elements are broadcasted.\n",
-    "    - If you are using error mitigation techniques with the primitives, extra circuits might be run as part of the mitigation process, which would increase the total number of executions. Additionally, advanced error mitigation techniques such as PEA and PEC come with much higher overhead because they require running circuits for noise learning.\n",
-    "    - Estimator groups qubit-wise commuting observables, which reduces the number of executions.\n",
-    "\n",
-    "If you aren't using any advanced error mitigation techniques or custom `rep_delay`, you can use `2+0.00035*<num executions>` as a quick formula.\n",
-    "\n",
     "## Next steps\n",
     "\n",
     "<Admonition type=\"tip\" title=\"Recommendations\">\n",
     "    - Review these tips: [Minimize job run time](minimize-time).\n",
-    "    - Set the [Maximum execution time](max-execution-time).\n",
-    "    - Learn how to transpile locally in the [Transpile](./transpile/) section.\n",
+    "    - Set the [Maximum execution time](/docs/guides/max-execution-time).\n",
+    "    - Learn how to transpile locally in the [Transpile](/docs/guides/transpile/) section.\n",
     "    - Try the [Compare transpiler settings](/docs/guides/circuit-transpilation-settings) guide.\n",
     "</Admonition>"
    ]

docs/guides/execution-modes-faq.mdx

@@ -102,10 +102,7 @@ The main difference is the time and cost tradeoff:
 Batch mode:
 
 - The total run time is less because the classical processing might run in parallel.
-- There is a slight overhead for running each job, so you end up paying a little more for batched jobs. This overhead correlates to the size of the job. For example, the total usage of two jobs, each containing 40 100x100 circuits, is six seconds more than a single job containing 80 circuits.
-- Because batch mode doesn't give you exclusive access to a backend, jobs inside a batch might run with other users' jobs or calibration jobs.
-- If some jobs fail, you still get results from the completed jobs.
-- You can take action in the middle of a batch workload based on the results of completed jobs. For example, you can cancel the rest of the jobs if the initial results look incorrect.
+- There is a slight overhead for running each job, so you end up paying a little more for batched jobs.
 
 Job mode:
 

docs/guides/instances.mdx

@@ -19,7 +19,7 @@ It is important that you understand which instance you are using, because all in
 <span id="open-plan"></span>
 ## Open Plan instance
 
-Open Plan users can run quantum circuits on the world's best QPUs for free (up to 10 minutes quantum time per 28-day rolling window). The QPU usage can be tracked on the [Platform dashboard](https://quantum.cloud.ibm.com/) and the [Workloads](https://quantum.cloud.ibm.com/workloads) pages.
+Open Plan users can run quantum circuits on the world's best QPUs for free (up to 10 minutes quantum usage per 28-day rolling window). The QPU usage can be tracked on the [Platform dashboard](https://quantum.cloud.ibm.com/) and the [Workloads](https://quantum.cloud.ibm.com/workloads) pages.
 
 <span id="standard-plan"></span>
 ## Pay-As-You-Go Plan instance
@@ -83,7 +83,7 @@ Follow these steps to create an instance and add it to your account. If you are
 1. From the Instances page, click **Create instance**.
     * Enter a name and optionally add tags.
     * If you have access to more than one resource group in IBM Cloud&reg;, you can choose to change the resource group this instance belongs to. See [Managing resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs&interface=ui) and [Giving access to resources in resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs_manage_access) for more information.
-1. Select the pricing plan this instance is associated with (for example, Pay-As-You-Go). Depending on the pricing plan selected, you can specify other options, such as the cost limit or the number of minutes to allocate to this instance. Note that If this instance is not associated with a free plan, a cost will be incurred when this instance is used to run workloads.
+1. Select the pricing plan this instance is associated with (for example, Pay-As-You-Go). Depending on the pricing plan selected, you can specify other options, such as the cost limit or the number of minutes to allocate to this instance. Note that if this instance is not associated with a free plan, a cost will be incurred when this instance is used to run workloads.
 1. Click **Next**. A list of the QPUs the instance can access is shown.
     - If you want the instance to have access to all the QPUs listed (and all QPUs added to this plan in the future), click **Next**.
     - If you are not setting up an open instance, you can customize which QPUs can be accessed with this instance. Click the "Customize allocated compute resources" toggle. Select specific QPUs that this instance can access, then click **Next**.

docs/guides/manage-cost.mdx

@@ -6,7 +6,7 @@ description: How to manage costs of running jobs on QPUs when using the Pay-As-Y
 
 # Manage cost
 
-This guide describes how to set a cost limit on your Pay-As-You-Go Plan instance.  You can also manage cost by [minimizing a workload's quantum time](/docs/guides/minimize-time), and setting a [maximum execution time](/docs/guides/max-execution-time) on your workloads.
+This guide describes how to set a cost limit on your Pay-As-You-Go Plan instance.  You can also manage cost by [minimizing a workload's quantum usage](/docs/guides/minimize-time), and setting a [maximum execution time](/docs/guides/max-execution-time) on your workloads.
 
 The _cost limit_ refers to the total cost of all workloads run with this instance since it was created, and it will always be greater than or equal to the total cost. After the instance reaches the specified number of total seconds, no further workloads can be run and no more cost is incurred.
 
@@ -101,9 +101,9 @@ To determine how much has been billed to an instance during the current billing
 
 These are the fields relevant to cost:
 
-- **Billing cycle usage**: The amount of _quantum time_ used by this instance during the current billing cycle. Quantum time is the duration a QPU is committed to fulfilling a user request.
+- **Billing cycle usage**: The instance's _quantum usage_ during the current billing cycle. Quantum usage is the duration a QPU is committed to fulfilling a user request.
 - **Billing cycle cost**: The total cost of running jobs during the current billing cycle.
-- **Total usage**: The amount of quantum time used by this instance since it was created.
+- **Total usage**: The total amount of this instance's quantum usage since it was created.
 - **Total cost**: The total cost of running jobs on this instance since it was created. Only administrators can set this value.
 
 You can view your billing cycle on the [Billing and usage page](https://cloud.ibm.com/billing).
@@ -114,7 +114,7 @@ To determine how much has been billed to each job associated with an instance, f
 
 These are the columns relevant to cost:
 
-- **Usage**: The amount of quantum time used by this job. Quantum time is the duration a QPU is committed to fulfilling a user request.
+- **Usage**: The amount of resource consumption used by this job. Quantum usage is the duration a QPU is committed to fulfilling a user request.
 - **Cost**: The total cost of running this job.
 
 ## Set up spending notifications
@@ -129,6 +129,6 @@ You can set up spending notifications to get notified when your account or a par
 
 <Admonition type="tip" title="Recommendations">
     - Review the [plans](/docs/guides/plans-overview) available to IBM Quantum users.
-    - Review suggestions to [minimize job quantum time](/docs/guides/minimize-time).
+    - Review suggestions to [minimize job quantum usage](/docs/guides/minimize-time).
     - Learn how to set a [maximum execution time](/docs/guides/max-execution-time) on jobs.
 </Admonition>

docs/guides/max-execution-time.ipynb

@@ -41,10 +41,10 @@
     "\n",
     "The maximum execution time for a job is the smaller of these values:\n",
     "\n",
-    "- The value set for `max_execution_time`\n",
+    "- The value set for `max_usage`\n",
     "- The service-determined job timeout value\n",
     "\n",
-    "The `max_execution_time` value is based on _quantum time_, not wall clock time. Quantum time is the amount of time that the QPU is dedicated to processing your job.\n",
+    "The `max_usage` value is based on *quantum usage*, not wall clock time. Quantum usage is the amount of time that the QPU is dedicated to processing your job.\n",
     "\n",
     "Set the maximum execution time (in seconds) on the job options, as shown in the following example.  See [Specify options](/docs/guides/specify-runtime-options) for information about setting options.\n",
     "\n",
@@ -57,22 +57,22 @@
     "\n",
     "estimator = Estimator(mode=backend)\n",
     "\n",
-    "estimator.options.max_execution_time = 2500\n",
+    "estimator.options.max_usage = 2500\n",
     "```\n",
     "\n",
-    "You can also find how much quantum time completed jobs have used by returning the job metrics as follows:\n",
+    "You can also find how much quantum usage completed jobs have used by returning the job metrics as follows:\n",
     "\n",
     "```python\n",
-    "# Find quantum time used by the job\n",
-    "print(f\"Quantum time used by job {job.job_id()} was {job.metrics()['usage']['quantum_seconds']} seconds\")\n",
+    "# Find quantum usage of specific job\n",
+    "print(f\"Quantum usage of job {job.job_id()} was {job.metrics()['usage']['quantum_seconds']} seconds\")\n",
     "```\n",
     "\n",
     "<span id=\"max-QPU\"></span>\n",
     "## Service-calculated maximum execution time\n",
     "\n",
-    "The service calculates an appropriate job timeout value based on the input circuits and options. This service-calculated timeout is capped at 3 hours to ensure fair device usage. If a `max_execution_time` is also specified for the job, the lesser of the two values is used.\n",
+    "The service calculates an appropriate job timeout value based on the input circuits and options. This service-calculated timeout is capped at 3 hours to ensure fair device usage. If a `max_usage` is also specified for the job, the lesser of the two values is used.\n",
     "\n",
-    "For example, if you specify `max_execution_time=5000` (approximately 83 minutes), but the service determines it should not take more than 5 minutes (300 seconds) to execute the job, then the job is canceled after 5 minutes.\n",
+    "For example, if you specify `max_usage=5000` (approximately 83 minutes), but the service determines it should not take more than 5 minutes (300 seconds) to execute the job, then the job is canceled after 5 minutes.\n",
     "\n",
     "<span id=\"batch-max-time\"></span>\n",
     "## Batch maximum execution time\n",
@@ -96,13 +96,13 @@
     "\n",
     "\n",
     "*   Inputs to jobs cannot exceed 50MB in size.\n",
-    "*   Open Plan users can use up to 10 minutes of quantum time per 28-day rolling window. Quantum time is the amount of time that the QPU is dedicated to processing your job. You can view an instance's usage on the [Instances](https://quantum.cloud.ibm.com/instances) page.\n",
+    "*   Open Plan users can use up to 10 minutes of quantum usage per 28-day rolling window. Quantum usage is the amount of time that the QPU is dedicated to processing your job. You can view an instance's usage on the [Instances](https://quantum.cloud.ibm.com/instances) page.\n",
     "\n",
     "## Next steps\n",
     "\n",
     "<Admonition type=\"tip\" title=\"Recommendations\">\n",
-    "    - [Workload usage](estimate-job-run-time).\n",
-    "    - Review these tips: [Minimize job run time](minimize-time).\n",
+    "    - [Workload usage](/docs/guides/estimate-job-run-time).\n",
+    "    - Review these tips: [Minimize job run time](/docs/guides/minimize-time).\n",
     "</Admonition>"
    ]
   }

docs/guides/minimize-time.mdx

@@ -1,14 +1,14 @@
 ---
 title: Minimize job run time
-description: How to minimize the amount of quantum time spent processing and running a job.
+description: How to minimize the amount of quantum usage spent processing and running a job.
 
 ---
 
 # Minimize job run time
 
 There are several ways you can limit the amount of time spent processing and running a job:
 
-- Run only as many shots as you need: The quantum time a job takes (and therefore, its cost) scales with the number of shots. Therefore, you can manage your cost by running only as many shots as you need. For Estimator jobs, lower precision typically requires more shots and therefore longer execution time.
+- Run only as many shots as you need: The resource consumption a job uses (and therefore, its cost) scales with the number of shots. Therefore, you can manage your cost by running only as many shots as you need. For Estimator jobs, lower precision typically requires more shots and therefore a longer execution time.
 
 - Set limits on execution time:  You can limit how long each job, batch, or session runs.  For details, see [Maximum execution time for Qiskit Runtime workloads](max-execution-time).