Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
164808 stories
·
33 followers

Content Understanding adds GPT-5.6, GPT-6, and GPT-6.1: Choose the right model for your workload

1 Share

Azure Content Understanding now supports the GPT-5.6, GPT-6, and GPT-6.1 model families, giving you more choices for document, text, speech, and video workflows. This adds to the existing set of supported models like the GPT-5 series. To help customers understand how to use this expanded set of options, we’re updating our model recommendations and sharing the evaluation data behind them.

In our GPT-5 model-selection guide, we described model selection as a mixing board: adjust quality and cost for each workload. The new models add range to those controls. Not every workload needs to be set to maximum, so we’ll share data here to help you make the call.

Choose your starting settings

For standard document extraction, start with GPT-6.1 Sol. Add GPT-6 Luna when token cost matters most, and test GPT-6 Astra when a small quality improvement could justify a premium.

Your priority Starting point Why
Balanced quality and token cost GPT-6.1 Sol Close to the GA accuracy leader; leads the separate Preview extraction evaluation.
Maximum accuracy, premium budget GPT-6 Astra and Sol Often similar quality to Sol, with a small GA extraction lead and a substantial token premium.
Low token cost GPT-6 Luna Much lower token spend, with a quality trade-off to test on your documents.

It’s important to say that outcomes vary widely depending on the task. Pick some options based on our evaluations, then test these choices on your own task. The best balance varies with the content and the work you need done.

Default to Sol; test Astra where errors are expensive

Sol and Astra often deliver similar quality, with the advantage depending on the workload. Astra has a small lead in GA document extraction (95.95% vs. Sol’s 95.74% for Schema only), and the gap narrows with examples (0.11 percentage points for With 5 labeled examples).

LLM match means using an LLM to judge whether extracted field values match the expected values.

Astra comes at a substantial premium: about five times Sol’s completion-token expense in these document tests. That can be worth testing when Sol’s remaining errors lead to expensive review or incorrect downstream decisions.

For demanding documents, compare the two rather than assuming the premium model wins. In the Preview extraction evaluation, Sol leads Astra instead (96.06% vs 95.58% for Schema only; 97.10% vs 97.06% for With 5 labeled examples).

Try examples before turning up the model budget

Content Understanding can run an analyzer with just a schema describing the fields you want, without any example documents. Or add example documents to its knowledge base and label the expected answers.

In Content Understanding Studio, use Knowledge to connect those documents and review or correct their labels. Our tests compare Schema only and With 5 labeled examples.

That gives you another control on the mixing board before changing models. Adding five labeled examples improves Luna’s extraction quality (91.82% to 94.16%), while its token expense remains much lower than Sol’s in these tests.

For high-volume processing, that makes Luna with knowledge worth testing before paying for a larger model. Savings aren’t automatic: examples add tokens and preparation costs, and quality must hold up on documents you didn’t use as examples.

Give each task its own channel

The previous guide’s central lesson still applies: the strongest document model isn’t necessarily the strongest video or speech model. Keep the mixing-board settings separate when the job changes.

  • Document segmentation: Astra leads the GA benchmark (98.00% Segment F1 vs Sol’s 97.10%). Segmentation splits a file into logical documents, so test it is separately from extracting fields.
  • Video: Among the nine compared models, GPT-6 Sol has the highest observed headline video Generation F1 (86.40% ± 0.70 percentage points) and the highest Long-video segmentation mean (80.10% ± 1.20 percentage points). GPT-6.1 Sol shows the best results on Short-video ads scoring 93.60% ± 0.40 percentage points. Its relative weakness is concentrated in long videos.
  • Speech: GPT-5.2 has the highest GA field-classification mean, while GPT-5.5 leads field generation. Those measure structured fields from audio, not transcription. We will update this post as we do additional investigation as to whether there is really significant differences between these speech tasks as those with video and documents.

F1 balances finding the expected results with avoiding incorrect ones. Each task has its own scoring rules, so don’t combine these percentages into a single model ranking.

Explore the data, not another wall of charts

Choose Document, Text, Speech, or Video, then a task. Hover, tap, or focus a model to inspect it; document extraction shows Schema only and With 5 labeled examples together.

