First spotted by Windows Latest, Microsoft just announced that Bing sign-in now works with Google and Apple accounts. No new Microsoft account required. The company says this should make it easier to sign in and get to “personalized experiences,” specifically calling out Microsoft Rewards, and they shared a direct link to try the new flow.

Ten years of pushing everyone toward a Microsoft account, and Bing just quietly opened its front door to Google and Apple instead. Bing was never supposed to work this way. We reported a few weeks ago that Microsoft is giving the ability to sign in to Edge using a Google account. The tech giant is essentially admitting the fact that most people don’t want to use a Microsoft account, and giving options to users is never a bad thing.

No need for a Microsoft account to use Bing search

Less than a month ago, when I tested signing into Edge with a Google account, I noticed how Microsoft Rewards got activated even without logging in with a Microsoft Account. I thought it was a bug, but now I realize it was a feature.

To try the new Bing yourself, head to Bing.com, hit sign in, and below the usual email-or-phone field sit two new buttons, Continue with Google and Continue with Apple.

Since the death of Windows Phone, Microsoft has no way to get people to default to Bing for web searches on mobile, and considering that’s the form factor where the most search takes place, giving Android and iPhone users the ability to use their existing Google or Apple accounts to log in to a different Search engine from the one their manufacturer recommends seems like a genius move from Microsoft.

Hands-on with the new Bing sign-in options

Clicking Google would take you to the familiar Google account picker page, but for some weird reason, it shows Sign in to continue using Microsoft Copilot. Same with Apple. If Microsoft’s goal is to get people to actually sign into Bing, then I’d recommend changing Copilot to Bing.

Fortunately, even after signing in, it’s Bing that treats us and not Copilot. Either way, a Microsoft account doesn’t get created in the background, unlike before, where if you entered a gmail.com address, it quietly turned into an MSA.

What happens to Bing now?

My take here is that Bing has essentially become a separate product that is by all means Microsoft, but also not tying you to Microsoft in the traditional sense. When you try to sign in to any website or a SaaS product, you’ll be asked to sign in with a Google, Microsoft, or Apple account. Bing has become such a product.

Imagine Google making YouTube sign-in possible with a Microsoft account, or Apple allowing Apple Maps to be logged in with a Microsoft Account. These companies cannot fathom associating their flagship services with their competitor’s email. Microsoft just did, and I would call this a landmark move from the company. If anything, this would help Bing become a more popular Search engine, and I sure hope it does because Google has been misusing its monopoly for quite a long time.

Microsoft Rewards drops its Microsoft account requirement too

All points you make in Microsoft Rewards, and every gift card redemption, have run through a Microsoft account. It’s only expected, and Microsoft has been throwing absurd money at it lately, a $1,000,000 cash sweepstakes and Mercedes-Benz cars included, all to get more people to sign up for an MSA and start searching on Bing.

The whole customer acquisition machine depended on people being willing to create a Microsoft account before they could enter the draw. For anyone already living inside Google’s ecosystem through Android or Gmail, that step was probably the real dealbreaker. Now it’s gone. Sign into Rewards with the same Google account already on your phone, and you’re earning points without MSA bothering you.

Funnily enough, I’d bet this single change moves more people into Rewards than the million-dollar sweepstakes ever did.

Bing features can be used without a Microsoft account

In case you didn’t know it already, Bing has a ton of features apart from being a Search engine. Bing Video Creator, Image Creator, Translator, AI Tools, Video Search, Bing News, Bing Maps, Bing Wallpaper, Bing Travel, Shopping, and a lot more are now possible without a Microsoft Account, and I wonder how Microsoft plans to make a profit out of these.

Microsoft opening the door for Google is the strange part

Microsoft spent years engineering Bing to trap people inside its ecosystem, sometimes in ways that bordered on deceptive. We reported in May that Bing was still spoofing Google’s homepage, a year and a half after the backlash started, showing a fake minimalist Google-style search box that runs a Bing search the moment you type into it. It’s a company baiting Google users.

And yet weeks later, Bing hands those Google users an official sign-in button. Windows 11 Search just picked up a toggle to kill Bing web results entirely, and in my testing it was noticeably faster once Bing stops interfering with local results.

Even Microsoft Edge’s own account got compliments from Mac users, and they’ll have all the more reason to use both Edge and Bing.

Of course, Microsoft being a profit-hungry machine, don’t expect any of this to be charity. Bing just crossed a billion monthly users, and Microsoft has clearly figured out that number climbs faster once the sign-in wall comes down than it did through seven-figure sweepstakes. Every extra signed-in Bing user, Google account or not, is still someone Microsoft can nudge toward Copilot later.

For now, the practical bit is that if a Microsoft account was the only thing keeping you off Bing, Microsoft Rewards, or its Copilot-powered creative tools, that excuse just disappeared.

The post Microsoft is letting you sign into Bing with a Google or Apple account, no MSA needed appeared first on Windows Latest

Microsoft has reportedly started transitioning away from OpenAI and Anthropic AI models in an attempt to cut costs.

The post Microsoft is Reportedly Transitioning to In-House AI Models appeared first on Thurrott.com.

API specification drift is one of those failure modes that’s invisible until it isn’t. The OpenAPI document says one thing, the running service does another, and somewhere downstream a client breaks because a field your team renamed two sprints ago never made it back into the contract.

The hardest part isn’t finding the difference. The hardest part is answering: which side is actually correct? Should the specification change to match the implementation, or should the implementation change to honor the published contract? And, more importantly: what else breaks if we change it?

