DEV Community: Burak Unuvar

GPT-5.6 Luna on Foundry: PTU Sizing, PayGo vs. PTU + Spillover Pricing

Burak Unuvar — Sun, 30 Aug 2026 13:33:25 +0000

A quick note before we start: While this article focuses on GPT-5.6 Luna to make the pricing and PTU calculations concrete, the same methodology applies to other models when their model-specific throughput and pricing values are substituted.

Provisioned Throughput provides a dedicated, fixed amount of processing capacity exclusively for your model deployment. Unlike Standard/PayGo, it provides a model-specific latency SLA, and its capacity is not shared across tenants.

PTU is a good fit for predictable, sustained traffic with consistent latency and high-throughput requirements.
PTU quota is model-independent, so the same quota pool can be allocated across supported models. Throughput per PTU remains model- and version-specific.
PTU quota is granted per subscription, region, and deployment type. Quota in East US does not carry over to West Europe, and Global Provisioned quota does not carry over to Data Zone Provisioned.

PTU Sizing and Estimation

Input	Description
Model and Version	The model determines which Input TPM per PTU and output-to-input ratio values to use. Each model has a minimum PTU count and specific PTU throughput.
Deployment type	The provisioned deployment type: Global Provisioned, Data Zone Provisioned, or Regional Provisioned.
Peak RPM	The expected peak number of calls per minute sent to the model.
Average prompt size	The average number of input tokens per request.
Average response size	The average number of output tokens per request.
Cache rate	The percentage of input tokens served from the prompt cache. Cached tokens don't consume any PTU capacity.

FORMULAS
`Input TPM` = `Peak RPM` × `Average input tokens per request`
`Output TPM` = `Peak RPM` × `Average output tokens per request`
`Effective Input TPM` = `Input TPM` × (1 - `Cache rate`)
`Normalized TPM` = `Effective Input TPM` + (`Output-to-input ratio` × `Output TPM`)
`Estimated PTUs` = `Normalized TPM` / `Input TPM per PTU`

Note: Input TPM is the workload-specific calculated volume, whereas Input TPM per PTU is a model-specific sizing constant. For example, some listed Input TPM per PTU values are 30,000 for GPT-5.6 Luna, 3,000 for GPT-5.6 Terra, and 1,200 for GPT-5.6 Sol.

Sample Pricing Calculations for GPT-5.6 Luna on Microsoft Foundry

Representative sample:

Let's suppose your application sends requests at a peak rate of 1,000 RPM, with an average prompt size of 1,200 tokens and an average response size of 200 tokens, using the gpt-5.6-luna model with a Global Provisioned deployment.

Based on the Microsoft Foundry PTU sizing table, gpt-5.6-luna has these constants:

GPT-5.6 LUNA SIZING CONSTANT	VALUE
Input TPM per PTU	30,000
Output-to-input ratio	6
Minimum Global Provisioned deployment	15 PTUs
Global Provisioned scale increment	5 PTUs

1. Without Prompt Caching

CALCULATION
`Input TPM` = 1,000 × 1,200 = 1,200,000
`Output TPM` = 1,000 × 200 = 200,000
`Normalized TPM` = 1,200,000 + (6 × 200,000) = 2,400,000
`Estimated PTUs` = 2,400,000 / 30,000 = 80 PTUs
`PTUs deployed` = 80 PTUs

2. With a 50% Prompt-Cache Hit Rate

CALCULATION
`Input TPM` = 1,000 × 1,200 = 1,200,000
`Effective Input TPM` = 1,200,000 × (1 - 0.50) = 600,000
`Output TPM` = 1,000 × 200 = 200,000
`Normalized TPM` = 600,000 + (6 × 200,000) = 1,800,000
`Estimated PTUs` = 1,800,000 / 30,000 = 60 PTUs
`PTUs deployed` = 60 PTUs

Peak RPM	Prompt size	Response size	Cache rate	Effective Input TPM	Output TPM	Normalized TPM	Estimated PTUs	PTUs deployed
1,000	1,200	200	0%	1,200,000	200,000	2,400,000	80.00	80
1,000	1,200	200	50%	600,000	200,000	1,800,000	60.00	60

Notes and Remarks