Measurement note: Graphs show GA evaluation averages. Token expense compares model input/output charges using measured usage and the evaluation’s rates, relative to Sol with Schema only (1.00×); it excludes service processing and other charges that are the same independent of model choice.

Use the billing explanation and current rates for your workload budget. The explorer keeps the task-specific metrics and qualifications beside the data.

Loading the interactive chart. If it does not appear, use the link below.

Open the interactive chart in a separate tab

&

So what should teams do next?

The expanded catalog gives every channel on the mixing board a wider range. The next step is to choose two or three candidates for your workload and test which combination of quality, cost, availability, and throughput deserves the final setting.

Keep the comparison simple:

  • Start with Sol for document extraction; compare Luna when cost matters and Astra when remaining errors justify the experiment.
  • Use the same analyzer, schema, representative input set, and labeled examples for every run.
  • Change only the model deployment, then compare output quality, latency, token usage, and failure rate.
  • Before testing, check the analyzer’s supported models and confirm that each candidate is available in the region(s) that you care about.

Start in Content Understanding Studio

  1. In Content Understanding Studio, open Settings, add your Foundry resource, and configure its default model deployments. Studio can deploy required models automatically when no suitable default exists.
  2. Follow the Content Understanding Studio quickstart to select an analyzer and run it on your own representative content.
  3. Test each candidate against the same files. Review the extracted fields and raw response, and record the quality, latency, and usage that matter to your workload.

Or compare deployments through the REST API

For a repeatable evaluation, pass a different modelDeployments mapping in each analyze request. A request-level mapping overrides the resource defaults, so you can keep the analyzer and inputs unchanged while swapping the completion deployment. For example, you can call:

POST /contentunderstanding/analyzers/myInvoice:analyze

{
  "inputs": [
    {
      "url": "<representative-input-url>"
    }
  ],
  "modelDeployments": {
    "prebuilt-analyzer-completion": "<candidate-deployment-name>",
    "prebuilt-analyzer-embedding": "<embedding-deployment-name>"
  }
}

Run the same request once per candidate, then compare the extracted results and the response’s usage data. Start with the balanced recommendation, add the lower-cost option, and include the best-quality model only when the remaining accuracy gap matters to the workflow.

The post Content Understanding adds GPT-5.6, GPT-6, and GPT-6.1: Choose the right model for your workload appeared first on Microsoft Foundry Blog.

Read the whole story
alvinashcraft
34 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Introducing CNCF User Groups: Long-lived homes for End User collaboration

1 Share

The CNCF End User Community is launching its User Group Program at KubeCon + CloudNativeCon North America. These are long-lived groups, each built around an industry vertical or problem domain, that serves the common need of the end user community, and reports directly to the CNCF Technical Advisory Board (TAB).

Why user groups

Cloud native adoption looks different in a telecom network, a research lab, a public agency and a platform team at a software company. Each has its own constraints, vocabulary and gaps in the tooling landscape. A CNCF User Group gives each of those communities a durable place to organize around its own needs, rather than relying on one-off efforts that fade after a single project or event.

A User Group is the primary organizational unit of the program. It is aligned with an industry vertical, a problem domain, or a common need of the CNCF end user community, and it is long-lived by design: user groups perform standing functions for projects and the organizations that adopt them. Each group:

  • Represents and serves the needs of end users in its domain
  • Identifies gaps in the CNCF project portfolio and helps attract projects to fill them
  • Educates users with unbiased, practical information scoped to cloud native
  • Proposes community-sourced reference architectures, best practices and how-tos for publication
  • Gives CNCF projects feedback on usability, reliability and performance

User groups also come with accountability. Every group operates under a charter, is led by chairs approved by the TAB, holds at least one public monthly meeting that is recorded and posted to YouTube, and reports regularly on its health and work to the TAB. Groups are also expected to show up at KubeCon + CloudNativeCon, whether through talks, booths or ecosystem updates.

Technical Community Groups and User Groups: what’s the difference?

The program is designed as a path, not a single door. Technical Community Groups (TCGs) are the lightweight starting point: part of the broader CNCF Community Groups Program, they act as a rallying point where practitioners discuss a topic, share knowledge and coordinate possible future initiatives. User Groups are the long-lived, chartered layer on top.

