DevOps agents can call every tool and still miss what is running in production; a portable context layer gives reviews, security triage, and automation evidence they can trust. Andrey Devyatkin, Vladimir Samoylov, and Fernando Gonçalves connect Grok 4.6 in Cursor, Claude Tag, cloud code review, and AI-driven bug bounty noise to the same orientation tax. They explain why live infrastructure state belongs in an automatically refreshed database rather than skills or vendor memory, and how owning that context improves accuracy, cost control, and portability across agent platforms.
Summary
Two recent launches and an existing cloud-review workflow all showed up in the same news cycle, and by default not one of them knows what is running in your production accounts. This trend-check episode of Agentic AI in DevOps, recorded August 14 with Andrey Devyatkin, Vladimir Samoylov, and Fernando Gonçalves, opens as a news roundup — Grok 4.6 arriving inside Cursor at $2/$6 per million tokens, Anthropic’s Claude Tag replacing the old Claude in Slack chatbot, cloud agents reviewing pull requests from a one-line comment — and keeps arriving at the same structural gap behind all three: each of these tools runs somewhere your infrastructure isn’t, so unless something hands it the estate it either rediscovers everything from scratch every session or guesses. Andrey’s name for the work that keeps repeating is orientation, and the fix he argues for is a context layer that is pre-computed, refreshed automatically, queryable through one interface, and portable across every harness a team rents. The sharp moments earn the half hour: Vladimir treating frontier models like a supermarket shelf — “whatever is on promotion today on Cursor… today is a Grok, tomorrow it’s some Sonnet”; Andrey’s verdict that with SpaceX’s compute behind Cursor, “suddenly Elon is back in the game”; Vladimir on why evidence beats fluency in bug bounty triage — “the model will hallucinate, but the context can actually prove it”; and the line that reframes the whole product category, straight out of the physical-datacenter era: this is the configuration database of the agentic age.
Key Topics
Grok 4.6 lands inside Cursor, and the branding tells the story
The thing that caught Andrey Devyatkin’s eye first was not a benchmark, it was a product name. The model showed up as Cursor Grok 4.6 — not a SpaceXAI launch with Cursor as a channel, but a joint release, and Vladimir Samoylov pointed out to him that the same pattern held for Grok 4.5 before it. That is visible in the vendors’ own surfaces: Cursor’s launch post frames the model as released by Cursor together with SpaceXAI, and Cursor’s own models and pricing docs list “Cursor Grok 4.6” inside the first-party Cursor Models pool alongside Grok 4.5 and Composer 2.5.
Andrey’s read is that these models are the product of the SpaceX tie-up — the compute clusters on one side, the engineering priorities and coding data on the other. The sequencing is worth stating precisely, because the acquisition and the models overlapped rather than followed one another: Cursor’s own announcement says the deal closed on August 14, 2026 — the day this episode was recorded — after a partnership first announced in April, and describes Grok 4.6, released the Wednesday before, as “an early look at what we can now build together.” So Grok 4.5 and 4.6 were developed and released during the partnership and acquisition process, not after it completed. Either way, Andrey’s substantive point stands: the release cadence has been fast, and the compute story behind it is now explicit.
The number he keeps coming back to is the price. Grok 4.6 is billed at $2 per million input tokens and $6 per million output tokens, which he calls very competitive, and it is worth being precise about what it is competitive with. Claude Sonnet 5 launched at a promotional $2/$10 with a standard $3/$15 scheduled to take effect September 1 — and days before this recording, Anthropic cancelled that increase. Sonnet 5’s page now states that the introductory pricing is permanent and that the $3/$15 standard rate “no longer applies.” Andrey doesn’t claim to know the cause — “I don’t know if it’s because of the Grok or what” — and neither does anyone else outside those two companies. What the timing does give practitioners is a data point Vladimir has been predicting for a while: a genuinely competitive market where the direction of travel on price is down. As he puts it, there is a meme going around about which model is best right now, and the answer turns over every month. “For us as consumers, it’s good.”
On the intelligence claims, Andrey applies his standard discount — “if you are to believe benchmarks again, because you can have your opinions about benchmarks and the companies actually gaming the system and training the models to perform better on the benchmarks.” Worth checking against the source: SpaceXAI’s own announcement puts Grok 4.6 at 61 on the Artificial Analysis Intelligence Index, level with GPT-5.6 Sol in Max mode, with Fable 5 Max a point ahead at 62 across a set of coding and agent benchmarks. So the shape of Andrey’s summary holds — frontier-tier scores at a discounted rate — with the parity claim landing on the OpenAI model rather than on Anthropic’s, which still edges the composite index.
Then there is speed, which the hosts think is the underrated variable. Vladimir buys whatever is on promotion each Monday — “today is a Grok. Fine, it’s Grok. Tomorrow it’s some Sonnet” — and the reason he cares about the 50% off is that the discount is what makes running in fast mode affordable. Andrey agrees and goes further: “Fast mode is underrated, I would say. People don’t talk enough about it.” His justification is the daily experience of working with Opus, Fable, and GPT-5.6, where a normal turn takes a minute or two, and the alternative to paying for latency is “just sitting there for hours waiting for the models to spin their wheels.” The trade is priced explicitly rather than hidden: SpaceXAI’s launch post puts the fast variant at double the standard rate. One more number belongs next to the cheap-frontier-intelligence framing — SpaceXAI’s release notes list standard pricing of $2 / $0.50 / $6 per million tokens (input / cached input / output) and a higher band of $4 / $1 / $12 above 200k. That band is documented for the SpaceXAI API; Cursor does not publish the same threshold for requests routed through its own pool. A session that lets its context sprawl doesn’t just get slower and less accurate; on the SpaceXAI API price sheet it crosses into a band that doubles the rate. That is a fairly direct argument for the context discipline the rest of the episode is about.
Fernando Gonçalves is the one host with no Grok experience to share. He stopped using Cursor around eight months ago, and his memory of the in-house model at the time was lukewarm — “hey, Composer is okay” — which is roughly Andrey’s assessment too, Sonnet-level intelligence rather than frontier. With a frontier-tier model now inside the first-party pool, Fernando’s verdict is short: “now it becomes tempting to try it again.”
The question that actually decides the bill: what runs on subscription?
Andrey’s practical interest is narrower than the benchmark race, and it is the question anyone running agents in CI should be asking. Cursor’s earlier problem, in his view, was that it “was charging API rates for everything” outside of the unlimited-ish auto mode backed by Composer. So: does the included pool extend to the CLI? “I wonder if they allow you to use auto mode in CLI, for instance. So you’re not paying API rates when you’re running the Cursor CLI in GitHub Actions, and you can use your subscription to run code reviews. Mmm, that becomes very interesting.”
Part of that has since been documented. Cursor now publishes a guide to running Cursor CLI in GitHub Actions, with the workflow authenticating through an API key generated from the Cursor dashboard, and the CLI supports Auto model selection rather than forcing an explicit model choice. What that page does not settle is the half Andrey actually cares about — whether CI runs draw on plan-included usage or bill as on-demand once allowances are exhausted. So the mechanism is now on the page and the economics are not, which leaves his question open in the form that matters, alongside his other caveat: “if they fix the CLI.” Anyone planning to move review workloads onto a subscription should price a pilot rather than assume.
The published pricing docs do answer the model-cost side. Grok 4.6 sits in the Cursor Models pool included with paid individual plans, Auto bills at the list price of whichever model a request is routed to, and third-party models carry an extra Cursor Token Rate of $0.25 per million tokens on Teams and Enterprise plans, from which first-party Cursor models — Grok and Composer — are exempt. That exemption is scoped to the business tiers rather than applying across every plan, but it is exactly the kind of asymmetry that makes a first-party frontier model strategically interesting.
Vladimir already runs the workflow that makes this concrete, and it is worth copying. His pull request pipeline is an automated skill: it opens the PR, does “some fancy things,” and then posts two comments — one asking Codex to review, one asking Cursor to review. Cursor documents this trigger directly: comment @cursor on a GitHub PR or issue, or on a Bitbucket PR, and a cloud agent picks it up. His own agent then waits two or three minutes for the reviews to land and fixes whatever the findings surface. “It’s my loop now.”
His read on the economics — “we’re paying like whatever is inside a subscription because it’s inside their cloud” — needs one correction, because execution location does not by itself determine billing. Cursor’s cloud agent documentation states that cloud agents are charged at API pricing for the selected model. In practice that means the reviews consume plan-included usage at model pricing and can spill into on-demand charges once the plan’s allowance is used up — which is why Cursor tells you to set a spend limit before you start. The subscription is a budget the reviews draw down, not a flat rate that makes them free. Vladimir is candid about the other trade rather than selling it — “it’s have some concerns. Can you run something in their cloud or not? But for code only, it’s sometimes a bit more flexible.” That is the right way to frame it: sending a repository into someone else’s sandbox is a decision with a security review attached, and it is easier to justify for source code than for anything holding production credentials.
Claude Tag is a better Slack agent that still doesn’t know your estate
The second release the hosts pick up is Claude Tag, which Anthropic announced in June 2026 and which replaces the older Claude in Slack app. Andrey’s summary of the change is that the previous version was a chatbot — flat-rate as he recalls it, chat as much as you like — and the new one is a different class of thing: usage-billed, heavily configurable, able to load skills and connectors. The product docs back most of that up. Channel work adds no per-seat charge and instead draws on a usage balance an owner funds, capped by a spend limit; admins extend Claude’s reach through connections, plugins, and skills configured per channel, workspace, or organization; each task runs in an ephemeral sandbox that is discarded when the conversation goes idle; and the agent keeps memory attached to the channel, shared with everyone in it.
Andrey’s objection is not that this is a weak product. It is that a Slack-native agent, however well built, “has no recollection of stuff that is outside of it.” Its channel memory is a record of what the team said, not of what the team runs. Ask it where a service lives, what depends on it, or which account it was deployed into, and it has whatever a human typed into that channel plus whatever it can reach through a connector.
Which is where the hosts describe what they have actually shipped with several customers: wiring B.O.R.I.S into Claude Tag as a remote context source over OAuth machine credentials, so the Slack agent can query the current state of the infrastructure directly — quickly locating where things are, answering the questions developers ask a dozen times a week, grounding its reasoning in something real, and using the temporal graph to explain how the estate changed over time.
For readers who want the mechanics of that plumbing, two documents matter and they are not the same document. The MCP authorization specification is the core standard: a protected MCP server acts as an OAuth 2.1 resource server, with token audience binding and scoped access. But that core flow assumes a human at a browser approving access, which is exactly what a headless integration does not have. The machine-to-machine case runs on a separate, optional OAuth Client Credentials extension, which adds the OAuth 2.0 client credentials grant — client ID and secret, or a signed JWT assertion — for background services and CI pipelines. Being an extension has a practical consequence: both sides have to support it. The client declares the capability, the server validates the token and checks scopes, and extensions are opt-in rather than active by default. Worth confirming on both ends before planning an integration around it.
There is also a budget consequence worth naming, because Claude Tag is consumption-billed. Every discovery task consumes billable usage from the funded balance — the same balance a spend limit caps. Working out where a service lives was always expensive; on this billing model it becomes visible.
A code review that doesn’t know where the code runs
The same gap shows up in CI, and Andrey’s example is the one most teams will recognize immediately. Cloud agents and CI-hosted reviewers — Claude Code or Codex in GitHub Actions, Cursor’s cloud agents — run in isolation. “They see the code, but they have no idea how that code is being applied to the real infrastructure, where it’s going to be running.” What are the constraints, how has it evolved, what depends on it? And then the specific failure: “if your Terraform is in a separate repository from your source code, the code review will have nothing to go by.”
Split repositories are a normal, defensible layout. They can also leave a single-repository reviewer blind unless cross-repository context is explicitly provided — the agent looking at an application diff sees nothing of the infrastructure it lands on, and the agent looking at an infrastructure diff sees nothing of what runs on it. That is a configuration problem rather than a law of nature: Cursor’s cloud agents, for one, support multi-repository environments intended for tasks that span separate frontend, backend, infrastructure, or shared-library repositories. Someone has to set that up deliberately, and the default is the blind version.
Vladimir sharpens what the reviewer should actually be answering. Not style, not naming — “what we are going to break with that pull request, just to help the dev team to understand what exactly needs to be verified and checked.” His scenario is the scale-up rhythm: a tiny feature change, a release every week, everything green, and then “suddenly your users find out that some other thing is broken.” A reviewer with the dependency map can produce something more useful than approval — a short list of what to watch after deploy. That is a deliverable a human reviewer with three tabs open often cannot produce either, which is part of why it gets skipped.
Andrey’s framing of where this fits is deliberately unglamorous, and it is the same argument Vladimir made in episode #16 about plugging in context before reaching for anything clever: it works in CI/CD, in code review, in any chatbot you can attach it to, and in agents you build yourself or buy. “If you buy some ITSM or DevOps agent, you can plug the context layer there and it will be helpful there.”
Security triage is where the payoff is easiest to see
Fernando’s contribution is the use case he has found most valuable outside code review, and it starts from a familiar noise problem. Security scanning tools throw alerts continuously, and they typically see a narrow slice — usually just the code — so they cannot tell you whether a given finding is a real threat in your environment. He was working through exactly this with a customer recently: “I have this alert, how do I know if this is actually a threat to me or not?” Handing the agent the code already helps. What changes the answer is letting it look at the live configuration and trace dependencies, sometimes into a different repository, until the conclusion is defensible: a false positive, or something that exists but doesn’t warrant panic “because maybe it’s not exposed to the internet.” The value is not the analysis, it is the ability to spend attention on the findings that matter instead of on the noise.
Vladimir raises the harder version of the same problem, and it is the most concrete pressure in the episode. One of his customers runs a bug bounty program on HackerOne, and in the current era the reports arrive at machine speed — largely generated, in volume, faster than human triage can move. Something on the validation side has to go into the AWS accounts and the codebase and actually check whether a claim is real, and decide whether a human needs to double-check it. He also names the category that wastes the most triage time: reports that describe software behaving differently than intended, which reads like a vulnerability and isn’t one. “The model will hallucinate, but the context can actually prove it where it is and it’s real or not.”
The published numbers are blunter than the anecdote, with one important qualification. HackerOne reports that the entire industry saw a surge of more than 100% in report volume following capable model releases in early 2026 — an industry-wide increase, not a uniform doubling for every program. HackerOne is explicit that the impact varied: public programs felt it more acutely than private ones, and programs with open-source repositories drew still more duplicate AI-generated scans. Its response was a mix of policy and tooling — a Code of Conduct update covering AI-assisted research, detection and enforcement mechanisms, smart routing to match reports to analysts, and its own agentic tooling for deduplication and escalation.
Elastic published the closest thing to an implementation of what Vladimir is describing: an AI triage pipeline for its own HackerOne program, built after receiving over 1,390 reports in the first half of 2026 — more than its full-year totals for 2024 and 2025 combined. Two details map directly onto the episode. The pipeline leans on Elastic-specific triage rules that encode which things are features rather than vulnerabilities, which is the exact distinction Vladimir says burns his customer’s time — organizational context, not model capability. And a human still makes the final call on every report, which is his “should we ask human to double check or not,” implemented as a rule rather than left to the model.
Orientation is the tax you keep paying
The most common objection Andrey hears is that this problem is already solved by giving the agent AWS access. “What I often hear people say is, like, yeah, like, what’s the point? I now have like AWS Agent Toolkit, I think it’s called, with MCP and everything.” His answer: “Yeah, yeah, you do.” You plug it in, you get AWS access and a set of tools — and then, at the start of every session, you still have to do the work of pulling on that interface to find out where things are and compute the answer you were actually looking for. “So you still need to do a discovery. And I call it orientation usually.”
The Agent Toolkit for AWS is real, generally available, and better designed than the objection assumes — a managed MCP server with full AWS API coverage behind IAM, live documentation access, sandboxed script execution, and curated skills that agents load on demand specifically so they “do not consume unnecessary context.” Credit where due: the toolkit already solves the version of this problem that lives inside the vendor’s own surface. What it does not do, and does not claim to do, is arrive knowing your estate. The per-session archaeology Andrey is describing — which account, which service, what depends on it, what changed — is still work the agent performs from cold every time.
Through a context layer, he argues, that collapses into one query: I’m working with this service. Because the graph is temporal, the answer comes back as a shape rather than a scavenger hunt — this is what it is, here is where it lives, these are its dependencies, and here is how it changed over time. Then the session starts.
The multi-provider case is where the arithmetic gets uncomfortable. Something on Google Cloud, something on AWS, Cloudflare in front of it: “you would need to connect MCP for every single data source that will eat into your context.” This is the tool-layer cost the hosts measured back in episode #2, and it is a well-documented failure mode — Anthropic’s own engineering write-up on code execution with MCP notes that loading every tool definition upfront and routing intermediate results through the context window slows agents down and raises cost as the number of connected tools grows. Andrey’s product-side comment is the useful signal here, because it runs against the usual incentive: with B.O.R.I.S the team is “very conscious about the number of tools, and we constantly trying to reduce the number of tools there, not add.” Fewer tools, one unified interface, more of the window left for the work.
Vladimir adds two properties that pre-computation alone doesn’t buy. First, freshness: “it’s not even only pre-calculated, it’s automatically updated, so there is no old information in the context.” Second, live validation — the layer can go check a specific resource on demand instead of serving only its last snapshot, which is the difference between a cache and a source. And he names a mapping problem that quietly defeats a lot of home-grown tooling: a company with more than one AWS organization, where the agent has to reconcile identities and topology across both. “It’s also a confusion.” Andrey’s answer is that the interface shouldn’t change as you add systems — you search once, across everything, and get back what was found plus how it connects back to source code.
Skills hold judgment; state belongs in a database
Andrey is careful not to oversell the layer, and this is the most portable distinction in the episode. Context does not replace skills. Skills are where how-to instructions live, along with the business context that cannot be scraped out of any engineering system: the decisions a team made, the reasons, the “we do things this way, not that way” that otherwise exists only in people’s heads.
“But what you don’t want to put in the skills is ephemeral information, such as the state of your infrastructure.” He grants the case where text files are perfectly sufficient, which is what makes the argument credible: a hobby project or a home automation setup, one or maybe two accounts, VPC networking that never changes. Skills cover it, and something like OpenClaw — the open-source, self-hosted personal assistant that grew out of the project formerly called Clawdbot — can refresh those notes on a daily schedule. The moment the number of accounts, systems, and moving parts grows, that breaks in two specific ways: the file has to be maintained as reality drifts, and it has no historical dimension, because adding one makes it too big to load. “It’s just not the right medium. Actually, for this kind of stuff, you need to have a proper database.”
Then comes the line that reframes the category, and it is the opposite of a novelty pitch: “the concept is not new. If you’ve been in IT long enough, configuration database — that’s probably ring the bell.” In physical datacenters, teams tracked what was where in a configuration management database, the ITIL construct that stores configuration items and, importantly, the relationships between them, with change history for audit. Andrey’s framing: “this is like the configuration database of the agentic era.” The historical rhyme cuts both ways, which is worth saying out loud — CMDB programs have a long track record of failing on exactly the property the hosts are selling, staleness, when they depend on humans to update them. Continuous ingestion is the claim that has to hold up, and it is the right thing to test in an evaluation.
Context you own, and why egress is slow
If the conversation so far sounds like an argument for one vendor’s integration, the hosts’ own workflow argues the opposite. As Andrey points out, you can tell from the way they discuss these tools that they hold multiple subscriptions — Claude, Codex, Cursor. Each of those keeps its own memory, “but you can’t take the memories with you when you jump between.” A separate context layer solves that by construction: he gets the same picture in Claude that he gets in Codex, regardless of which harness he opened.
He goes further, and this is where the episode connects back to episode #7 and episode #12: he has tried to disable memory wherever he can. The reasoning is specific rather than ideological. A context layer gives the recent scraped state plus tools to check live state, while harness memory is written whenever the agent happens to touch something — so it can encode how things looked at the moment of a past edit and then present that as current. “Memory might be actually misguiding and doing you misservice in those coding agents.” The same decay applies to hand-written skill files that document where things are: someone has to keep them true.
The portability argument then turns into a lock-in argument, and it is the sharpest strategic point in the half hour. Teams will run multiple providers whether they plan to or not — Claude Code locally, Bedrock as the provider in CI, plus a bought agent running its own models — so owning the context and being able to plug it into a different system is what makes leaving a vendor survivable. “That’s actually quite a trap that people don’t think about today. Like, if you integrate any of those LLM vendors deeply, they will build a context about you, like Google building your search profile. Getting that out of them is a non-trivial task.” His evidence is secondhand and he says so: Vladimir told him about an acquaintance who tried to pull his data out of OpenAI and found the process moving very, very slowly.
Vladimir’s generalization is the part that doesn’t depend on any anecdote: “the egress, like putting things out, it’s usually painful and slow instead of putting things in.” The checkable version of this is in the vendors’ own help pages. OpenAI documents that a ChatGPT export can take up to seven days to arrive, with a download link that expires 24 hours later. Anthropic documents self-service export for individual plans with a delay while the export is generated — and, notably, states that exported data cannot be imported into another personal Claude account. Two honest qualifications belong here: documented latency is not proof of intent, which is what the hosts are inferring, and Anthropic does now publish an import/export path for Claude’s memory specifically. But the limitation the episode is really pointing at survives all of that. A ZIP of chat history is not portable engineering context, and no export button turns it into one.
Vladimir’s closing note on migration is the pragmatic split. Harness configuration is now cheap to move — “I believe you can ask AI, please move my codex configuration to cloud configuration, to cursor configuration, it will perfectly do it.” Context is not. “For a context, it’s better to have some tool.”
What this means for teams
Fernando’s summary is where the episode lands, and it connects straight to the trust argument he and Vladimir worked through in episode #16. Speed is the whole reason to adopt agents. “But if they start giving you wrong information, then it’s worse than if you would go slow, but actually do the thing properly.” What context buys, in his framing, is not intelligence but evidence: a reviewer looking at a pull request can go and check the basis for a claim. “Here’s proof that whatever change you are making here, it’s based on a fact.” That is also what makes the automations trustworthy enough to leave running — the triage loops, the security workflows — because their conclusions can be audited rather than believed.
Andrey’s own testimony is deliberately personal rather than analytical, and it is the most quotable thing he says all episode: “for me, there was the moment before and after. I’m so much not looking forward to running the agent without the context layer.” He pairs it with an admission that cuts against his own product: “the market maturation is still there, so the people do not realize what they need.” Read that as the honest state of the category — the hosts think this is a fundamental layer, and they also think most teams haven’t yet felt the pain that makes it obvious.
Four things a reader can act on this week:
- Check what your CI reviewer can actually see. If application code and Terraform live in separate repositories, the agent reviewing either one is working blind on the other unless someone configured cross-repository context. That is the cheapest place to notice whether context is missing.
- Ask the release question, not the style question. Vladimir’s version — what will this pull request break, and what should we watch after deploy — is a better test of a review tool than whether it finds a naming nit.
- Price the subscription-versus-on-demand question before you scale review automation. Cloud agents bill at the selected model’s API pricing against plan-included usage, and spill into on-demand charges once allowances run out — so set a spend limit and pilot the CLI-in-CI pattern rather than assuming it is covered. And on token pricing, watch the long-context bands: on the SpaceXAI API, Grok 4.6 prompts above 200k move to $4 / $1 / $12, a threshold Cursor does not document for its own routed pool.
- Keep judgment in skills and state in a database. How-to instructions, decisions, and conventions belong in skill files. Live topology does not, and a text file gives you no history without becoming unloadable.
One last thing the transcript preserves, and it is funnier in a show about agents than it would be anywhere else. Andrey closes with a quiz about the two flags on his sleeve — one red, yellow, red, which he says football fans will get immediately, and one white, blue, and yellow, which he concedes is harder — with a single rule attached: “Don’t ask AI or Google for that matter. Try to do work yourself first.” The answers are left where the hosts left them.
The episode is a half-hour trend check rather than a deep dive, so the takeaway is calibrated accordingly: the model race is now competitive enough that price and latency, not capability, are the interesting variables, and every new agent surface — a Slack teammate, a cloud reviewer, a CI job — inherits the same blind spot the moment it has to reason about infrastructure it cannot see.
Resources
- The Grok 4.6 launch, the price war around it, and the branding timeline: Cursor’s announcement and SpaceXAI’s announcement are the primary sources for the $2/$6 headline rate, the fast variant at double the price, and the benchmark claim the hosts discount — 61 on the Artificial Analysis Intelligence Index, level with GPT-5.6 Sol in Max mode, with Fable 5 Max a point ahead at 62. SpaceXAI’s release notes add the caveat that matters most for context-heavy sessions, scoped to SpaceXAI’s own API: $2 / $0.50 / $6 per million tokens standard, and $4 / $1 / $12 above 200k, a band Cursor does not document for its routed pool. Read alongside Claude Sonnet 5’s page, which confirms Andrey’s data point exactly — the introductory $2/$10 is now permanent and the $3/$15 rate scheduled for September 1 “no longer applies” — and Cursor is joining SpaceX, which gets the sequencing right: an April partnership, an acquisition that closed on August 14, 2026 (the day this was recorded), and Grok 4.5 and 4.6 released during that process rather than after it.
- Cursor’s own docs, for the economics Andrey wondered about on air: Models and pricing confirms that Cursor Grok 4.6 sits in the first-party included pool with Grok 4.5 and Composer 2.5, that all Auto modes bill at the routed model’s list price, and that the $0.25 per million Cursor Token Rate on third-party models applies on Teams and Enterprise plans with first-party models exempt. Cloud agents documents Vladimir’s review loop — comment
@cursoron a GitHub or Bitbucket PR and an agent picks it up — plus the multi-repository environments that let a reviewer see infrastructure and application code together. Cloud agents billing is the correction to the “it’s in their cloud so it’s on the subscription” intuition: charged at API pricing for the selected model, drawing on plan-included usage and then on-demand, which is why a spend limit is the first thing the docs ask for. Cursor CLI in GitHub Actions covers the mechanism, authenticating with an API key; what none of these pages settles is whether that CI usage lands inside plan allowances or outside them. - Introducing Claude Tag (Anthropic) and the Claude Tag docs — what replaced the old Claude in Slack app, and the details behind Andrey’s description: no per-seat charge but consumption-billed channel work against a funded balance with a spend limit, extensibility through connections, plugins and skills, an ephemeral sandbox per task, and memory attached to the channel rather than to your infrastructure. Pair with the MCP authorization specification for the core OAuth 2.1 resource-server model, and the optional OAuth Client Credentials extension for the headless case the hosts actually shipped — client ID and secret or a signed JWT assertion, with both client and server needing to support the extension, since extensions are opt-in and off by default.
- AI vulnerability triage: bug bounty reports at $2 each (Elastic Security Labs) and AI-driven report volume (HackerOne) — the measured version of Vladimir’s customer problem. HackerOne describes an industry-wide surge of more than 100% in report volume and is explicit that the impact varied by program, hitting public and open-source programs hardest. Elastic’s pipeline, built after 1,390+ reports in six months, is the closest published implementation of what he wants, and two of its design choices are the episode’s argument in production form — organization-specific rules encoding which things are features rather than vulnerabilities, and a human making the final call on every report.
- What is the Agent Toolkit for AWS? and Code execution with MCP (Anthropic) — read these together to see exactly where Andrey’s “yeah, you do” objection bites. The toolkit gives agents authenticated AWS API access, live docs, and on-demand skills specifically designed not to consume unnecessary context; it still doesn’t arrive knowing your estate, which is the per-session orientation cost. Anthropic’s post is the mechanism behind the multi-provider math: every additional connected server’s definitions and intermediate results compete with the work for window space.
- What is a configuration management database (CMDB)? (Red Hat) — background for the episode’s best reframe, “the configuration database of the agentic era.” Useful for the relationship-tracking and change-history parts that map cleanly onto a context layer, and useful as a warning: the classic failure mode of a CMDB is going stale, which is precisely the property continuous ingestion has to prove.
- Export reality check: exporting your ChatGPT history and data (OpenAI) — up to seven days to arrive, download link expiring after 24 hours — and export your Claude data (Anthropic), which notes an export can’t be imported into another personal Claude account. These document the friction the hosts describe without proving the intent they infer, and they make the deeper point better than the anecdote does: a chat archive was never portable engineering context.
- Prior episodes this one builds on: #12 — Semantic Layers, Context Layers, and Agents That Stop Guessing is the full version of the context-layer argument applied here to Slack agents and CI reviewers; #7 — Agent Memory is why Andrey disables harness memory rather than trusting it; #2 — The Tool Layer is where the MCP-per-data-source context cost was first measured on this show; #16 — How DevOps Makes AI Safe to Scale is the trust-and-evidence discussion Fernando refers back to in his closing; and #6 — The Big AI Squeeze is the token-economics episode behind Vladimir’s “it’s a competitive market and the price supposed to go a bit lower now.”