For this simplified example, each representative prompt is assumed to contain 1,200 tokens. This exceeds the 1,024-token minimum for prompt caching. A cache hit also requires at least the first 1,024 tokens to be identical across requests.
Prompt caching is also available for Provisioned Throughput deployments. Cached input tokens don't consume PTU capacity. In this example, caching reduces the calculated requirement from 80 PTUs to 60 PTUs—a reduction of 20 PTUs (25%). Both values are above the 15-PTU minimum and divisible by the 5-PTU scale increment.
No additional rounding is required in this example. Rounding would be required if an estimate fell below the 15-PTU minimum or between supported 5-PTU increments; for example, 62.4 PTUs would be rounded up to 65 PTUs.

Handling Spiky Traffic

Illustrative 24-Hour RPM Profile and 30-Day Estimate

Representative sample: Let's suppose traffic fluctuates between 0 and 2,500 RPM over a typical 24-hour period, with an average input size of 1,200 tokens and an average response size of 200 tokens, using the gpt-5.6-luna model with a Global Standard (pay-as-you-go) deployment. For the 30-day estimate, this daily traffic profile is assumed to repeat every day.

We'll also assume that 50% of input tokens are cache reads and the remaining 50% are cache misses. Of all input tokens, 10 percentage points are cache writes, leaving 40 percentage points as regular input that is neither read from nor written to the cache. Prompt caching applies only to input tokens; output tokens are always charged at the regular output-token rate.

Illustrative RPM distribution over 24 hours
(RPM changes every 4 hours)

2500 ┤                         ██████
2250 ┤                         ██████
2000 ┤                         ██████  ██████
1750 ┤                         ██████  ██████
1500 ┤                         ██████  ██████
1250 ┤                         ██████  ██████
1000 ┤                 ██████  ██████  ██████  ██████
 750 ┤                 ██████  ██████  ██████  ██████
 500 ┤         ██████  ██████  ██████  ██████  ██████
 250 ┤         ██████  ██████  ██████  ██████  ██████
   0 ┼─────────────────────────────────────────────────
HOUR │ 00–04 │ 04–08 │ 08–12 │ 12–16 │ 16–20 │ 20–24
 RPM │     0 │   500 │ 1,000 │ 2,500 │ 2,000 │ 1,000

1. PayGo-Only Cost Calculation

For Standard/PayGo rates, as of August 27, 2026, the Azure OpenAI pricing page lists these USD rates for gpt-5.6-luna Global Standard:

Meter	Symbol	Price per 1M tokens
Regular input	`P_regular`	$0.20
Cached input	`P_cached`	$0.02
Cache writes	`P_write`	$0.25
Output	`P_output`	$1.20

50% cache reads + 10% cache writes + 40% regular input = 100%

Symbol	Description
`RPM`	Requests per minute
`a.i.T`, `a.o.T`	Average input and output tokens per request
`Hours`	Duration of the batch in hours
`r_cached`, `r_write`	Cache-read and cache-write rates
`C_batch`	Total input-and-output token cost for one batch

Formula	Calculation
Total input tokens	`T_input` = `RPM` × `a.i.T` × 60 × `Hours`
Cached input tokens	`T_cached` = `T_input` × `r_cached`
Cache-write input tokens	`T_write` = `T_input` × `r_write`
Regular input tokens	`T_regular` = `T_input` - `T_cached` - `T_write`
Total output tokens	`T_output` = `RPM` × `a.o.T` × 60 × `Hours`
Batch cost	`C_batch` = (`T_regular`·`P_regular` + `T_cached`·`P_cached` + `T_write`·`P_write` + `T_output`·`P_output`) / 1,000,000

Each column represents one 4-hour batch on a typical day. The daily traffic profile is assumed to repeat itself for 30 days. Token values are shown in billions (B).

Metric	00–04	04–08	08–12	12–16	16–20	20–24	Total per day
Batch duration	4 hours	4 hours	4 hours	4 hours	4 hours	4 hours	24 hours
RPM	0	500	1,000	2,500	2,000	1,000	—
`T_regular`	0	0.05760B	0.11520B	0.28800B	0.23040B	0.11520B	0.80640B
`T_cached`	0	0.07200B	0.14400B	0.36000B	0.28800B	0.14400B	1.00800B
`T_write`	0	0.01440B	0.02880B	0.07200B	0.05760B	0.02880B	0.20160B
`T_output`	0	0.02400B	0.04800B	0.12000B	0.09600B	0.04800B	0.33600B
`C_4-hour batch`	$0.00	$45.36	$90.72	$226.80	$181.44	$90.72	$635.04

30-day token totals:

Regular input (T_regular): 24.19200B

Cached input (T_cached): 30.24000B

Cache writes (T_write): 6.04800B

Output (T_output): 10.08000B

Estimated pay-as-you-go cost per day: $635.04.

Estimated cost per 30-day month: $19,051.20.