Technical Community GroupUser Group
PurposeDiscussion, knowledge sharing and a rallying point around a topic or domainStanding, long-term coverage of an industry vertical or problem domain
GovernanceMinimal; follows the Community Groups process, plus TAB approvalCharter required; reports directly to the TAB
LeadershipOrganizers (2-year terms)Chairs approved by the TAB (2-year terms)
MeetingsOne meet-up every 90 daysAt least one public monthly meeting, recorded and posted to YouTube
ReportingMinimalPeriodic health and initiative updates to the TAB; KubeCon presence expected
Scope of workFree to propose initiatives with an explicit deliverableStanding functions, plus initiatives, white papers and reference architectures

The governance model expects most future user groups to begin life as community groups. A TCG that wants to graduate must have completed numerous initiatives, cover a gap not already served by an existing group, and win TAB approval. The group then drafts a charter with defined scope, and the TAB votes on it. Once the vote passes, the user group is formed. Source: User Group Governance.

One on-ramp, two destinations

Community groups are a shared on-ramp across CNCF. Where a TCG lands depends on its focus. End user-driven domains such as an industry vertical go to the TAB and become User Groups. Project-focused domains go to the Technical Oversight Committee (TOC) and can become a Technical Advisory Group (TAG). The governance documents tell TCG organizers to talk to the TOC and TAB chairs early, so the group lands in the right place.

The TAG path has the same shape as the User Group path. A TCG applying to become a TAG must have completed numerous initiatives, cover a gap in the currently defined groups, have a documented history of collaboration with its parent group, and be approved by the TOC. The group then drafts a charter, the TOC votes on it, and the TAG is formed once the vote passes. Source: Tech Group Governance.

Platform Engineering: from TCG to User Group

The Platform Engineering community shows how that path works in practice. It started life as a Working Group under the previous TAG App Delivery, became a Technical Community Group during the TAG restructuring last year, and is now transitioning to a User Group. Over time, the group moved from conversation to output, including the Platform Engineering Maturity Model and the Platforms White Paper.

Becoming a User Group changes what the community can do. It now has a TAB-approved charter, a direct reporting line to the TAB, a standing public monthly meeting, and a formal role in representing platform engineering end users across the CNCF ecosystem. Its focus areas include internal developer platforms, golden paths, self-service capabilities, platform as a product, developer experience, and operational practices such as GitOps and policy as code.

“Being recognized as a CNCF User Group is an exciting milestone for us. It validates years of dedication from our community members and provides the elevated visibility we need to bring in new ideas, attract fresh talent, and continue shaping the future of Platform Engineering together.”

– Chris Plank aka Planko

Four user groups, and room to grow

The program launches with four groups, each serving a distinct end user community:

  • Platform Engineering: Cloud native collaboration for platform engineering end users
  • Public Sector: Cloud native collaboration for public-sector end users
  • Research: Cloud native collaboration for research organizations and scientific workloads
  • Telecom: Cloud native collaboration for telecom end users

New groups are formed when there is a documented, outstanding gap in coverage of a technical domain within cloud native. If your community fits that description, the path starts with a conversation with the TAB. Community groups that have a track record of completed initiatives are the natural candidates.

Meet the Platform Engineering User Group at KubeCon

The best way to see what a user group does is to meet the people in it. Stop by the Platform Engineering User Group kiosk on Day 1, Tuesday, November 10, from 3:00 PM to 7:00 PM at P-16B. Talk with the group about your platform challenges, hear how the move from TCG to user group came together, and find out how to get involved.

Can’t make it to the show floor? You can join the conversation any time:

Also at KubeCon: the Public Sector User Group

Working in or alongside government or another regulated environment? The Public Sector User Group has two sessions this week, back to back:

  • Public Sector User Group Meetup: Cloud Native in the Public Sector is an informal, social meetup with no slides or agenda. Meet the co-chairs and other members, swap stories about deploying cloud native technology in regulated environments, and learn how to get involved.
  • Public Sector User Group BoF: Roadmap, White Papers, Our Group is a Birds of a Feather session led by co-chairs William Crum and Daniel Moch. It covers the group’s mission and roadmap, its white papers published and in progress, and how it works with the TAB. They will also ask for help with current work and open a discussion on the biggest adoption challenges in the public sector.

