Unfortunately, none of this is explained in the announcement, but the documentation [0] is pretty good.

[0]: https://docs.typesafe.ai/concepts/how-to-build-with-system-o...

  from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
  
  with TypeSafeClient() as client:
      response = client.system_one(
          state={"document": "I was charged twice. Please fix this ASAP."},
          questions={
              "billing": Noul(instructions="Is this ticket about billing?"),
              "tone": Choice(
                  instructions="What is the customer's tone?",
                  criteria={"calm": None, "frustrated": None, "angry": None},
              ),
              "urgency": Score(
                  instructions="How urgent is this ticket?",
                  criteria=["can wait", "this week", "today"],
              ),
          },
      )
  
  print(response.nouls["billing"].noul)
  print(response.choices["tone"].choice)
  print(response.scores["urgency"].score)

The same model hosted by other providers is much more expensive [0]. So either DeepSeek can host it much cheaper than anyone else, or their business model is different. I suspect the latter, especially since their privacy policy [1] says personal data, including “User Input,” can be used "To improve and develop the Services and to train and improve our technology".

[0]: https://openrouter.ai/deepseek/deepseek-v4-pro/providers

[1]: https://cdn.deepseek.com/policies/en-US/deepseek-privacy-pol...

Inference stack efficiency: Many of these providers take off the shelf sglang / vllm / trtllm and hope for the best. Meanwhile DeepSeek team is known for pushing the boundary of optimizations.

Now, sglang and vllm are great pieces of software, but take DeepSeek's Sparse Attention (DSA). Introduced 1.5 years ago (https://arxiv.org/abs/2512.02556), used by DeepSeek 3.2, GLM 5, DeepSeek V4. Only now is it slowly strating to get optimized in the major inference engines: (https://github.com/sgl-project/sglang/issues/19380 https://github.com/sgl-project/sglang/pull/22851 etc.). Of course, DS V4 adds extra optimizations into the model architecture on top of DSA, and those will take more time to be taken full advantage of by the open source inference engines.

Privacy: Betting that people will pay extra for inference hosted outside China. This is especially true with DeepSeek, because DeepSeek is transparent about using API data for model improvements.

And few other things (scale (matters a lot for MoEs), reliability, soft enterprise lock in, etc.)

---

There is also, likely, tacit collusion at play here. Look at GLM 5 and GLM 5.1 prices. GLM 5 and 5.1 cost the same to run, but providers decided to charge much more for 5.1 because it is much better model, and because Z.AI raised their price as well.

But I agree that the main driver is that they are really good at optimizing. They will have chosen their architecture in such a way that it will be as efficient as possible on their own infrastructure, so they have a massive head start. Inference framework developers still have to catch up.

I'd love to give these models a try, but I'd rather not use a provider that trains on or stores my data (beyond standard legal requirements of course).

https://www.inceptron.io/models

Though to be honest, I'm not sure I want to trust business workflows to a website where the only contact is a Gmail address and no physical contact address. That site looks incredibly dodgy.

But why not? Gaining market share at a loss isn't the US's patent.

Loss leading only works when

- it leads to a situation that allows you to prevent competitors from selling to your customers (gilded age railroad and pipeline industries are great examples). Then you can eventually raise prices and not lose back any market share.

- or when it allows you to remarket to customers and make back the difference (selling a single console at a loss to sell a whole library of high margin videos games, or selling jet engines at a loss to lock in 30-year maintenance contracts).

Also, in case of LLM, market share = more people uploading their whole codebase/legal documents/unfinished books/literally everything to your servers for you to use in future training. So the incentive to sell at a loss is much stronger than other kinds of service.

Once they cross a certain threshold, nVidia can say goodbye to it's monopolisitic profit margins of over 70%.

GPU infra capex is the biggest spend for the inference providers as of now, power, second biggest.

China has already cracked the power part, they are now close to cracking the GPU part.

Before DeepSeek, no one sold cheap tokens anyways and then DS showed the profit margins.

So their strategy now is to try get as much raw content for their inference. You're being "paid", via discount, for your use

There is an implicit social contract, and for many it might work out well:

We use your data to improve the model. You get to use the improved model for affordable prices and (the important part): you get _the model_.

"DeepSeek

Scale: Over 150,000 exchanges"

Doesn't sound like much of distilling. Maybe they are runnung benchmarks?

I suggest taking a look at what providers like Sendgrid, Mailchimp, etc are doing to prevent abuse.

For most software companies, operating expenses are mostly wages. So, cutting costs means reducing headcount, which is likely especially true in lower-wage regions. If an engineer costs $4K/month, adding $1K/month in token costs increases employment cost by 25%. If an engineer costs $2K/month, the same $1K raises costs by only 5%.

So, I'd argue that everyone should be worried at least to some degree until the industry finds a new equilibrium.

How, at scale?

RPKI only secures the ownership information of a given prefix, not the path to that prefix. Under RPKI, an attacker can still claim to be on the path to a victim AS, and get the victim's traffic sent to it.

The solution to this was supposed to be BGPSec, but it's widely seen as un-deployable.

https://rot256.dev/post/bgp-pcd/

Proof-carrying data has come a long way in the last 10 years.

EDIT: you would still need RPKI, but not BGPSec

[0]: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-asp...

This sounds "obviously bad" but the intricacies of routing aren't really my field, could you expand on why this is bad? (i.e. what specific bad things does it enable)

The attacker can impersonate the victim, get a valid x509 certificate issued to it, and create a perfect replica of their website/api/whatever.

The attacker can perform a man-in-the-middle attack on the victim - record traffic, inject traffic, manipulate traffic, etc.

The attacker can just deny access to the victim - just drop packets meant for the victim.

I think that people often compare apples to oranges by comparing the “copilot” they have in Windows/Office/Teams etc to Claude Code which is ridiculous.

A better product to compare Claude Code to would be “Github Copilot CLI”, but I haven’t seen the two seriously compared anywhere.

Github Copilot can use Claude APIs and has its own problems and challenges.

Microsoft AI performance is primarily not being affected by Github - while significant is much much smaller part of the enterprise revenue stream and their DAU compared to their Office suite apps.

Same for their PR exposure. It is lot more likely to here about Copilot in the office context than Github outside of small niche's like this forum.

Now it's "Microsoft Copilot" which is different from "Microsoft 365 Copilot", which is different from "Copilot Chat" and from "GitHub Copilot", and the many other flavors.

It's a mess.

Still, their developer-focused offering seems to be "GitHub Copilot", which among other things includes "GitHub Copilot CLI" [1], their terminal-based agent. It's not bad.

[0]: https://en.wikipedia.org/wiki/Microsoft_.NET_strategy

[1]: https://github.com/features/copilot/cli/

Everyone cares. In fact, there's an entire industry of tools being developed to solve this very problem. The current governance gaps are obvious to anyone who's ever used an agent.

We are still in the very early stages of all of this. The capabilities of current models are ahead of our engineering practices, and other organizational practices for that matter. Everyone is new to this.

I think we are going through the same cycle of http leading to https, the rise of oauth and oidc. Its just way faster now.

Currently, engineers work with loose specifications, which they translate into code. With the proposed approach, they would need to first convert those specifications into a formally verifiable form before using LLMs to generate the implementation.

But to be production-ready, that spec would have to cover all possible use-cases, edge cases, error handling, performance targets, security and privacy controls, etc. That sounds awfully close to being an actual implementation, only in a different language.

Of course, this remains largely theoretical for now, but it is an exciting possibility. Note high-level specifications often overlook performance issues, but they are likely sufficient for most scenarios. Regardless, we have formal development methodologies able to decompose problems to an arbitrary level of granularity since the 1990s, all while preserving correctness. It is likely that many of these ideas will be revisited soon.