Estimated cost per 365-day year: $231,789.60.

2. PTU + Spillover to PayGo Cost Calculation

The following Sweden Central PTU rates were retrieved on August 27, 2026, using the Azure Retail Prices API. Sample queries and commands are included in the Appendix as a reference.

Tier	Retail API rate	Monthly equivalent per PTU
Hourly PTU	$1.00/PTU/hour	$720.00
Monthly reservation	$260.00/PTU/month	$260.00
One-year reservation	$2,652.00/PTU/year	$221.00

The hourly PTU monthly equivalent assumes 720 hours (30 days).

Warning: Hourly, non-reserved PTU is best suited to temporary or uncertain workloads, such as testing, benchmarking, capacity validation, short pilots, or migration exercises.

2.A Provisioned Baseline of 250 RPM

Let's take 250 RPM as the provisioned baseline and use Standard/PayGo spillover for bursts above it.

CALCULATION
`Input TPM` = 250 × 1,200 = 300,000
`Effective Input TPM` = 300,000 × (1 - 0.50) = 150,000
`Output TPM` = 250 × 200 = 50,000
`Normalized TPM` = 150,000 + (6 × 50,000) = 450,000
`Estimated PTUs` = 450,000 / 30,000 = 15 PTUs
`Provisioned baseline` = 15 PTUs

Time	Incoming RPM	Normalized TPM Demand	15-PTU Capacity (Normalized TPM)	Potential Spillover Demand
00–04	0	0	450,000	0
04–08	500	900,000	450,000	450,000
08–12	1,000	1,800,000	450,000	1,350,000
12–16	2,500	4,500,000	450,000	4,050,000
16–20	2,000	3,600,000	450,000	3,150,000
20–24	1,000	1,800,000	450,000	1,350,000

Incoming traffic ──▶ 15-PTU deployment (450,000 normalized TPM capacity)
                  X
                  X if throttled (HTTP 429)
                  │
                  └──▶ Automated Spillover to Standard/PayGo deployment if configured

Important: Spillover is optional and must be configured either for the provisioned deployment or per request. Once configured, Microsoft Foundry automatically routes eligible requests that the provisioned deployment cannot serve—such as requests receiving HTTP 429, 500, or 503—to the associated Standard deployment. Without this configuration, the application must implement its own fallback logic.

Provisioned-Capacity Pricing for 15 PTUs

Pricing option	Retail API rate	1 PTU/month	15 PTUs/month	15 PTUs/day (approx.)
Hourly PTU	$1.00/PTU/hour	$720.00	$10,800.00	$360.00
Monthly reservation	$260.00/PTU/month	$260.00	$3,900.00	$130.00
One-year reservation	$2,652.00/PTU/year	$221.00	$3,315.00	$108.99

Monthly cost of a yearly PTU reservation is an approximate equivalent calculated by dividing the annual price by 12.

Daily cost of a yearly PTU reservation is an approximate equivalent calculated by dividing the annual price by 365.

Daily cost of monthly PTU reservation is a rough estimation calculated by dividing the monthly price by 30.

Monthly Reserved PTU + PayGo Spillover Pricing

Metric	00–04	04–08	08–12	12–16	16–20	20–24	Daily total
Incoming RPM	0	500	1,000	2,500	2,000	1,000	—
Estimated spillover RPM	0	250	750	2,250	1,750	750	—
`T_regular`	0	0.02880B	0.08640B	0.25920B	0.20160B	0.08640B	0.66240B
`T_cached`	0	0.03600B	0.10800B	0.32400B	0.25200B	0.10800B	0.82800B
`T_write`	0	0.00720B	0.02160B	0.06480B	0.05040B	0.02160B	0.16560B
`T_output`	0	0.01200B	0.03600B	0.10800B	0.08400B	0.03600B	0.27600B
`C_PTU reservation`	$21.67	$21.67	$21.67	$21.67	$21.67	$21.67	$130.00
`C_PayGo spillover`	$0.00	$22.68	$68.04	$204.12	$158.76	$68.04	$521.64
`C_PTU + spillover`	$21.67	$44.35	$89.71	$225.79	$180.43	$89.71	$651.64

Daily estimate using a monthly reservation: The $3,900 monthly PTU reservation amortizes to $130.00 per day over a 30-day month. Estimated PayGo spillover is $521.64 per day, for a combined daily estimate of $651.64.

30-day estimate using a monthly reservation: PTU reservation $3,900.00; PayGo spillover $15,649.20; combined cost $19,549.20.