We ran an experiment to see how AI agents handle this. Two agents, one prompt:

Identify all API spec drift. Ensure the API contract is valid.

One was Claude Code with the Postman plugin installed, bringing Postman capabilities directly into the developer workflow. The other was the Postman AI Engineer, running natively with the Postman Context Graph. Same repository, same request, two different approaches — and the result reveals something important about AI-assisted development: the quality of an agent’s answer depends on the context it can access.

What API specification drift means

API drift happens when the behavior of an API no longer matches its specification. A response adds a required field but the schema is never updated. A status code changes from 200 to 201. A parameter that was optional quietly becomes required. Individually, these changes might seem harmless. Together, they break the contract that consumers build against.

Contract testing helps teams catch these gaps, but detecting drift is only the first step. The harder question is whether the contract should move or the code should move — and that decision needs context.

The experiment

We pointed both agents at the same API project and ran the same prompt: Identify all API specification drift. Ensure the API contract is valid. Here’s what happened.

Both PRs removed the drift and both were technically valid. They also solved two different problems.

Why the agents disagreed

Claude Code with the Postman plugin uses Model Context Protocol tools to bring Postman capabilities into the IDE. That bridge gives Claude direct access to API artifacts and workflows while it reasons across the codebase, files, and implementation context in the repository.

The Postman AI Engineer approaches the same problem from another dimension. Built on the Postman Context Graph — a continuously updated map of APIs, collections, specifications, environments, workspaces, governance rules, and the relationships between them — it can reason about more than syntax. Instead of only asking “Does this code match this specification?”, it can ask:

What does this API mean to this organization?

That distinction matters because APIs are not implementation details. They’re formal contracts that encode how systems, teams, and business capabilities interact.

Moving from “does this match the spec” to “what does this API mean to the organization” expands the evaluation context. A single endpoint may represent payments, provisioning, identity, or data consistency, so a change can have downstream effects far beyond a code diff.

This broader lens catches issues that static validation misses — breaking consumer assumptions, violating SLAs, or altering business-critical behavior. The result is fewer production regressions and less rework because decisions are made with system-wide context, not line-level correctness.

A real example: a code change that looks correct but breaks the API ecosystem

Imagine a developer adds pagination to an endpoint. The implementation changes:

GET /customers

Now returns:

{
  "customers": [
    {
      "id": "123",
      "name": "Acme"
    }
  ],
  "next_cursor": "abc123"
}

The developer updates the OpenAPI file. Everything looks good. A code-focused agent can validate that the endpoint works, the schema matches the implementation, and the tests pass.

But the Context Graph reveals something else. The endpoint is referenced by:

• a customer onboarding collection
• an internal billing workflow
• a partner-facing collection
• a mock server used by frontend developers
• contract tests owned by another team

One consumer is still expecting the old response shape. The implementation change is correct. The specification update is correct. The API ecosystem is still broken.

The Context Graph surfaces the relationships that are invisible from the repository alone. This is the difference between changing an API and understanding an API.

Why context is the bottleneck for AI coding agents

AI models keep getting more capable. The limiting factor is usually not reasoning ability — it’s access to the right context.

A repository tells an agent what code exists, how services are implemented, and what files changed. It usually doesn’t tell an agent which APIs are consumed by other teams, which collections represent real workflows, which specifications are published, which environments validate production behavior, or which changes violate governance rules.

That context lives outside the codebase. It lives across the API lifecycle, and the Postman Context Graph connects those signals.

Claude Code + Postman: different strengths, stronger together

This isn’t a comparison where one agent replaces the other. Claude Code brings powerful reasoning directly into the developer environment, and the Postman plugin lets developers work with Postman resources and API workflows without leaving their IDE. The Postman AI Engineer adds API lifecycle intelligence through the Context Graph.

Together, Claude helps answer “How should I change the code?” while the Postman AI Engineer helps answer “Should this change happen, and what else does it affect?”

The future of AI engineering isn’t one universal agent — it’s specialized agents with the context they understand best.

What this experiment shows

The experiment started as a simple comparison and turned into a lesson about context. Models aren’t the only factor. Code context shows implementation; API context shows impact. The Postman Context Graph provides the missing layer: how APIs connect across teams, consumers, and systems. That’s what moves AI from generating changes to making informed engineering decisions.

Try it yourself

If you have the integration for Slack set up, you can ask the Postman AI Engineer to analyze drift directly:

@Postman Identify all API specification drift.

To reason about the same drift from inside Claude Code, install the Postman plugin and run setup:

claude plugin install postman
claude
> /postman:setup
> Compare the OpenAPI specification in api/openapi.yaml against the implementation
  in services/. Identify any drift and show both sides before suggesting a fix.

Then compare what each agent surfaces. If the answers diverge from what your team would have done, that’s a signal worth investigating — usually it means a governance rule isn’t encoded yet, or the specification is missing a constraint that everyone has internalized but nobody wrote down.

The goal isn’t to find differences. The goal is to understand why they exist — and make changes that preserve the systems built around your APIs.

Resources

• Announcing the Postman plugin for Claude Code
• Introducing the Postman AI Engineer
• Postman Spec Hub documentation
• Postman MCP server overview
• Contract testing in Postman
• Postman API Governance
• OpenAPI specification
• Model Context Protocol specification
• Claude Code documentation

The post We Gave Two AI Agents the Same API Spec Drift Problem. The Difference Was Context. appeared first on Postman Blog.