M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
13 hours ago in I keep telling people the best AdTech takes aren't on stage, they're in Slack threads at 11pm when something breaks.
So we started writing them down.
The Frontier is our weekly Appliscale newsletter about AdTech and the AI agents moving into it, written by the people at Appliscale who build the infrastructure underneath both. Damian Naglak and I have spent 11 years running RTB platforms, bidders, and identity pipelines for SSPs, DSPs, and exchanges moving tens of billions of impressions a day - this is where we write down what we're actually seeing.
Every issue, 3 minutes, same structure:
→ Deep Dive - Damian's weekly tech deep dive
→ 5 Things You Should Know - short 240 characters Ad Tech news we believe are relevant for our industry
→ The Number - one stat, unpacked
→ The Signal - the slower-moving shift worth tracking
If you're shipping AdTech, buying media, or just tired of slide decks selling you nothing, sign up here: appliscale.substack.com
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
1 day ago in One of the questions I got asked after the XDS panel in Vancouver was: how do you keep clients isolated?
For a service provider AI policy belongs in the setup conversation, together with machine provisioning or VPN access.
So before an engineer writes a line of code, we check the client's AI compliance. Then we brief the engineers. Clearly, before they start.
And there's one rule behind that: hard isolation. No client's data touches another client's environment. When an engineer moves to a new project, they switch hardware, and they switch their AI suite, too. Clients data and everything derived from it stays with the client. Ideally we work on the client's own model from the start.
It's not a flexible guideline. It's baked into Appliscale's internal policy. As much as we value trust, we're also transparent - clients should be able to check the setup.
My advice: if you work with several external partners, ask them how they isolate. The answer tells you a lot.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 day ago in 1) Custom software dev is cooling because code is cheap now, VCs don't care about software wrappers anymore so if you want to build a real business in 2026, the moat is in your proprietary data + the unique insights your software can extract from it
2) Data engineering is expanding because modern AI is 10% prompt and 90% data pipeline and I see this daily in Ad Tech - you cannot deploy agentic media buying or automated reporting if your underlying data lake is a mess
3) The junior market is brutal right now because companies are scared of the unknown. They aren't investing in future generations of programmers; they want senior architects who can fix infrastructure today (but IMO in long-term that's an industry debt, juniors are still needed and they bring fresh perspective, tools, ideas)
4) Pure development is dying, but integration is booming. Senior integration and DevOps are in high demand because AI creates an explosion of unvetted code that has to be deployed, monitored, and secured. The bottleneck shifted from writing application logic -> systems integration
5) The compliance / security time bomb? "Haste makes waste” or as we say in Poland "When you rush, the devil rejoices”.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 days ago in Recently I attended two in-person meetings where there was no video call and no mention of recording.
After those meetings I got two pages of detailed notes - something I never encountered in my engineering career before AI.
I also attended a few video calls with industry software groups that had a special policy of no recording and no AI transcripts. Still, I received a meeting summary from Fireflies, Fyxer, etc., which someone had enabled - by accident or on purpose.
I wonder now: were those notes generated from a voice transcript of a recording, or was somebody just that good at taking notes? :)
It makes me wonder whether we’re already living in an age where you should assume - and take for granted - that everything is recorded and could be processed in a public cloud.
...and there's already new software popping up to block AI notetakers like Kalypta (it runs a small local model on your device, reshaping audio in real time) .
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
4 days ago in This Jev model playing Doom in real time 20-200x faster and 40-400x cheaper that LLM.
If there's one thing you should try this week is Jev by TypeSafe AI . The idea is pretty simple: you send Jev two things:
- the state e.g. image, frame, text, support ticket
- set of questions you defined in advance e.g. "is it SPAM", "probability it's fraud"
Jev evaluates every question against that same state in one pass and comes back with:
1) a choice
2) a score
3) a yes/no probability
It's not an LLM that writes code, text or reasons - it's more of a JSON generator or as Nathan Flurry states:
"jev is just a *really* smart switch statement like if 2016 ml classifiers got 2026 levels of intelligence"
Why it's such a big deal?
Cost and speed. 70-500 ms latency and $0.042 / mln input tokens, output is not charged (still too expensive/slow to run on a hot path when OpenRTB is considered but it's getting interesting...)
One person triaged on the order of 1,500 to 1,700 emails for pocket change. Another classified 100 emails in 1.42 seconds and only sent the uncertain ones to a bigger model or break down 724 live ads from 37 brands in 40 seconds (every hook, every format, CTA etc.)
Doom demo source: https://x.com/kmad/status/2100339921714323624 - navigation (5 decisions / s), Combat (12 decisions / s). Browser automation is probably not the best usecase (if everything goes API-first soon) but if the price goes to $0 and latency -> 0 we soon will be able to put judgment into every interaction like email, notification and get instant answer/probability ("is it relavant for this user?").
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
4 days ago in Most inventory trades through deals now, and the reasons given are commercial: price, access, guarantees. But what does a deal add to the anatomy of a bid request? One object on the impression, around 150 bytes.
A deal travels inside the ordinary bid request, through the same auction, as one extra object hanging off the impression. It's called imp.pmp, it holds a flag and an array of deals, and everything PMP means commercially is carried in there.
What's in a deal is mostly overrides. It carries its own floor, which replaces the floor on the impression, and its own currency, which doesn't inherit from the impression and defaults to USD when nobody sets it. It can override the auction type for itself alone, and one of those values means the floor is the agreed price rather than a minimum. It can name the seats and advertiser domains allowed to bid, making a deal an access list as well as a price. One more field marks the deal guaranteed, which tells the bidder it's expected to bid. That's nine fields, two of them only for video and audio, where the floor changes with creative length.
I measured what all that weighs on a day of live bid requests, and the size is linear. One deal is 152 bytes, about 41 of that the wrapper, and every deal after the first adds another 110. Against a request averaging 2.7KB, a single deal is just under 6 percent of everything sent.
Say an exchange runs 500,000 requests a second and a third of those carry one deal. That's a bit over two terabytes a day in deal objects by themselves, before compression, and about 800 terabytes a year on one buyer connection. The sender pays it. The receiver doesn't, because cloud ingress is free, so on the buy side a deal costs decode time instead. Inside a containerized bidder those bytes obey different laws of physics. The bidder sits in the exchange's own cluster, nothing crosses a network boundary, and the egress on all of it goes to zero. Everything two companies agree about a deal has to survive the trip into those nine fields. Price fits, access fits because wseat and wadomain name who is allowed to bid, and a guarantee gets one flag.
The share of spend moving through deals keeps climbing. Whether that continues, or agentic audiences take some of it back, is the open question. Vectors may end up carrying enough of what a buyer wants to replace part of what a deal does today.
Bedrock Platform
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
1 week ago in Does your Claude model really need Claude Code?
Just saw a really interesting study comparing model performance across different harnesses (Claude Code, Codex, and Pi). The findings are quite impressive:
1. Harness choice barely affects task success, but can swing costs up to 5x for the exact same model.
2. A simple harness can be competitive. Pi, a minimal open-source harness with just 4 basic tools, reached the Pareto frontier on both cost and accuracy.
3. Models may perform better with other harnesses than native.
As models get smarter, heavy harness scaffolding might be turning into a pure tax.
Link in comments
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in Half the questions in adtech are one question: is this in the list? The list is usually too big to keep, so the answer comes from something that trades a few wrong answers for the space.
Has this person already seen the ad? Is this user in the segment? Is this domain on the blocklist? Is this a request the buyer would skip? Frequency capping, targeting, brand safety and traffic shaping ask four different questions with the same shape underneath: a set that's expensive to hold, checked millions of times a second.
The answer is older than programmatic, and it comes down to not keeping the list at all.
Picture a row of a thousand empty boxes. To put user 4471 on the list, the ID runs through a bit of arithmetic that always points at the same three boxes, say 12, 340 and 807, and those get ticked. Put user 9982 on and it points at 340, 512 and 903, so those get ticked too. Box 340 is now ticked by both of them, and nothing anywhere records which user did it. Checking works the same way. User 4471 points at 12, 340 and 807, all ticked, so 4471 is probably on the list. User 5000 points at 88, 512 and 640, and 88 is blank, so 5000 was definitely never added. Then user 7231 points at 12, 340 and 903, every one of them ticked by somebody else, so the answer comes back yes for a user that was never put on the list.
One blank box and the answer is no, for certain. Every box ticked and the answer is probably yes. A user ID written out is 36 characters, so ten million of them is 360 megabytes stored as they are, or 160 packed into raw bytes. Compress that as hard as it can possibly go and it is still 133. The same ten million as ticks is 12 megabytes at one wrong yes in a hundred, 6 at one in ten, 18 at one in a thousand.
This only works where a wrong yes is cheap. On a drop list it is. If the filter says a request is on the list when it never was, a few requests go unsent that didn't need to be, and sending fewer was the point anyway. Elsewhere in adtech the same mistake costs more or less depending on where it happens. Blocking a page that was actually fine is the cheap kind of mistake, and skipping someone who hadn't seen the ad yet only costs a bit of reach. Putting someone in an audience they were never in is the expensive one, because money goes on showing them the ad.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in Google does not need to win the AI chat war because they already own the ground truth.
At Appliscale , we run our entire 120+ person organization on just three core systems, with Google Workspace as the backbone. People constantly tell companies they need ten separate SaaS tools for HR, CRM, resource management, and documentation - we avoided the SaaS bloat because almost every single business truth eventually touches Google (or Slack), so inbox is a semi-structured, chronological log of an entire company's ops reality.
With our internal AI workflows, our agents don't need a complex custom CRM - just need access to Google Workspace APIs to reconstruct the state of a project, understand client history, and automate operations.
Everyone is watching Google fight OpenAI / Anthropic for the browser chat interface or assume they "got defeated because Gemini is falling behind" but Google's real moat is sitting in the background. If every agent on earth has to query Gmail and Calendar to understand what a human or business is doing, Google wins by just taxing the API call.
PS. We've recently started our Substack newsletter with Damian Naglak on AdTech x LLMs, check it out and subscribe for more analysis: appliscale.substack.com
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in Keeping design docs in your git repo = antipattern (at least for us)
We recently took over a client project at Appliscale that had over 1,500 design docs and RFCs committed directly into the repo.
Turned out it was a disaster for coding agents.
Whenever Cursor or Claude Code tried to solve an issue, the agent pulled dozens of these old design files into the context window looking for clues, and the result was quite predictable:
Context bloat: burning thousands of tokens on historical plans rather than actual source code
Context poisoning: the agent kept writing code for systems that were designed in 2023 but completely refactored in 2025
Simple thing to remember: in most cases an AI agent does not care about your past intent, it cares about the ground truth right now. A design doc captures how you hoped to build a feature two years ago, but it tells the agent almost nothing about how the system actually functions today.
So our team threw out the approach and replaced it with a pattern we call Atlas: instead of accumulating hundreds of static RFCs, we force our agents to maintain a single, highly accurate map of the current architecture. Concise, structured, and explicit about what exists now and what does not.
The important part is that Atlas works like an encyclopedia rather than a single document. It is heavily compartmentalized, so an agent loads only the slice covering the area it is about to modify. That protects the context window and keeps the agent focused.
On keeping it fresh: we first tried to verify Atlas on every PR. Too many changes at our pace of work and too many conflicts. So the refresh runs nightly instead. That works fine, because agents are good at spotting where the documentation has started to lag behind the code.
Stop writing for the historian. Write for the agent working right now.
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
1 week ago in The External Development Summit wrapped up on Friday. My first one, and far easier to navigate than I expected. The Connect Zone makes networking seamless, and it’s a genuinely welcoming crowd.
My take from the conference is that both publishers and service providers are trending positively on where the industry is heading.
Partnership was the word I heard the most in the table topics. And there was one specific call-out repeated - rely on service providers experience. We work with multiple clients, so we’ve usually seen the problem before and recognized the solution faster. Bringing partners who add capability, not just capacity, is crucial for the stability of the industry at the moment.
On AI — the market has absorbed AI and started using AI tools built by specialists, tools that serve the purpose. I heard it in off-stage conversations, table topics, and in Brian Burleson's keynote on Thursday. And on our panel of course. Glad I could share how Appliscale approaches agents harnessing, and the operational side of building with AI so it brings actual results. Reasonably. Judging by the conversations afterwards, this is a discussion the industry wants more of.
And you know what? Shoes connect people!
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
1 week ago in DeepSeek just released DeepSeek-V4.1-Flash, and the coding results are genuinely impressive - it's holding its own against GPT-5.6 Sol and Opus-5, to the point where DeepSeek is actually deprecating their own V4 Pro model for it.
Getting frontier-tier coding out of a 'Flash' model is wild. But as someone who uses coding agents daily, what really caught my attention is how they engineered it for agent loops.
Anyone running agents knows that context prefill and memory is taking up a lot of tokens. Every tool call, test run, and file diff gets dumped back into context. Decoding the next action is cheap, but re-reading that massive prompt on every turn kills latency, and keeping gigabytes of cache in GPU memory across turns is what makes long sessions absurdly expensive.
DeepSeek essentially built this model around that hardware pain.
Asymmetric compute - it only activates 8B parameters when reading your prompt, compared to 16B when generating code. That cuts prefill compute nearly in half. Squeezing the context cache down to a fraction of the memory footprint, so multi-turn sessions don't exhaust your GPUs. And instead of chasing exotic new RL algorithms, they focused on building a massive internal sandbox cluster to train agents against real production environments.
A Flash model that beats the previous flagship while slashing the cost of long-context prompts feels like a turning point. We're finally seeing model architecture designed for the actual economics of running agents.
Paper in comments.
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
2 weeks ago in Tencent published a paper on a system called WorldClaw, and it gives a pretty interesting look at where 3D scene generation is heading.
Most generative 3D today focuses on either single isolated assets or rendering camera fly-throughs. Building a full, explorable open world where you can walk around, edit individual props, and export clean geometry to a game engine is a completely different challenge.
What makes WorldClaw neat is how pragmatic the pipeline is. They approached it much like a level designer would:
Procedural heightmaps lay down the continuous terrain first - mountains, riverbeds, valleys.
To populate specific areas, the system takes a 2D camera render of the bare ground and lets an image model paint what belongs in that view. It cuts the props out with SAM, lifts them into 3D meshes, and uses camera raycasting to snap them back down onto the sloped terrain.
Then an agent inside Blender inspects the scene from diagnostic angles and adjusts the ground footprint under foundations so buildings sit naturally on the hillside.
What you get at the end - shown in the clip below - is an explicit 3D world with separate textured meshes. Real geometry where you can click on an individual house, move it, tweak shaders, or export the whole scene into Unreal or Unity.
Really interesting to see generative 3D moving from purely visual outputs toward actual production-ready assets.
Paper and project page in comments.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in "Since January 2025, tech job postings have seen a marked rise in preferred years of experience, with a concomitant drop in preferred number of skills.
The change is small–~5-10% in both cases–but noticeable, and it’s consistent with the notion that tech is looking for more experienced workers, rather than workers with any particular set of skills, let alone a broad range of skills. That could very well be an AI-driven shift: grappling with a new technology means that extant “skills” are less applicable, and the new set of skills is still a bit of a whitespace. When you’re operating on a new frontier, you don’t yet know what you’ll need, other than the need to be able to figure it out–and that’s where experience goes a long way."
https://www.a16z.news/p/chart-of-the-week-experience-skills
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in I measured what it costs a bidder to open a request it will never bid on: about 7 microseconds of CPU and 13 kilobytes of memory, spent before anything looks at whether it's wanted.
Dynamic Traffic Engine, donated to IAB Tech Lab by Amazon Ads, is a standardized proposal for not sending those requests at all: the buyer publishes a list of what it doesn't want, and the seller drops matching requests before they go out. The buyer's half comes down to one step every DSP pays however its bidder is built: turning 2KB of incoming request into a structure the bidder can reason about.
The test is a thousand real bid requests from live traffic, decoded in Go, measured three times. Opening one costs 7 microseconds and 13 kilobytes, and the JSON decode is most of that. At that point nothing has been checked against a single campaign. A parser has to read through the text to find a field. So a check that only looks at the impression type, building nothing and allocating nothing at all, still cost a third of the full decode. There's no cheap look at a bid request.
Say a bidder takes 500k requests a second and only buys video. Count formats in live traffic and two thirds carry video, so the other third is banner, native or audio: unbiddable at any price. That leaves 165,000 requests a second, before geography or publisher narrows it further. Multiply by the 7 microseconds and 13 kilobytes each and that comes to about a core of CPU and 2 gigabytes of memory a second, spent on requests nobody could bid on. All of it predictable from one field.
And that is only the raw work of opening the request. A bidder with a model loaded in the same container pays far more per request, and the memory that model needs is what decides how many instances have to run. Every request nobody could bid on takes a slot in that, so the waste turns up as instance count rather than microseconds.
Nothing inside the bidder fixes this, because the cost lands the moment the request arrives and sending it was somebody else's decision. That's a good use-case for DTE. Telling the seller what a buyer won't bid on is the only thing that takes the work to zero.
Bedrock Platform
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
2 weeks ago in The AI in External Development panel is done.
A wonderful group of people to be on that stage with, and the discussion had a flow you can’t plan for. We’re still getting very positive feedback.
Main take away from the panel: the industry is fairly positive about AI adoption. And when you know how to do it reasonably, you’ve nailed it.
Two advise from my side: start the AI conversation at the start of the relationship. And look for a partner who specializes in agent harnessing.
Huge thank you to the panel host Summer O'Brien, to Arun Gowda for backing us from the XDS side, and to my co-panelists - Rory McGuire, Carl Schmidt and Dave Sanderson.
I already look forward to next year!
#xds2026
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in A DSP knows which bid requests it won't bid on. Dynamic Traffic Engine is a standardized proposal for informing the seller of that before it sends them, donated to IAB Tech Lab by Amazon Ads in April.
Sellers already shape traffic without any of it. They cap how many requests a given buyer gets, they rank buyers by how often they bid and cut the least active, and they score each request on how likely that buyer is to answer. All of that reads the buyer's past behavior, which lags the thing that actually decides what a buyer wants: which campaigns are live today. Nothing stopped a buyer stating its preferences either, it just meant an email, a QPS cap or a bespoke filter, one integration at a time.
It works like a list the buyer hands over, with instructions for reading it. One file says which parts of a bid request to look at, seven of them in the reference setup: app or website, banner or video, which publisher, which country, the ad size, where it sits on the screen, what kind of device. The other file lists the combinations the buyer has an opinion about, one per line, values separated by a vertical bar:
app|banner|123456789|GBR|320x50|a|4
A 320x50 banner in a mobile app, near the top of the screen, publisher 123456789, UK, phone. When a request comes in, the seller pulls those same seven things out of it, joins them into one line, and checks whether that line is on the list. The list sits in memory, 1 to 10MB of it, so the check costs under a millisecond, and it's re-downloaded every five minutes in case the buyer changed its mind.
The buyer also chooses which way to read the list. A drop list means send everything that isn't on it. A keep list means drop everything that isn't on it. Both are documented, and the closed beta ships only the first, so DTE today says what to stop sending. A list too long to move gets swapped for a Bloom filter, a compact structure that trades exactness for size.
Anything that breaks sends the request, and a stale list stops filtering after 24 hours. Broken DTE behaves like DTE nobody installed.
There's also a holdout written into the wire format. Every forwarded request carries a learning flag, and 20% of traffic in the reference config is control: the library works out it would have dropped it, and the seller forwards it anyway with that verdict attached. The buyer gets a labeled sample of what the filtering costs, and the seller uploads a weekly report splitting fill rate and spend across both groups. The seller runs the experiment and reports the results to the buyer who wrote the model.
Every no-bid gets paid for twice, in CPU at both ends. The seller spends cycles building a request nobody wanted, the buyer spends cycles unpacking it to find out. Co-location removes the distance between them and leaves both costs in place, so dropping the obvious cases is what removes the work.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in "We spent more on remembering context than generating answers"
I asked one of our engineers about our "tokenmaxxing" stats for August and key metrics are: 3.064B tokens and ~$2,294 estimated API cost but this is a little bit misleading.
So over 27 days:
20 active days
78 coding sessions
7,311 assistant messages
3.064B total tokens
68.5M new tokens
2.996B cache reads (97.8%)
5.4M output tokens
~$2,294 estimated API cost
Now a few observations:
1) Cache is the king = we spent more on remembering context than generating answers
Only 5.4M tokens were output. The vast majority of the token volume came from repeatedly reading cached context so I think this is a more useful way to think about coding agents: the expensive part isn't necessarily writing code but maintaining enough context to understand the repository, previous changes, tool output, tests, etc.
Prompt engineering -> Context engineering
2) “3 billion tokens” is a pretty bad productivity metric
Only 68.5M tokens were new. The other ~3B were cache reads.
So two engineers can have radically different token counts without one necessarily doing 40x more work.
For agentic development, I think metrics like cost per session, cost per PR, cost per feature shipped are ultimately more useful than raw token volume.
3) The unit of AI usage is changing from “prompt” -> “session”
7,311 assistant messages across 78 sessions = ~94 messages per session.
This isn't ChatGPT-style usage where an engineer asks a question and copies the answer because the agent is running a loop e.g. inspect -> change -> run -> inspect -> debug -> change -> test -> repeat
4) Context engineering has a direct economic value.
With 97.8% of tokens being cache reads, keeping useful context stable enough to reuse is more than an architectural detail, it really affects the bill.
So again: that makes things like repository structure, instructions, tool output, context boundaries and caching strategy increasingly relevant to engineering economics. Engineers -> Archiects
5) $2.3k is the number I actually care about
Not because it's "expensive", but because it's now measurable. For one engineer this over 20 active days = that's roughly $115 per active day of frontier model inference at API list pricing.
Worth noting: this was all Opus via subscription, so $2,294 is list price, not what we paid. On a $200/month plan that's roughly an 11x spread on one seat, which tells you what these subscriptions are currently worth.
And from CEO perspective the business question isn't whether $2.3k sounds large or small but what did we ship for that $2.3k?
6) Model selection is a workflow design decision
All of this ran on the most expensive model available, for every step of the loop.
So the next optimization is decomposition: Opus for planning and hard debugging, cheaper models for the mechanical loop, cheap subagents doing the wide shallow work and reporting back compressed findings.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in "Across all industries, there’s an ~8-fold gap in token output between the typical and top-decile enterprise, where the latter has increased output by more than 17x since April 2025. Within select industries, the gap is even wider, rising to almost 12-fold in Information (i.e. tech), where the top decile of firms is outputting 32.5x(!) as many tokens as they were a little over a year ago."
Source: https://www.a16z.news/p/charts-of-the-week-winds-of-thematic
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
3 weeks ago in External Development Summit (XDS) starts next week.
I’ve already introduced the panel I’m in: AI in External Development —Policy, Risk, and Reality. Feel free to sign-up on Wednesday, if there are any seats left.
We’ll be talking about AI off the stage, too, but I’m also going to other table-topics and panels to explore:
- how vendors and developers are rebuilding their business models for the AI era
- where the gaming industry is actually heading, what the current trends are
- how studios and external partners are working together right now
- what needs to change in ex-dev - sustainability, margins, survival
I'll come back next week with whichever one surprised me most.
The main reason everyone flies to Vancouver is the networking and what happens in the Connect meeting zone. So if you're going to be there and want to go deeper on any of the above - hit me up to connect.
#xds2026 #gamedev
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in A user agent string is supposed to say which browser made a request. Most of what it actually contains describes browsers and engines that aren't the one running, kept alive as compatibility credentials for three decades.
A user agent string is meant to carry the browser, its rendering engine, the operating system, and a version number, sent automatically on every request. A newer field, sua, is meant to carry a more honest structured version, built from data the browser only shares if asked, and only on the next request. OpenRTB's spec recommends sua over the plain string when both exist, since the plain one can be frozen or reduced. sua also carries a field marking where its data came from, and since Safari and Firefox never adopted the mechanism that would make it genuine, that value is often just the old string, parsed and reshaped to look tidier.
The reason goes back to 1995. Netscape's browser identified itself as Mozilla, and sites checked for that word before serving the full page. When Internet Explorer 2 shipped that year, it started sending Mozilla too, so it wouldn't get the downgraded page. Every browser has kept the trick since.
The format itself isn't even consistent. Browsers and mobile apps mostly send that same layered string, since they run real browser engines underneath. CTV splits in two: some platforms send their own short device string with no browser claims at all. Others run an actual browser under their interface and produce the identical Mozilla, WebKit, Safari chain a phone would. Three conventions, depending only on what's asking.
The same identification problem is showing up again, one generation newer. GPTBot, ClaudeBot, PerplexityBot, and Google-Extended are real, distinct strings site owners write rules against, commonly blocking the ones built for training while letting the real-time answer ones through. Research from January 2026 already found some AI agents using those exact strings to get past the blocks.
An IETF draft called Web Bot Auth, backed by engineers at Cloudflare, Google, and Amazon, replaces the self-reported string with proof. A bot signs each request with a private key only it holds, and publishes the matching public key at a known address. A server checks the signature against that public key: a match proves who sent it, anything else proves nothing. A text string can be typed by anyone, a signature only by whoever holds the private key. Cloudflare already runs a version of it, though the standard itself is still a draft, not yet adopted.
As a field for saying what's actually making a request, user agent is unreliable. Every other identifier in this series gets patched by someone, privacy extensions, sync mechanisms, truncation policies. This one has a patch too, and most of what claims to be patched is really just the old string, reshaped. The approach that might work doesn't patch it at all, it stops asking the field anything and checks a signature instead.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in ChatGPT ads just went from “interesting experiment” to a $1B annualized business.
On August 31, OpenAI said its advertising business had reached a $1B annualized revenue run rate, less than 200 days after the first paid ads launched in the US. At that run rate, we're talking about roughly $83M of monthly ad revenue.
The more interesting number is the slope.
OpenAI says the ads business was around $100M ARR after ~6 weeks, with roughly 600 advertisers. By August, it had reached $1B ARR and tens of thousands of advertisers across 40+ countries.
That's roughly a 10× increase in run-rate in five months (!).
And there is a technical story underneath the revenue story.
OpenAI has had to build most of an advertising stack from scratch in roughly half a year: Ads Manager, CPC and outcome-based bidding, conversion tracking, product feeds, geo targeting, custom audiences and integrations with 50+ measurement and technology partners.
The inventory is also unusual.
Ads appear below responses for Free and Go users, while Plus, Pro, Business and Enterprise remain ad-free. That puts advertising directly next to what is arguably the highest-intent consumer interaction on the internet: someone asking an AI to help them decide what to buy, where to go, what software to use or which product to choose.
And this is where I think the next interesting competition will be: how much of the advertising stack can move from predicting intent to observing intent?
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in Over the weekend, X got taken over by “Infinite Slop” - a live stream where people type prompts and AI generates the next video in the sequence.
The reason this suddenly became possible is a very specific performance threshold.
On August 27, fal.ai released H3 Max, a post-trained and inference-optimized version of MiniMax H3. At 768p, it can generate 5 seconds of video in under 3 seconds. fal reports roughly 35× the throughput of the official H3 endpoint (Design Arena measured more than 50× the speed of the original model at comparable quality).
That means generation is now faster than playback.
It sounds like a benchmark detail, but it changes the system you can build around the model.
Previously, a video model looked roughly like: prompt → wait → video → watch → repeat
If a 15-second clip takes several minutes to generate, you can't really make it the engine of a live medium.
With sub-real-time generation, you can generate the next scene while the current one is playing. Add a queue, some state and an input channel, and you have a continuous stream.
That's basically what InfiniteSlop.ai does. Pieter Levels connected H3 Max to a live interface where chat messages influence the next generation and the model tries to connect it to the previous clip. Levels reported 37,000 viewers on August 30.
The output is obviously rough. Characters drift, scenes don't reliably connect and most prompts produce nonsense. But that's almost useful for the experiment because the demo is testing the system property rather than the quality of the final product.
Future? Interactive stories, generative games, live virtual characters, audience-controlled broadcasts, dynamic advertising.
(Of course there is also a new constraint: Infinite Slop can receive more prompts than it can put on screen so at some point the problem becomes deciding which input gets compute, when to generate it and how much context to carry forward)
H3 Max is still limited to 768p, and the continuity between generations is primitive. The standard price is also moving to $0.08/sec after the launch promotion.
But the underlying threshold is worth paying attention to:
For most of the history of digital advertising, we’ve optimized the path from an impression → a decision → an asset being served. Milliseconds matter because the decision has to happen before the user moves on. Generative video has operated on a completely different timescale. You generate the asset first, then serve it so interesting thing about H3 Max is that it starts to blur that boundary?
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in Device ID can go missing, and so can a cookie. An IP address almost never does, which doesn't make it any more stable.
An IP address is a routing address: a network location for delivering a packet, not an identity. It only has to be right long enough for one delivery, nothing about it was built to stay attached to a person over time.
NAT is the trick a router uses to let many devices share one address, and CGNAT is the same trick run by the carrier instead of your router. It's driven by plain IPv4 exhaustion, only about 4.3 billion IPv4 addresses exist and none are left to hand out, and it's standardized, not a workaround: internet technical standards require these devices to limit how many connections each subscriber gets. Ordinary office or cafe WiFi does the same sharing through plain NAT: one documented setup showed a single device supporting up to 8,000 people before its roughly 60,000 connection slots ran out. A VPN's exit server runs the same trick, just chosen by the user instead of assigned by a carrier. The address itself isn't fixed either. It changes on lease renewal, a router restart, or just moving networks, home WiFi to mobile data.
IPv6 has its own churn built in, and there's a real reason for it. Left alone, IPv6 can build a device's actual hardware address into the address itself, the same value on every network it joins, letting anyone who sees the traffic recognize it across networks and even read the manufacturer off part of it. Privacy extensions exist specifically to cover that up, swapping in a fresh, randomized address roughly every 24 hours instead, standard across every major modern operating system.
Some exchanges blur it further on purpose. IPv4 gets its last number zeroed before a buyer ever sees it, confirmed against real traffic. IPv6 gets wiped down to a fixed size too, and that doesn't reliably hide anyone. How much ground that covers depends on how the ISP handed the block out, and plenty give one household exactly that size on its own. So the wipe can look like it blurs several homes together when it is really just one house's address, untouched.
The same address also gets used to guess where someone is, and that guess was never precise either. The databases behind it describe a circle with a radius from 5km to hundreds of km, not a point, warning against reading it at street level. Starlink is a clear example: its own support documentation notes the IP-based location can be off by entire states, because the address reflects wherever the connection surfaces at one of its data center hookups, not the dish itself.
Cap on an IP address and you will almost always have something to count against. Sharing, churn, deliberate blurring, and geolocation that was never precise all mean it rarely points at the same person twice. It is part of why linking an IP to a specific person downstream is so hard too, because that work is built on a foundation that keeps shifting under it
Bedrock Platform
View on LinkedIn