365-day estimate using a one-year reservation: PTU reservation $39,780.00; PayGo spillover $190,398.60; combined cost $230,178.60.

Interval amounts are rounded independently. Daily and longer-term totals are calculated using unrounded values. Actual throughput and costs can vary with request concurrency, token-length distribution, caching behavior, model version, regional pricing, and throttling characteristics.

2.B Provisioned Baseline of 500 RPM

Let's take 500 RPM as the provisioned baseline and use Standard/PayGo spillover for bursts above it.

CALCULATION
`Input TPM` = 500 × 1,200 = 600,000
`Effective Input TPM` = 600,000 × (1 - 0.50) = 300,000
`Output TPM` = 500 × 200 = 100,000
`Normalized TPM` = 300,000 + (6 × 100,000) = 900,000
`Estimated PTUs` = 900,000 / 30,000 = 30 PTUs
`Provisioned baseline` = 30 PTUs

Time	Incoming RPM	Normalized TPM Demand	30-PTU Capacity (Normalized TPM)	Potential Spillover Demand
00–04	0	0	900,000	0
04–08	500	900,000	900,000	0
08–12	1,000	1,800,000	900,000	900,000
12–16	2,500	4,500,000	900,000	3,600,000
16–20	2,000	3,600,000	900,000	2,700,000
20–24	1,000	1,800,000	900,000	900,000

Incoming traffic ──▶ 30-PTU deployment (900,000 normalized TPM capacity)
                  X
                  X if throttled (HTTP 429)
                  │
                  └──▶ Automated Spillover to Standard/PayGo deployment if configured

Important: Spillover is optional and must be configured either for the provisioned deployment or per request. Once configured, Microsoft Foundry automatically routes eligible requests that the provisioned deployment cannot serve—such as requests receiving HTTP 429, 500, or 503—to the associated Standard deployment. Without this configuration, the application must implement its own fallback logic.

Provisioned-Capacity Pricing for 30 PTUs

Pricing option	Retail API rate	1 PTU/month	30 PTUs/month	30 PTUs/day (approx.)
Hourly PTU	$1.00/PTU/hour	$720.00	$21,600.00	$720.00
Monthly reservation	$260.00/PTU/month	$260.00	$7,800.00	$260.00
One-year reservation	$2,652.00/PTU/year	$221.00	$6,630.00	$217.97

Monthly cost of a yearly PTU reservation is an approximate equivalent calculated by dividing the annual price by 12.

Daily cost of a yearly PTU reservation is an approximate equivalent calculated by dividing the annual price by 365.

Daily cost of monthly PTU reservation is a rough estimation calculated by dividing the monthly price by 30.

Monthly Reserved PTU + PayGo Spillover Pricing

Metric	00–04	04–08	08–12	12–16	16–20	20–24	Daily total
Incoming RPM	0	500	1,000	2,500	2,000	1,000	—
Estimated spillover RPM	0	0	500	2,000	1,500	500	—
`T_regular`	0	0	0.05760B	0.23040B	0.17280B	0.05760B	0.51840B
`T_cached`	0	0	0.07200B	0.28800B	0.21600B	0.07200B	0.64800B
`T_write`	0	0	0.01440B	0.05760B	0.04320B	0.01440B	0.12960B
`T_output`	0	0	0.02400B	0.09600B	0.07200B	0.02400B	0.21600B
`C_PTU reservation`	$43.33	$43.33	$43.33	$43.33	$43.33	$43.33	$260.00
`C_PayGo spillover`	$0.00	$0.00	$45.36	$181.44	$136.08	$45.36	$408.24
`C_PTU + spillover`	$43.33	$43.33	$88.69	$224.77	$179.41	$88.69	$668.24

Daily estimate using a monthly reservation: The $7,800 monthly PTU reservation amortizes to $260.00 per day over a 30-day month. Estimated PayGo spillover is $408.24 per day, producing a combined daily estimate of $668.24.

30-day estimate using a monthly reservation: PTU reservation $7,800.00; PayGo spillover $12,247.20; combined cost $20,047.20.

365-day estimate using a one-year reservation: PTU reservation $79,560.00; PayGo spillover $149,007.60; combined cost $228,567.60.

Interval amounts are rounded independently. Daily and longer-term totals are calculated using unrounded values. Actual throughput and costs can vary with request concurrency, token-length distribution, caching behavior, model version, regional pricing, and throttling characteristics.

PayGo Only vs. 15 PTUs + PayGo Spillover vs. 30 PTUs + PayGo Spillover