Both ancillaries are aimed at government employees, contractors and service members. Can’t make it? The group meets biweekly on Wednesdays at 2:00 PM US/Eastern. Find the details on the Public Sector User Group page, the CNCF community page, or in #ug-public-sector on CNCF Slack.

Read the whole story
alvinashcraft
36 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Node.js 26.13.1 (LTS)

1 Share
Read the whole story
alvinashcraft
36 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Node.js 24.22.3 (LTS)

1 Share
Read the whole story
alvinashcraft
36 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Node.js 22.23.5 (LTS)

1 Share
Read the whole story
alvinashcraft
36 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Migrate a GitHub repository to GitHub Enterprise

1 Share

This posts shows how to migrate a repository from GitHub.com to GitHub Enterprise Cloud (GHE.com). The migration transfers the repository and its associated data to the GitHub Enterprise environment while preserving project continuity and maintaining access for authorized users.

Step 1: Install required tools for the GitHub migration.

Install the required tools for the GitHub migration in advance, including PowerShell and the GitHub CLI (gh). Ensure both tools are installed and available from the command line.

winget install --id GitHub.cli --source winget

gh extension install github/gh-gei

https://cli.github.com

Step 2: Create the GitHub.com, GHE.com Access Tokens

Create a Personal Access Token (Classic) on GitHub.com/ghe.com for both the source and destination. Ensure that you select Personal access tokens (classic) and not a fine-grained personal access token, as the migration process requires a classic PAT. When creating the token, grant the required permissions as specified for the migration and store the token securely, as it will only be displayed once. (Personal access tokens (classic))

Source:

https://github.com/settings/tokens

Select the required source scopes:

  • repo
  • admin:org

Destination:

Do the same for the destination GitHub Enterprise:

https://{your-enterprise}.ghe.com/settings/tokens

Required scopes for the destination:

  • repo
  • workflow
  • admin:org

Step 3: Configure SSO

Ensure that SSO is configured and authorized for both Personal Access Tokens (PATs) in the GitHub UI. Select the correct SSO for the target and destinations GitHub enterprises.

Step 4: Migrate the repository

I use Powershell for this. Add the two tokens:

$env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"

Run the migration using the correct parameters for your setup.

gh gei migrate-repo --github-source-org SOURCE 
     --source-repo CURRENT-NAME 
     --github-target-org DESTINATION 
     --target-repo NEW-NAME 
     --target-api-url "TARGET-API-URL"

Step 5: Validate the new repository and delete the tokens

Validate that the repository was correctly migrated and delete the two PAT from GitHub and GHE.

Notes, troubleshooting

If you get this error the following error, configure the SSO for your PAT.

[2026-11-09 13:10:54] [ERROR] Resource protected by organization SAML enforcement. 
You must grant your Personal Access token access to this organization.

PR Error: Adjust the GHE settings.

Error during migration: Git source migration failed. Error message: Push error: Errors reported by remote:
error: GH013: Repository rule violations found for refs/heads/main.
error: GH013: Repository rule violations found for refs/github-services/pull/1/head.
References rejected by remote:
main => push declined due to repository rule violations
refs/github-services/pull/1/head => push declined due to repository rule violations

FIX:

Open the Enterprise and reset the repository settings.

https://{your-ghe}.ghe.com/enterprises/{–name–}

enterprises/{your-ghe}/settings/policies/repositories

Disable all the custom defined rulesets and do the migration. When complete re-enable the rulesets.

Already exists:

[WARNING] The Org ‘{org-name}’ already contains a repository with the name ‘RepoName’. No operation will be performed

Delete the repository in the destination GHE organisation.

Links

https://docs.github.com/en/migrations/using-github-enterprise-importer/migrating-between-github-products/migrating-repositories-from-githubcom-to-github-enterprise-cloud

https://docs.github.com/en/migrations/using-ghe-migrator

https://github.com/cli/cli/blob/trunk/docs/install_windows.md#winget



Read the whole story
alvinashcraft
37 minutes ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories