@@ -1,6 +1,6 @@
 ---
 title: Billing and usage
-intro: There are usage limits for {% data variables.product.prodname_actions %} workflows. Usage charges apply to repositories that go beyond the amount of free minutes and storage for a repository.
+intro: Understand which {% data variables.product.prodname_actions %} usage is included with your plan, when charges apply, and which usage limits administrators can manage.
 redirect_from:
   - /actions/getting-started-with-github-actions/usage-and-billing-information-for-github-actions
   - /actions/reference/usage-limits-billing-and-administration
 
@@ -97,7 +97,18 @@ To get started with custom images, see [AUTOTITLE](/actions/how-tos/manage-runne
 
 ## Cloud hosts used by {% data variables.product.prodname_dotcom %}-hosted runners
 
-{% data variables.product.prodname_dotcom %} hosts Linux and Windows runners on virtual machines in Microsoft Azure with the {% data variables.product.prodname_actions %} runner application installed. The {% data variables.product.prodname_dotcom %}-hosted runner application is a fork of the Azure Pipelines Agent. Inbound ICMP packets are blocked for all Azure virtual machines, so ping or traceroute commands might not work. {% data variables.product.prodname_dotcom %} hosts macOS runners in Azure data centers.
+{% data variables.product.prodname_actions %} uses a multi-cloud compute pool to help improve runner availability for eligible Linux jobs. These jobs can run on either Amazon Web Services (AWS) or Microsoft Azure.
+
+Multi-cloud compute is used for standard 2-core and 4-core Linux runners and compatible 2-core and 4-core {% data variables.actions.hosted_runners %} without specialized configurations. It does not apply to Windows runners or runners with private networking or other specialized configurations. Jobs are automatically scheduled across available cloud providers.
+
+> [!NOTE] If you used {% data variables.product.prodname_dotcom %}-hosted Linux runners before multi-cloud compute was introduced, existing runner labels and workflow syntax remain unchanged.
+
+<!-- Before publication, confirm GHE.com availability: the release description and later release discussion conflict. -->
+Eligible runners on {% data variables.product.prodname_free_user %}, {% data variables.product.prodname_pro %}, and {% data variables.product.prodname_team %} automatically use multi-cloud compute. Enterprises on {% data variables.product.prodname_ghe_cloud %} can opt in. See [AUTOTITLE]({% ifversion ghec %}/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enabling-multi-cloud-compute{% else %}/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enabling-multi-cloud-compute{% endif %}).
+
+If your workflows depend on network allowlists or Azure SDK credentials, running on a different cloud provider can cause connection or authentication failures. Review [IP address requirements](/actions/reference/runners/github-hosted-runners#ip-addresses) and [Azure SDK authentication troubleshooting](/actions/how-tos/troubleshoot-workflows#azure-sdk-authentication-failures).
+
+{% data variables.product.prodname_dotcom %} hosts Windows runners and Linux runners that don't use multi-cloud compute on virtual machines in Azure. Inbound ICMP packets are blocked for Azure virtual machines, so ping or traceroute commands might not work. {% data variables.product.prodname_dotcom %} hosts macOS runners in Azure data centers.
 
 ## Workflow continuity
 
 
@@ -57,7 +57,7 @@ For more information on configuring {% data variables.actions.hosted_runners %}
 ## Billing
 
 > [!NOTE]
-> {% data variables.actions.hosted_runner_caps %}s are not eligible for the use of included minutes on private repositories. For both private and public repositories, when {% data variables.actions.hosted_runners %} are in use, they will always be billed at the per-minute rate.
+> Where available, {% data variables.actions.hosted_runner %} costs can draw from the included compute usage for accounts on {% data variables.product.prodname_team %} and {% data variables.product.prodname_ghe_cloud %}. After the included value is consumed, usage is billed at the per-minute rate. Usage in public repositories is also billed at the per-minute rate.
 
 Compared to standard {% data variables.product.github %}-hosted runners, {% data variables.actions.hosted_runners %} are billed differently. {% data reusables.actions.about-larger-runners-billing %} For more information, see [AUTOTITLE](/billing/reference/actions-runner-pricing).
 
@@ -68,4 +68,3 @@ To start using larger runners, see [AUTOTITLE](/actions/how-tos/manage-runners/l
 To find reference information about using {% data variables.actions.hosted_runners %}, see [AUTOTITLE](/actions/reference/runners/larger-runners).
 
 {% endif %}
-
@@ -9,19 +9,17 @@ category:
 contentType: concepts
 ---
 
-> [!NOTE] {% data reusables.actions.workflow-lockfiles-preview %}
-
 ## Why lock workflow dependencies?
 
-When a workflow references an action by a tag or branch, such as `uses: octo-org/deploy-action@v3` or `uses: octo-org/deploy-action@main`, {% data variables.product.prodname_actions %} resolves that reference to whatever commit the tag or branch points to at run time.
+Workflows often reference an action by a tag or branch, such as `uses: octo-org/deploy-action@v3` or `uses: octo-org/deploy-action@main`. {% data variables.product.prodname_actions %} resolves that reference to whatever commit the tag or branch points to at run time.
 
-Tags and branches can move, so the code that runs is not guaranteed to be the code that the workflow author originally reviewed. If an upstream maintainer's account is compromised and a tag is repointed, your repositories could run malicious code.
+Tags and branches can move. As a result, the code that runs is not guaranteed to be the code that the workflow author originally reviewed. If an upstream maintainer's account is compromised and a tag is repointed, your repositories could run malicious code.
 
-A workflow dependency lockfile pins a commit SHA to every action (including transitive dependencies) and reusable workflow your workflows depend on. This gives you:
+A workflow dependency lockfile pins a commit SHA to every action your workflows depend on, including transitive dependencies. It doesn't pin calls to reusable workflows (`jobs.<job_id>.uses`). To pin a reusable workflow, reference it by its full commit SHA. A lockfile controls which action code runs on the runner. It doesn't control other build inputs, such as input parameters, secrets, or the runner image. A lockfile gives you the following for the action code it covers:
 
-* Reproducible builds
+* Reproducible resolution of action dependencies
 * Reviewable dependency changes and {% data variables.product.prodname_dependabot %} version updates
-* An auditable inventory of your CI/CD systems' dependencies
+* An auditable inventory of your CI/CD systems' action dependencies
 
 ## How does the lockfile work?
 
@@ -30,9 +28,10 @@ The lockfile is defined in a repository at `.github/workflows/actions.lock`. It'
 You can onboard a repository's workflows to the lockfile one at a time or all at once. After a workflow is onboarded:
 
 * Every action dependency the workflow uses must be present in the lockfile.
-* The locked commit is what runs when the workflow executes, and what allowed actions policies check. This commit must exist within a branch of the source repository.
+* The locked commit is what runs when the workflow executes, and what allowed actions policies check.
+* This commit must be reachable from the branch or tag recorded for it in the lockfile, in the action's own repository. A commit that exists only in a fork, or that's no longer reachable from that branch or tag, is rejected when the workflow runs.
 
-A lockfile covers the workflows in its own repository. It extends to transitive dependencies (actions that _your action dependencies_ use), **except** for dependencies of reusable workflow calls. A reusable workflow is covered by the lockfile of the repository where it is defined.
+A lockfile covers the workflows in its own repository, including transitive dependencies (actions that _your action dependencies_ use), **except** for dependencies of reusable workflow calls. Reusable workflows can have their own lockfiles too. A reusable workflow's dependencies are covered by the lockfile of the repository where it's defined, not by the lockfile of the repository that calls it.
 
 ## What does the lockfile record?
 
@@ -41,7 +40,8 @@ The lockfile has two sections. `workflows` records which dependencies each onboa
 ```yaml
 # This file is machine-generated by `gh actions-lock`.
 # Do not edit by hand; run `gh actions-lock` to update.
-version: 'v0.0.2'
+# Docs: https://gh.io/actions-lockfile
+version: 'v0.0.3'
 workflows:
     '.github/workflows/ci.yml':
         - 'octo-org/deploy-action@v3.1.0'
@@ -55,13 +55,21 @@ dependencies:
 
 Each dependency records:
 
-* **`ref`**: The reference the workflow uses, such as a tag or branch.
+* **`ref`**: The tag or branch the commit was resolved from.
 * **`commit`**: The exact commit the reference resolved to. This is the code that will run.
 * **`owner_id` and `repo_id`**: The numeric identity of the source repository. {% data variables.product.prodname_actions %} uses these to confirm at run time that the repository behind the name is still the one you locked.
 
+This structured format gives tools like {% data variables.product.prodname_dependabot %} a machine-readable record they can use to manage dependency updates, without relying on YAML comments as version annotations.
+
 ## How do lockfiles compare with SHA pinning?
 
-{% data variables.product.github %} has historically recommended pinning third-party actions to a full-length commit SHA in your workflow files. For repositories that adopt a lockfile, SHA pinning within workflow files is **no longer necessary**. The lockfile is the better option because it supports transitive dependencies, makes workflow files easier to read, and records the identity of the source repository.
+{% data variables.product.github %} has historically recommended pinning third-party actions to a full-length commit SHA in your workflow files. For repositories that adopt a lockfile, SHA pinning within workflow files is **no longer necessary**. The lockfile is the better option because it:
+
+* Supports transitive dependencies
+* Makes workflow files easier to read
+* Records the identity of the source repository
+
+A lockfile also satisfies the separate **Require actions to be pinned to a full-length commit SHA** policy for workflows that are onboarded to it. See [AUTOTITLE](/actions/how-tos/administer/control-workflow-execution#require-lockfile).
 
 ## Next steps
 
 
@@ -12,7 +12,7 @@ category:
 
 By default, {% data variables.product.prodname_actions %} allows multiple jobs within the same workflow, multiple workflow runs within the same repository, and multiple workflow runs across a repository owner's account to run concurrently. This means that multiple instances of the same workflow or job can run at the same time, performing the same steps.
 
-{% data variables.product.prodname_actions %} also allows you to disable concurrent execution. This can be useful for controlling your account’s or organization’s resources in situations where running multiple workflows or jobs at the same time could cause conflicts or consume more Actions minutes and storage than expected. For example, you might want to prevent multiple deployments from running at the same time, or cancel linters checking outdated commits.
+{% data variables.product.prodname_actions %} also allows you to disable concurrent execution. This can be useful for controlling your account’s or organization’s resources in situations where running multiple workflows or jobs at the same time could cause conflicts or consume more runner compute and storage than expected. For example, you might want to prevent multiple deployments from running at the same time, or cancel linters checking outdated commits.
 
 {% ifversion actions-nga %}
 
 
@@ -82,11 +82,17 @@ Event rules control which events are permitted, such as `push`, `pull_request`,
 
 ### Require lockfile
 
-The **Require lockfile** protection blocks runs of workflows with `uses:` dependencies on other actions, unless the dependencies are pinned in a dependency lockfile. This ensures that the targeted workflows run predictable, vetted code, rather than whatever a tag or branch points to at run time. See [AUTOTITLE](/actions/concepts/security/workflow-dependency-lockfiles).
+The **Require lockfile** protection blocks runs of targeted workflows that aren't onboarded to the repository's lockfile. This way, the targeted workflows run vetted, predictable code, instead of whatever a tag or branch points to at run time. This protection, and lockfiles in general, only cover actions called at the step level (`jobs.<job_id>.steps[*].uses`). They don't cover reusable workflows called at the job level (`jobs.<job_id>.uses`). If a called reusable workflow isn't onboarded to the lockfile in its own repository, this protection blocks the calling workflow's run. See [AUTOTITLE](/actions/concepts/security/workflow-dependency-lockfiles).
 
 Generate and verify lockfiles in the repositories you're targeting before you set this protection to **Active**. Otherwise, you'll block workflow runs in repositories that aren't ready. For a staged rollout, see [AUTOTITLE](/actions/how-tos/administer/enforce-workflow-lockfiles).
 
-You can keep **Require actions to be pinned to a full-length commit SHA** enabled when adopting lockfiles. For dependencies covered by a lockfile, {% data variables.product.github %} evaluates this requirement using the locked commit SHA. Keeping the policy enabled during a staged rollout preserves SHA-pinning enforcement for workflows that have not yet adopted lockfiles.
+You can keep the separate **Require actions to be pinned to a full-length commit SHA** policy enabled when adopting lockfiles. A lockfile satisfies the SHA-pinning requirement for workflows that are onboarded to a lockfile.
+
+Both policies are independent checks, and a workflow run must pass both when they're both enabled:
+
+* A workflow that is in the lockfile passes both policies, with no SHAs needed in the workflow file.
+* A workflow that isn't in the lockfile, with `uses:` references pinned to a full-length commit SHA, passes SHA pinning but is blocked by **Require lockfile**.
+* A workflow that isn't in the lockfile, with `uses:` references to a tag or branch, is blocked by both policies.
 
 {% endif %}