Period and pricing basis	PayGo only	250-RPM baseline (15 PTUs) + spillover	Difference vs. PayGo	500-RPM baseline (30 PTUs) + spillover	Difference vs. PayGo
Daily — monthly reservation	$635.04	$651.64	+$16.60 (+2.61%)	$668.24	+$33.20 (+5.23%)
30-day month — monthly reservation	$19,051.20	$19,549.20	+$498.00 (+2.61%)	$20,047.20	+$996.00 (+5.23%)
365-day year — one-year reservation	$231,789.60	$230,178.60	−$1,611.00 (−0.70%)	$228,567.60	−$3,222.00 (−1.39%)

With monthly reservation pricing, PayGo-only is the least expensive option. The 250-RPM baseline costs $498.00 more per 30-day month, while the 500-RPM baseline costs $996.00 more.

With one-year reservation pricing, the result reverses. The 250-RPM baseline saves $1,611.00 per year relative to PayGo-only, while the 500-RPM baseline saves $3,222.00 per year. Under this representative traffic profile, the 500-RPM baseline therefore provides the lowest annual cost of the three options.

Key Takeaway

If cost is the primary objective, use PTUs to cover the workload's stable, sustained baseline and route variable or burst traffic to PayGo. Avoid reserving PTUs for capacity that may remain idle; each additional PTU block should save more in PayGo charges than it costs to reserve.

That said, cost is not the only objective of PTUs. A correctly sized provisioned deployment also provides dedicated throughput, more predictable latency, a defined latency SLA, and more consistent benchmark results than shared PayGo capacity. The best choice therefore depends on both economics and performance requirements.

Billing and Reservation: Some Lessons Learnt by Blood

You are billed on PTUs deployed, not tokens processed: an idle deployment costs exactly the same as a saturated one. Deployments cannot be paused, so under hourly billing, charges stop only when the deployment is deleted.

Hourly billing charges per PTU per hour, prorated for partial hours. Use it for benchmarking, evaluation, and short-lived capacity.
Azure Reservations discount the effective PTU rate for a one-month or one-year commitment. This is the intended mode for sustained production workloads.

Reservations and deployments are created independently, with two consequences:

A reservation is a billing discount, not a capacity guarantee. Create the deployment first to confirm capacity exists, then reserve the PTUs you actually deployed.
If that deployment is later scaled down or deleted, the reservation keeps billing its original quantity. Deployed PTUs below it become unused coverage; PTUs above it bill at the hourly rate.

Scaling down also releases capacity back to the regional pool with no guarantee of reclaiming it, so cycling a production deployment up and down is a poor cost-control strategy. A reservation on a steady deployment is usually cheaper and safer.

References and Further Reading

Appendix

How to Query the Pricing API for This Example

{
    curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=productName%20eq%20%27Azure%20OpenAI%27%20and%20armRegionName%20eq%20%27swedencentral%27"

    curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=productName%20eq%20%27Azure%20AI%20Foundry%20Provisioned%20Throughput%20Reservation%27%20and%20armRegionName%20eq%20%27swedencentral%27"
} | jq -rs '
    ["Pricing option", "USD / PTU", "Reservation term"],
    (
        .[].Items[]
        | select(.skuName == "Provisioned Managed Global")
        | [
                (if .reservationTerm == null
                 then "Hourly"
                 else .reservationTerm
                 end),
                .retailPrice,
                (.reservationTerm // "None")
            ]
    )
    | @tsv'

FireConnect Open Models from MS Foundry to GH Copilot, or any other AI Coding Harness

Burak Unuvar — Sun, 16 Aug 2026 21:37:19 +0000

❓ Impressed by the latest open-source model benchmarks and eager to use those models in GitHub Copilot?

❓ Using several AI coding tools and tired of configuring bring-your-own-key (BYOK) access separately in each one?

🔥 FireConnect is an open-source CLI that connects agentic coding tools to open-source model families such as Llama, Qwen, DeepSeek, Kimi, and GLM.

💡 A reminder about native GH Copilot models

At the time of writing, GitHub Copilot already supports 30 models, including open models such as Kimi K3.

FireConnect becomes useful when you want:

Faster access to an expanding range of models
One configuration pattern across coding tools (GitHub Copilot, Claude Code, Cursor)
Install once, sign in once, then flip any supported harness on or off without hand-editing config files

What is Fireworks and FireConnect?

💡 Fireworks AI is a high-performance inference and fine-tuning platform focused on open-source models such as Llama, Qwen, DeepSeek, Kimi, and GLM.

💡 Microsoft announced Fireworks AI as an official first-party inference provider inside Foundry in March 2026.

💡 FireConnect is the bridge between your AI coding harness and the model ecosystem, letting you plug in models your tool does not natively offer without changing how you work.

🤔 Wait, aren't open models already available on Foundry?

Yes, Microsoft Foundry already offers a rich catalog of models, including open source models sold directly by Azure. Fireworks provides an alternative inference path for many of those models at a quicker pace. Fireworks brings its own rapidly evolving catalog backed by an optimized inference platform that's directly integrated into Foundry.

Some examples:

Model	Direct from Azure	Via Fireworks on Foundry
Kimi K3	❌ No	✅ Yes
GLM 5.2	❌ No	✅ Yes
Kimi K2.7 Code	✅ Yes	✅ Yes
DeepSeek V4 Pro	✅ Yes	✅ Yes

🤔 Looks like just another way of Bring Your Own Key (BYOK), do I really need FireConnect ?

If you only need a custom model for GH Copilot CLI or GH Copilot inside VS Code, BYOK is more than enough and works great!

FireConnect becomes much more interesting when you use multiple AI coding harnesses—such as GitHub Copilot, Cursor, Claude Code, Codex, or others—and want a more consistent way to connect and route them to models available through Fireworks AI. Instead of configuring every harness independently against different model-provider interfaces, FireConnect provides a common integration layer across supported tools.

FireConnect will fit in perfectly when you need a single control plane across multiple AI coding tools such as GH Copilot, Cursor, Claude Code and others.

When to Use Which Approach?

Use-Case Built-in providers and Extensions Custom Endpoint with FireConnect

Use a single model in VS Code chat ✅ Just add your key and go Works, but overkill for this

Use the same Fireworks models across Copilot, Cline, Continue, etc. ❌ Set up each tool separately ✅ One setup — toggle harnesses on/off

Get Fireworks latency and routing out of the box ❌ Generic endpoint, you're on your own ✅ Built for Fireworks, tuned for their infrastructure

Get your whole team on the same model config ❌ Everyone sets it up manually ✅ Shared config that anyone can reproduce

Use-Case	Built-in providers and Extensions	Custom Endpoint with FireConnect
Use a single model in VS Code chat	✅ Just add your key and go	Works, but overkill for this
Use the same Fireworks models across Copilot, Cline, Continue, etc.	❌ Set up each tool separately	✅ One setup — toggle harnesses on/off
Get Fireworks latency and routing out of the box	❌ Generic endpoint, you're on your own	✅ Built for Fireworks, tuned for their infrastructure
Get your whole team on the same model config	❌ Everyone sets it up manually	✅ Shared config that anyone can reproduce

Warning

FireConnect provides technical integration between Claude Code and Fireworks models through an Anthropic-compatible endpoint. But, this is not an Anthropic-endorsed configuration, and Anthropic does not provide support for routing Claude Code to non-Claude models through third-party gateways.

So maybe as a fun fact we can say:

Claude Code can technically be configured to go outside the Claude family to make most out of open weighted models, but Anthropic currently doesn't like this 😁

How to Get Started

Prerequisites

An active Azure subscription with the Fireworks integration enabled. See the Fireworks on Foundry setup guide.
A Microsoft Foundry project and a deployment of your preferred open-weight model from the Fireworks model catalog.

Step 1: Set Up the Foundry Resource and Project

Before running the Azure CLI commands, create a local .env file in the repository root. These variables are used by the commands below.


RESOURCE_GROUP=my-fireconnect-rg

AZURE_REGION=eastus

FOUNDRY_RESOURCE_NAME=my-fireconnect-foundry

PROJECT_NAME=my-fireconnect-project

MODEL_NAME=FW-GLM-5.2

BASE_URL=https://<your-resource-name>.services.ai.azure.com/

AZURE_API_KEY=your_key


# Load the variables into your current Bash session.

set -a

source .env

set +a

# create the resource group

az group create \\

  --name "$RESOURCE_GROUP" \\

  --location "$AZURE_REGION"

# Create the Microsoft Foundry resource.

az cognitiveservices account create \\

  --name "$FOUNDRY_RESOURCE_NAME" \\

  --resource-group "$RESOURCE_GROUP" \\

  --location "$AZURE_REGION" \\

  --kind AIServices \\

  --sku S0 \\

  --custom-domain "$FOUNDRY_RESOURCE_NAME" \\

  --yes

# Create the Microsoft Foundry project.

az cognitiveservices account project create \\

  --project-name "$PROJECT_NAME" \\

  --name "$FOUNDRY_RESOURCE_NAME" \\

  --resource-group "$RESOURCE_GROUP" \\

  --location "$AZURE_REGION"

Step 2: Deploy a Fireworks Model on Foundry

Model benchmarks evolve frequently. For this example, I’ll use GLM-5.2 from Z.ai, which ranked among the strongest open-weight coding models in recent evaluations. See the GLM-5.2 benchmark analysis.


# Inspect the model format.

MODEL_NAME="FW-GLM-5.2"

MODEL_INFO=$(az cognitiveservices account list-models \\

  --name "$FOUNDRY_RESOURCE_NAME" \\

  --resource-group "$RESOURCE_GROUP" \\

  | jq --arg MODEL "$MODEL_NAME" '.[] | select(.name == $MODEL)')

echo "$MODEL_INFO"

# Deploy the model.

az cognitiveservices account deployment create \\

  --resource-group "$RESOURCE_GROUP" \\

  --name "$FOUNDRY_RESOURCE_NAME" \\

  --deployment-name "$MODEL_NAME" \\

  --model-format "Fireworks" \\

  --model-name "$MODEL_NAME" \\

  --model-version "1" \\

  --sku-name "DataZoneStandard" \\

  --sku-capacity 100

Step 3: Install, Upgrade, and Configure FireConnect

Install FireConnect, then configure its global VS Code settings:


# Install FireConnect.

curl -fsSL https://raw\.githubusercontent.com/fw-ai/fireconnect/main/install.sh | bash

fireconnect upgrade

# Configure the global FireConnect settings.

fireconnect configure \\

  --provider azure \\

  --base-url "$BASE_URL" \\

  --api-key "$AZURE_API_KEY"

fireconnect vscode on --model FW-GLM-5.2

fireconnect vscode status

Start or restart VS Code, open Copilot Chat, and pick a Fireworks model from the model picker.

For one-off routing without changing the global configuration, pass your Foundry model with --model (for example, FW-GLM-5.2), not a Fireworks serverless short ID.


fireconnect vscode on \\

  --azure \\

  --base-url "$BASE_URL" \\

  --model FW-GLM-5.2

To disable or uninstall FireConnect:


# Disable FireConnect for VS Code.

fireconnect vscode off

# Uninstall FireConnect for VS Code.

fireconnect uninstall

🔐 BYOK in Depth

BYOK IN DEPTH

Bring your own key (BYOK) allows you to use Copilot with models of your choice: local or hosted by an external provider. GitHub Copilot supports BYOK at two levels:

Feature	Enterprise BYOK	Local BYOK
Who configures it	Enterprise / Org owner	Individual developer
Where keys live	Server-side (GitHub)	Client-side only
Copilot license needed?	Yes	No
Works offline / air-gapped?	❌ No	✅ Yes

Local BYOK works across multiple surfaces:

VS Code	JetBrains IDEs	Xcode	Copilot CLI	GitHub Copilot App	Copilot SDK
✅ GA	✅ Public preview	✅ Public preview	✅ Supported	✅ Supported	✅ Supported

BYOK to GH Copilot in VS Code and FireConnect

VS Code offers different ways to add language models:

Provider option	What it means
Built-in providers	The provider is already listed (Azure, Anthropic, Gemini, OpenAI, and others)
Extensions	A marketplace extension provides the model (e.g., AI Toolkit for local models)
Custom endpoint	You have a self-hosted or enterprise endpoint that speaks Chat Completions, Responses, or Messages API

💡 FireConnect is configured through custom endpoints.

📚 References

References

1. FireConnect overview

2. GitHub Copilot model availability

3. Fireworks AI model catalog

4. Fireworks AI on Microsoft Foundry

5. FireConnect GitHub repository

6. Models sold directly by Azure

7. Enable Fireworks models on Foundry

8. Available Fireworks catalog models

9. GLM-5.2 benchmark analysis

10. FireConnect installer

11. VS Code BYOK language models

12. GitHub Copilot CLI BYOK providers

GitHub Agentic Workflows for Guardrailed Automation

Burak Unuvar — Sat, 08 Aug 2026 22:27:11 +0000

❓ Have you found your self orchestrating multiple coding agents across different harnesses, screens, surfaces? How many at most can you track and monitor simultaneously? 😫

❓ Did you ever give up on approving permission asks and started running all of them on YOLO mode ? Please try not to do that, at least not in production, agents can easily get out control and dangerous! 😱

Although I love all the magic and efficiency AI Coding Tools are bringing to my life, I'm a bit overwhelmed recently, trying to achieve tens maybe hundreds of tasks! Some really deserve my full attention and active steering to achieve the best possible outcome, while for most, the judgement of a model is more than enough.

In order to bring intelligent and controlled automation to my Github Repositories, I hired octopus students 🐙 🐙 🐙

GitHub Agentic Workflows(GH-AW).

What is GH-AW?

Disclaimer: GitHub Agentic Workflows a.k.a. GH-AW is an open-source GitHub CLI extension developed by GitHub. It is announced in February 2026 by GitHub Next and Microsoft Research, still in public preview but already widely adopted by Microsoft itself as well as many other organizations.

GH-AW enables running the coding agents you know and love such as GitHub Copilot, Claude Code, OpenAI Codex, or Google Gemini in GitHub Actions. Consider them as intelligent systems embedded directly into your CI/CD 💡 They all run within pre-defined guardrails, using safe outputs and sandboxed execution.

Some of the use cases are :

Repository Maintenance with Issue Triages, PRs Reviews
Continuous Documentation maintenance and consistency
Metrics & Analytics for daily reports and workflow health monitoring
Test improvements, CI failure diagnosis, quality checks

Hmm, what does it really address ?

👍 Do you want to gather daily activity data, analyze all the PRs and issues, check workflow results, and creates status report in form of issues ? Enable Daily Repo Status

👍 Do you want to automatically assign issues labeled cookie to the Copilot coding agent every 30 minutes? Enable Issue Monster.

Above are only two examples from a sample family of reusable pre-baked workflows maintained by Github Next, called agentics. There're plenty of interesting ones such as CI Doctor to Monitor CI workflows or Grumpy Reviewer for On-demand opinionated code review by a grumpy but thorough senior developer.

These may be useful, what else ?

👍 Do you have an automation in mind that you could describe entirely in natural language? Then you can create custom agentic workflows for that !

Whether it’s fixing a simple bug, creating and running tests on a schedule, fetching data from the web to keep your documentation up to date, or something entirely different.

How does it work ?

Agentic Workflow: From Prompt to Execution

                                         gh aw compile
┌──────────────────────┐  ┌──────────────────────┐  ┌──────────────────────┐
│  1. YOUR PROMPT      │  │  2. GH-AW            │  │  3. GH-AW COMPILER   │
│                      │  │   CUSTOMAGENT        │  │                      │
│  /agentic-workflows  │  │  Creates workflow.md │  │  Validates source    │
│  "Create a workflow" │──►  using its skill     │──►  Injects runtime     │
│                      │  │                      │  │  Generates YAML      │
│                      │  │  - schedule          │  │                      │
│                      │  │  - permissions       │  │  workflow.lock.yml   │
│                      │  │  - safe outputs      │  │                      │
│                      │  │  - task brief        │  │                      │
└──────────────────────┘  └──────────────────────┘  └───────────┬──────────┘
                                                                │
           ┌───────────────────── commit + push ────────────────┘
           ▼
┌──────────────────────┐                     ┌──────────────────────┐
│  4. GITHUB ACTIONS   │                     │  5. GITHUB REPO      │
│                      │                     │                      │
│  Launches agent      │                     │  Issues / PRs / code │
│  Executes task       │   ───────►          │                      │
│  Posts safe outputs  │                     │                      │
│                      │                     │                      │
└──────────────────────┘                     └──────────────────────┘

Why is this really a thing , can't I just build my own custom agents ?

Yes of course you can - sky is the limit ! But enforcing what they can do access and affect can can quite trickly. GH-AW runs within an isolated sandbox with Read-Only permissions, prevents Prompt Injection and is authorized to write only what you let.

When to use which: Github Actions VS Github Agentic Workflows

⚠️ A better question would be "How to use both together". 💡

Agentic workflows are complementary; your deterministic build, test, and release pipelines stay unchanged. Github Actions requires YAML configuration for fully deterministic systems. Agentic workflows use AI to interpret natural language instructions in markdown. Think of it as Continuous AI alongside CI/CD: a new automation layer in GitHub Actions for tasks where exact reproducibility doesn’t matter.

How can I start ?

Quick Start with Github CLI
A github repo to experiment some pre-built and 2 custom workflows
Disclaimer: Please don't hate me in case of errors 😃 and please feel free to submit issues or contribute 🤗
Are you looking something for advanced, a zero to hero style workshop ? gh-aw-workshop

Last but not least, here comes the main source of all information and updates GitHub Agentic Workflows 🚀 🚀 🚀