Blog

  • Cosmos DB vs Firestore: A Free-Tier Operations Ledger on Both Clouds

    Cosmos DB vs Firestore: A Free-Tier Operations Ledger on Both Clouds

    Every real content operation grows a small database it didn’t plan for: a ledger of what got published when, a metadata store tracking which article has an audio version, which has been translated, which is queued. It’s not big data — it’s a few thousand small records that need to be written cheaply, queried quickly, and never cost anything. The question is which cloud’s free NoSQL tier carries that load forever.

    We run the same small ops ledger and content-metadata store on both Azure Cosmos DB and Google Firestore, on the free tiers, and watch the quotas. Short answer: Cosmos DB’s always-free tier is unusually generous — 1,000 RU/s of provisioned throughput plus 25 GB of storage, free for the life of one account per subscription. Firestore’s free tier is simpler but tighter — 1 GiB of storage with 50,000 reads, 20,000 writes, and 20,000 deletes per day. For a metadata store that fits either, Cosmos gives you more room; Firestore gives you less to think about.

    This is the breakdown from the running lab on tygart.media — free-tier generosity, data model, query power, latency, and which one we’d trust with the ledger.

    The free-tier ceilings

    This is where the two diverge most, and the units don’t line up cleanly — which is itself the point.

    How we do it

    Azure Google Cloud Verdict
    Free throughput 1,000 RU/s provisioned 50K reads / 20K writes / 20K deletes per day Cosmos for steady throughput
    Free storage 25 GB 1 GiB Cosmos — 25× the storage
    Billing unit Request Units (RU/s) Per-operation daily quota Different mental models
    How many free tiers One per subscription Per project (Spark plan) Tie, structurally
    Fit for a metadata store Generous Comfortable for small stores Cosmos on headroom

    The mismatch in units is the real story. Cosmos meters everything in Request Units — a blended currency for reads, writes, and queries — and gives you a flat 1,000 RU/s continuously plus 25 GB. Firestore meters discrete daily operations — 50K reads, 20K writes, 20K deletes — and 1 GiB. For our ledger, Cosmos’s 25 GB is absurd headroom we’ll never approach, and 1,000 RU/s comfortably absorbs bursty publish events. Firestore’s daily caps are fine for a small store but you feel them: a chatty dashboard that re-reads the ledger on every page load can nibble through 50K reads faster than you’d expect.

    Data model and query power

    How we do it

    Azure Google Cloud Verdict
    Data model Multi-model (document, key-value, graph, column) Document (collections + docs) Cosmos on flexibility
    API surface NoSQL (SQL-like), MongoDB, Cassandra, Gremlin, Table Native Firestore SDK Cosmos on portability
    Query model Rich SQL-like queries, indexing tunable Indexed queries, real-time listeners Tie — different strengths
    Real-time sync Change feed First-class real-time listeners Firestore on live UI
    Schema Schema-agnostic Schema-agnostic Tie

    Cosmos is multi-model: the same data can be addressed through a SQL-like NoSQL API, MongoDB’s wire protocol, Cassandra, Gremlin (graph), or Table. If you ever want to query the ledger like a graph, or you’re migrating off MongoDB, that optionality is real and free. Firestore is single-purpose by design — document collections with excellent real-time listeners, which is the thing to reach for when a dashboard should update live as the ledger changes. For a metadata store feeding a UI, those listeners are genuinely pleasant.

    Latency and operational feel

    How we do it

    Azure Google Cloud Verdict
    Read latency Single-digit ms (tuned) Low, very consistent Tie at our scale
    Provisioning model Provisioned RU/s (or serverless) Fully managed, no capacity knobs Firestore on simplicity
    Capacity tuning You can over/under-provision Nothing to tune Firestore on hands-off
    Setup friction A few more knobs Near-zero Firestore

    At our volume, both are fast enough that latency never registered as a difference. The operational feel diverges: Cosmos hands you knobs (RU/s, consistency levels, indexing policy) — power if you want it, a thing to learn if you don’t. Firestore has almost no knobs, which is the right call when the database is a side character in your stack and you never want to think about capacity.

    What surprised us

    • Cosmos’s 25 GB always-free storage is wildly generous for a metadata store. We will not approach it. It reframed Cosmos from “enterprise database” to “perfectly viable free tier.”
    • Firestore’s daily read quota is the thing to watch. It’s not the storage that bites — it’s a chatty UI re-reading the ledger. Cache reads or you’ll surprise yourself.
    • The RU/s model has a learning curve. Cosmos’s Request Unit currency is unintuitive at first; once it clicks, capacity planning is straightforward, but day one is more conceptual than Firestore.
    • Firestore’s real-time listeners are a quiet joy. For a live dashboard, “the data just updates” without polling is worth a lot.

    The takeaway

    Pick Azure Cosmos DB if you want maximum free headroom — 1,000 RU/s and 25 GB is a lot of database for $0 — or you value multi-model flexibility and API portability (especially a MongoDB-compatible path). It’s our pick when the ledger might grow or change shape.

    Pick Firestore if you want the simplest possible managed document store with first-class real-time listeners and nothing to tune, and your store stays comfortably inside 1 GiB and the daily operation caps. It’s the right call when the database should disappear into the background.

    For our ops ledger, Cosmos’s always-free generosity is hard to argue with — but for the live dashboard that reads the ledger, Firestore’s real-time listeners are the nicer developer experience. Running the same store on both made the trade explicit instead of theoretical.

    This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud on the free tiers, keeping the same ops ledger on each to see where the quotas really pinch. The lab lives on tygart.media; the findings publish here.

    Frequently asked questions

    What does the free tier of Cosmos DB and Firestore actually include?
    Azure Cosmos DB’s always-free tier gives 1,000 RU/s of provisioned throughput plus 25 GB of storage, free for one account per subscription. Firestore’s free Spark tier gives 1 GiB of storage with 50,000 reads, 20,000 writes, and 20,000 deletes per day. Cosmos offers far more storage; Firestore meters by daily operations.

    Is Cosmos DB or Firestore more generous on the free tier?
    For storage and steady throughput, Cosmos DB is more generous — 25 GB and a continuous 1,000 RU/s versus Firestore’s 1 GiB and daily operation caps. Firestore is perfectly adequate for a small metadata store, but a chatty application can hit its daily read quota. Cosmos gives more headroom for growth.

    What’s the difference between Cosmos DB and Firestore’s data model?
    Cosmos DB is multi-model: the same data can be queried as documents, key-value pairs, graphs, or columns, and it speaks NoSQL, MongoDB, Cassandra, Gremlin, and Table APIs. Firestore is a focused document database — collections and documents — with excellent real-time listeners. Cosmos offers flexibility; Firestore offers simplicity.

    Which is better for a serverless content metadata store?
    Both work well. Choose Cosmos DB if you want generous free storage, multi-model flexibility, or a MongoDB-compatible path. Choose Firestore if you want a zero-tuning managed store with real-time listeners that update a dashboard live, and your data fits inside 1 GiB and the daily operation limits.

    Will I hit Firestore’s free quota with a small app?
    Storage usually isn’t the problem — 1 GiB holds a lot of small records. The daily read quota of 50,000 is what catches people: a dashboard that re-reads the same data on every page load can consume it quickly. Caching reads keeps a small app comfortably inside the free tier.

  • Azure Neural TTS vs Google Cloud Text-to-Speech: Audio Versions of Every Article

    Azure Neural TTS vs Google Cloud Text-to-Speech: Audio Versions of Every Article

    Adding an audio version of every article is one of those low-effort, high-leverage moves: it makes your content accessible to people who’d rather listen, it gives you a “play this article” widget that lifts time-on-page, and the audio file itself becomes another thing search and assistants can surface. The work is entirely automated — text goes in, an MP3 comes out — so the only real decisions are which voice sounds least like a robot and which free tier covers your back catalog.

    We auto-generate audio versions of the same articles on both Azure Neural TTS and Google Cloud Text-to-Speech, on the free tiers, and listen. Short answer: this one’s an honest toss-up. Both produce genuinely natural neural voices, both give you SSML control, and both run our audio pipeline for $0/month. Azure’s free tier is 500,000 characters/month (~60–80 article audio versions of neural voices); Google’s is 1,000,000 characters/month of Standard voices and 1,000,000 characters/month of WaveNet/Neural2 premium voices. Pick by ecosystem and by which voice you’d rather hear.

    This is the breakdown from the running lab on tygart.media — voice naturalness, SSML control, voice variety, free ceilings, and the accessibility/SEO payoff.

    The free-tier ceilings

    How we do it

    Azure Google Cloud Verdict
    Free neural/premium chars/month 500,000 (Neural) 1,000,000 (WaveNet/Neural2) Google — 2× headroom
    Free standard chars/month n/a (neural is the tier) 1,000,000 (Standard) Google on raw volume
    Roughly how many article audios ~60–80 neural/mo ~140 premium/mo Google
    Always-free Yes Yes Tie
    Our actual bill $0 $0 Tie where it counts

    A 1,200-word article runs around 6,500–7,000 characters, so Azure’s 500K neural budget covers roughly 60–80 full article audio versions a month, and Google’s 1M premium budget covers roughly twice that. For a publisher shipping a handful of articles a week, both stay free with room to spare — the 2× gap only bites if you’re voicing a large back catalog in one go.

    Voice quality and SSML control

    This is where you actually choose, and it’s genuinely close.

    How we do it

    Azure Google Cloud Verdict
    Voice naturalness Excellent, very expressive Excellent, very natural Tie — both clear the “robot” bar
    Voice variety Huge neural catalog, many styles Large WaveNet/Neural2 catalog Slight edge Azure on styles
    Speaking styles / emotion Yes (cheerful, newscast, etc.) More limited emotional styles Azure
    SSML control Full SSML + style/prosody tags Full SSML Azure, slightly
    Custom voice Yes (custom neural voice) Yes (custom voice) Tie
    Languages / locales 140+ locales 50+ languages, many voices Azure on locale breadth

    Both clear the bar that matters: neither sounds like a 2010-era text-to-speech engine, and a casual listener wouldn’t immediately clock either as synthetic. Azure edges ahead on expressiveness — its neural voices support named speaking styles (newscast, cheerful, empathetic) that are perfect for an article read-aloud, and its SSML supports fine prosody control. Google’s Neural2 voices are beautifully natural and, to some ears, a touch warmer; the emotional-style controls are just a little thinner.

    The accessibility and SEO payoff

    The audio isn’t only a nice-to-have. It does real work.

    How we do it

    Azure Google Cloud Verdict
    Accessibility win Listen instead of read Listen instead of read Tie
    Output format MP3 / WAV / streaming MP3 / LINEAR16 / OGG Tie
    Pipeline integration REST + SDKs REST + SDKs Tie
    Time-on-page lift Audio widget keeps people on page Same Tie

    An audio version gives screen-reader users and “I’d rather listen” users a first-class way to consume the piece, and the on-page player tends to lift dwell time — a signal that doesn’t hurt. The mechanics are identical on both clouds: feed text, get an MP3, embed it.

    What surprised us

    • Both are genuinely good now. We expected one to clearly win on naturalness and neither did — the synthetic-voice era is over on both clouds.
    • Azure’s speaking styles are the sleeper feature. Being able to render an article in a “newscast” or “cheerful” style without writing prosody by hand made the read-alouds noticeably more engaging.
    • Google’s free character budget is the bigger one. 1M premium characters is real headroom; if you’re voicing a back catalog, that matters more than a half-point of naturalness.
    • The MP3s are interchangeable. Once embedded, listeners couldn’t reliably tell which cloud voiced which article in a blind test we ran on ourselves.

    The takeaway

    Pick Azure Neural TTS if you want maximum expressiveness — named speaking styles, fine prosody control, and the broadest locale catalog — and your Microsoft ecosystem is already where the rest of your stack lives. The 500K free characters cover a normal publishing cadence comfortably.

    Pick Google Cloud Text-to-Speech if you want the larger free character budget (1M premium) for voicing a big back catalog, or you simply prefer the warmth of the Neural2 voices, and your stack is GCP-centric.

    For us this is the rare comparison with no loser. We run the pipeline on whichever cloud the rest of that article’s workflow already lives on — and the listener can’t tell the difference either way.

    This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud on the free tiers, generating audio versions of the same articles on each to hear where the voices differ. The lab lives on tygart.media; the findings publish here.

    Frequently asked questions

    How many free characters do Azure and Google text-to-speech give you per month?
    Azure Neural TTS gives 500,000 free neural characters per month, which is roughly 60–80 article audio versions. Google Cloud Text-to-Speech gives 1,000,000 free Standard characters and 1,000,000 free WaveNet/Neural2 premium characters per month, roughly double Azure’s premium headroom. Both stay free for a normal publishing cadence.

    Which text-to-speech sounds more natural, Azure or Google?
    Both produce genuinely natural neural voices, and in blind listening neither clearly wins. Azure edges ahead on expressiveness with named speaking styles like newscast and cheerful, while Google’s Neural2 voices are very natural and, to some ears, slightly warmer. The synthetic-robot problem is solved on both.

    Can I auto-generate an audio version of every blog post for free?
    Yes. Both clouds expose a simple REST API that turns article text into an MP3, and their free character budgets cover a typical few-articles-a-week cadence at $0. Google’s larger free budget is better if you want to voice a big back catalog in one pass.

    Does Azure Neural TTS support SSML and speaking styles?
    Yes. Azure supports full SSML plus named speaking styles (newscast, cheerful, empathetic and more) and fine prosody control, which makes article read-alouds noticeably more engaging. Google also supports full SSML, but its emotional-style controls are thinner.

    Does adding an audio version of articles help accessibility and SEO?
    Yes. An audio version gives screen-reader and listen-first users a first-class way to consume the content, improving accessibility, and the on-page audio player tends to lift time-on-page, which is a positive engagement signal. The benefit is identical whether you generate the audio on Azure or Google.

  • Azure Translator vs Google Cloud Translation: 2M Free Characters, Tested

    Azure Translator vs Google Cloud Translation: 2M Free Characters, Tested

    Translating your content is one of the cheapest ways to multiply its reach — every article becomes five articles the moment you ship it in five languages. The catch is that machine translation is metered by the character, and a content pipeline burns characters fast. So the real question for a bootstrapped publisher isn’t “which engine is best?” — it’s “which free tier lets me run a multilingual pipeline forever without ever seeing a bill?”

    We translate the same articles into multilingual variants on both Azure Translator and Google Cloud Translation, on the free tiers, and watch where each one runs out. Short answer: for a perpetual $0 pipeline, Azure Translator wins on the ceiling — its free tier is 2,000,000 characters/month and it’s always free, which is roughly 300 article-length translations a month. Google Cloud Translation gives you a generous-but-capped 500,000 characters/month and then it’s paid, and it earns its keep on quality and language coverage.

    This is the breakdown from the running lab on tygart.media — free ceilings, translation nuance, document vs text, and which one we actually point the pipeline at.

    The free-tier ceilings

    This is the headline difference, and it’s not close.

    How we do it

    Azure Google Cloud Verdict
    Free characters/month 2,000,000, always free 500,000, then paid Azure — 4× the ceiling
    Roughly how many articles ~300 article translations/mo ~75 article translations/mo Azure
    What happens at the cap Pay-as-you-go kicks in Pay-as-you-go kicks in Tie (mechanism)
    Always-free vs 12-month trial Always free Always free (the 500K is perpetual) Tie
    Fit for a perpetual pipeline Excellent Tight Azure

    The math is the whole story. A typical 1,200-word article is around 6,500–7,000 characters. Translate it into five languages and you’ve spent ~35,000 characters on one article. Azure’s 2M ceiling absorbs dozens of articles across multiple languages every month without a cent; Google’s 500K runs dry after a couple of weeks of the same cadence. If your single hard constraint is “never pay for translation,” Azure is the answer before you even look at quality.

    Translation quality and nuance

    Free ceilings decide whether you can run the pipeline. Quality decides whether you should publish what comes out.

    How we do it

    Azure Google Cloud Verdict
    Engine Neural MT, custom models available Neural MT (NMT), strong general model Slight edge Google on nuance
    Idiom / register handling Good, occasionally literal More natural on idioms and tone Google
    Technical terminology Reliable, customizable glossary Reliable Tie
    Custom/glossary control Custom Translator + dictionary Glossary + AutoML (paid) Azure on free customization
    Major-language quality Excellent both ways Excellent both ways Tie

    On high-resource languages — Spanish, French, German, Portuguese — both engines produce output we’d publish with a light editorial pass. Google has a slight edge on idiom and register: it tends to “sound like a person” a beat more often, especially on conversational copy. Azure closes most of that gap with Custom Translator and inline dictionaries, which let you pin brand terms and preferred phrasings — and those customization tools are usable inside the free workflow.

    Language coverage and document mode

    How we do it

    Azure Google Cloud Verdict
    Languages supported 100+ 100+ (NMT subset varies) Tie
    Long-tail / low-resource Broad Broad, often strong Google, slightly
    Document translation Yes (preserves formatting) Yes (separate API surface) Tie
    Text translation API Simple REST Simple REST Tie
    Batch throughput High High Tie

    Both clouds clear 100 languages, so coverage isn’t a deciding factor for a Western-market content site. Document translation — feeding in a formatted file and getting the same layout back in another language — exists on both; we mostly use plain text translation because our content is markdown and we re-render it ourselves.

    What surprised us

    • The character ceiling, not the quality, is the real constraint. We went in expecting a quality shootout and came out realizing that for a content pipeline, “2M free vs 500K free” decides the workflow long before anyone compares a single sentence.
    • Azure’s always-free 2M is genuinely always free. It’s not a 12-month trial that lapses into charges — it resets every month indefinitely. That’s rare enough that we double-checked it.
    • Google’s output reads slightly more human on conversational copy. For marketing-voice pieces we noticed Google needed less editorial cleanup; for technical articles the two were indistinguishable.
    • Glossaries matter more than the base engine. Once you pin your brand and product terms, the gap between the two narrows to almost nothing.

    The takeaway

    Pick Azure Translator if your priority is a perpetual multilingual content pipeline that never bills you — the 2M-character always-free ceiling is built for exactly this, and Custom Translator gives you brand-term control for free. It’s our default for high-volume article translation.

    Pick Google Cloud Translation if quality on conversational, idiom-heavy copy is your top concern and your volume fits comfortably under 500K characters/month — its NMT output tends to need a lighter editorial pass.

    For us, running the same site on both clouds, the translation pipeline lives on Azure: at our cadence we’d blow through Google’s free tier in two weeks, and Azure’s ceiling means the multilingual variants ship at $0, month after month.

    This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud on the free tiers, translating the same articles on each to see where the ceilings really sit. The lab lives on tygart.media; the findings publish here.

    Frequently asked questions

    How many free characters do Azure Translator and Google Cloud Translation give you per month?
    Azure Translator’s free tier is 2,000,000 characters per month and it’s always free, resetting every month indefinitely. Google Cloud Translation’s free tier is 500,000 characters per month, after which you pay per character. For a content pipeline, Azure’s ceiling is roughly four times larger.

    Which machine translation is more accurate, Azure or Google?
    Both use neural machine translation and produce publish-quality output on major languages. Google has a slight edge on idiom, tone, and conversational register, while Azure closes most of that gap with its free Custom Translator and dictionary features. For technical content the two are hard to tell apart.

    Can I run a multilingual website translation pipeline for free?
    Yes. Azure Translator’s 2,000,000 free characters per month is enough for roughly 300 article-length translations, which covers a typical publishing cadence across several languages at $0. Google’s 500,000 free characters works for lower-volume sites but runs out faster at the same pace.

    Does Azure Translator support document translation that keeps formatting?
    Yes. Azure offers a document translation mode that preserves the original layout and formatting of files, alongside a simple text translation REST API. Google Cloud Translation offers document translation too. We mostly use plain text translation because our content is markdown that we re-render ourselves.

    How many languages do Azure Translator and Google Cloud Translation support?
    Both support more than 100 languages, so coverage is rarely the deciding factor for a Western-market site. Google sometimes edges ahead on lower-resource languages, but for common European and Latin American languages the two are equivalent in reach.

  • Bing Webmaster Tools vs Google Search Console: What Each Tells You (and the 84% Lesson)

    Here’s the number that reorganized how we think about search: ~84% of our organic traffic comes from Bing. Not Google. Bing — and the Copilot and ChatGPT surfaces that draw on Bing’s index. Yet for a long time, like nearly everyone, we watched only Google Search Console and treated Bing as an afterthought.

    That’s the blind spot this article is about. Short answer: use both consoles, but if Bing drives your traffic, stop treating Bing Webmaster Tools as optional — it has data, indexing controls, and an AI-insights surface that Google Search Console doesn’t, and it’s reporting on the search engine that’s actually sending you readers.

    This is the side-by-side from running both consoles on the same media property: what each one tells you, where Bing is quietly ahead, and how we wired the Bing Webmaster Tools API into our editorial calendar.

    The core reporting — query, position, CTR

    At the surface, the two consoles look like twins. Both give you queries, impressions, clicks, average position, and CTR. The differences are in coverage and freshness.

    How we do it

    Job Bing Webmaster Tools Google Search Console Verdict
    Query / position / CTR Yes, per query and page Yes, per query and page Tie on the basics
    Data freshness Often faster to update ~2-3 day lag Bing edges ahead
    Historical window Generous 16 months Toss-up
    API access Full API: position + CTR per query/page Search Analytics API Bing — the API is the underrated weapon
    AI / Copilot insights Dedicated AI-traffic insights No equivalent surface yet Bing, clearly
    Market it reports on Bing + Copilot + ChatGPT-via-Bing Google only Depends on your traffic mix

    The honest read: for the basic dashboard, they’re close enough that you’d never switch for the UI. The reasons to take Bing seriously are whose traffic it reports on and what it lets you do about it — the AI insights tab and the API.

    Indexing: IndexNow vs crawl-when-it-feels-like-it

    This is the most concrete operational difference, and it’s lopsided.

    How we do it

    Job Bing Webmaster Tools Google Search Console Verdict
    Tell it about a new URL IndexNow — push, indexed near-instantly URL Inspection → “Request indexing” (queued) Bing — push beats poll
    Bulk submission IndexNow ping + sitemap Sitemap, then wait Bing
    Control over crawl Crawl control, block/allow Limited crawl controls Bing — more knobs
    Re-crawl on edit Re-ping IndexNow Hope, or re-request Bing

    IndexNow is the standout. Instead of submitting a sitemap and waiting for a crawler to wander by, you push a URL the moment it changes and it’s picked up almost immediately — and because IndexNow is a shared protocol, one ping notifies participating engines. Google’s model is still largely “request indexing and wait.” For a content site that publishes and edits constantly, push beats poll every time. We ping IndexNow on publish and on every meaningful edit.

    The AI / Copilot insights tab

    Google Search Console has no real equivalent here yet. Bing Webmaster Tools surfaces AI-traffic insights — visibility into how your content shows up across Bing’s AI-powered and Copilot surfaces. Given that those surfaces (and ChatGPT’s web results, which draw on Bing) are an increasing share of how people find answers, this is the single console feature most aligned with where discovery is heading. If you care about GEO at all, it’s the dashboard that tells you whether the AI assistants are actually pulling you in.

    Wiring the BWT API into the editorial calendar

    The Bing Webmaster Tools API is the part most sites never touch, and it’s the most actionable. It returns position and CTR per query and per page — which is a ready-made content-optimization loop:

    1. Pull query/position/CTR from the BWT API on a schedule.
    2. Find pages ranking on page one with weak CTR (good position, bad headline/meta) — fast wins.
    3. Find queries where we rank position 5-15 with real impressions — the “one good edit from page one” list.
    4. Feed both lists straight into the editorial calendar as prioritized rewrites.

    Because Bing drives most of our traffic, this loop is pointed at the engine that actually moves our numbers. Running the same loop off Google Search Console’s API would optimize for the 16% of traffic, not the 84%.

    What surprised us

    • Bing’s data is often fresher than Google’s. We frequently see new queries in Bing Webmaster Tools before they show up in Search Console.
    • IndexNow is faster than anything Google offers — and it’s free and standard. The gap between “push and it’s indexed” and “request and wait” is real and daily.
    • The AI insights tab has no GSC counterpart. For a site doing GEO, that’s the most forward-looking surface either console offers.
    • Almost nobody verifies their site in Bing Webmaster Tools. You can import directly from Google Search Console in a couple of clicks, so the only reason most sites skip it is that they’ve never looked at where their traffic comes from.

    The takeaway

    This was never a “pick one” — it’s “stop ignoring one.” Google Search Console is still essential; Google isn’t going anywhere. But running only GSC is a bet that Google’s view of your site is the only one that matters, and our traffic data says that bet is wrong by a factor of five.

    Use both. Watch Google Search Console for the Google slice. But if a large share of your organic traffic comes from Bing — and a surprising number of content sites are in exactly that position without checking — then Bing Webmaster Tools is your primary console: fresher data, IndexNow for instant indexing, the AI/Copilot insights surface, and an API you can wire straight into your editorial calendar.

    The 84% lesson is simple: measure where your readers actually come from, then watch the console that reports on it. For us, that meant promoting Bing from afterthought to the dashboard we open first.

    This is part of our “Two Clouds, One Site” series — we run the same media property on Azure and Google Cloud, on the free tiers, and report what watching both ecosystems actually teaches us. The lab lives on tygart.media; the findings publish here.

    Frequently asked questions

    Should I use Bing Webmaster Tools if I already use Google Search Console?
    Yes — they report on different search engines, so using only Google Search Console hides all of your Bing performance. If any meaningful share of your traffic comes from Bing, Copilot, or ChatGPT’s Bing-powered results, Bing Webmaster Tools shows data and offers indexing controls that Search Console doesn’t. You can import your site from Search Console in a couple of clicks.

    What is IndexNow and is it faster than Google indexing?
    IndexNow is a protocol that lets you push a URL to search engines the moment it’s published or changed, instead of waiting for a crawler. It’s typically much faster than Google’s “request indexing and wait” model, and because it’s a shared standard, one ping notifies participating engines. For sites that publish or edit frequently, it’s a meaningful indexing-speed advantage.

    Does Bing Webmaster Tools have an API?
    Yes. The Bing Webmaster Tools API exposes per-query and per-page data including position and CTR, plus URL submission. That makes it practical to pull your search performance on a schedule and feed it into a content-optimization loop — for example, flagging page-one results with weak CTR or near-miss rankings to prioritize for rewrites.

    What does the Bing Webmaster Tools AI insights tab show?
    It surfaces how your content appears across Bing’s AI-powered and Copilot surfaces, giving visibility into AI-driven discovery that Google Search Console has no direct equivalent for yet. For sites focused on Generative Engine Optimization, it’s the most forward-looking view either console offers into whether AI assistants are pulling in your content.

    Why would a site get most of its traffic from Bing instead of Google?
    It’s more common than people assume, especially for niche or B2B content, sites strong in Bing-heavy regions or browsers, and content that surfaces well in Copilot and ChatGPT’s Bing-powered results. The lesson is to measure your actual referral mix rather than assume Google dominates — many sites only discover their Bing share once they verify in Bing Webmaster Tools.

  • Azure Functions vs Cloud Run: We Ran the Same Worker on Both

    Pick a serverless platform and you’re picking a default for the next five years of your stack. Most comparisons of Azure Functions vs Google Cloud Run are written from the docs. This one isn’t — we deployed the same worker to both, in production, on the free tiers, and watched what happened.

    The worker is simple on purpose: it takes a webhook, does a little work, writes a record, returns JSON. The kind of glue every real system has dozens of. Boring is exactly what you want when you’re measuring the platform and not the app.

    The short answer

    If you just want the verdict: Cloud Run wins for anything containerized and anything where you care about not storing deploy keys. Azure Functions wins when your automation already lives in the Microsoft ecosystem and benefits from Logic Apps, Event Grid, and Entra sitting right next door. Both run our worker for $0/month. The tie-breakers are deploy security and what else is in the neighborhood.

    Now the detail.

    Deploying the same worker

    This is where the two platforms feel most different, and where Google Cloud quietly pulls ahead.

    How we do it

    Azure Functions Google Cloud Run Verdict
    Unit of deploy Function app (code + host) Container image Cloud Run if you’re already containerized
    Deploy auth Publish profile / service principal Workload Identity Federation — no stored keys Cloud Run, decisively
    Cold start Noticeable on Consumption plan Negligible at our scale Cloud Run
    Local dev parity Functions Core Tools (good) “It’s just a container” (great) Cloud Run

    The headline is the deploy auth. Our Cloud Run workers deploy from GitHub Actions using Workload Identity Federation — GitHub proves its identity to Google with a short-lived token, and no service-account key is ever stored in the repo. That’s not a convenience; it’s the single biggest reduction in credential risk you can make in a CI/CD pipeline. Azure Functions can get close with OIDC + a service principal, but the container-native, keyless Cloud Run path was simpler to lock down and is the model we standardized on.

    What the free tier actually gives you

    Both platforms have genuinely generous always-free serverless tiers. The numbers that matter for a glue worker:

    How we do it

    Metric Azure Functions Google Cloud Run Verdict
    Free requests/month 1,000,000 2,000,000 Google — 2× headroom
    Free compute 400,000 GB-s 360,000 GiB-s + 180,000 vCPU-s Roughly even
    Scale to zero Yes (Consumption) Yes Tie
    Max instances control Yes Yes (and per-service concurrency) Cloud Run, slightly
    Our actual bill $0 $0 Tie where it counts

    At our volume — thousands of invocations a month, not millions — both are free and stay free. The 2M-vs-1M request gap only matters if you’re genuinely high-traffic. For most glue workloads, you will never see a bill on either.

    The neighborhood effect

    A serverless function is rarely alone. It fires because something happened and it triggers something else afterward. That’s where the ecosystems diverge — and where Azure earns its keep.

    • Azure Functions sits next to Logic Apps (4,000 free built-in actions/month), Event Grid (100,000 free operations/month), and Entra ID for identity. If your automation is event-driven and Microsoft-centric, the glue around the function is already there and already free.
    • Cloud Run sits next to Eventarc, Cloud Workflows, Pub/Sub, and Cloud Scheduler — the same pattern on Google’s side, equally capable.

    Neither is “better” in the abstract. The right answer is whichever cloud your other services already live in. A function that triggers a Logic App next door beats a function that has to reach across clouds to do the same thing.

    What surprised us

    • Cloud Run cold starts basically disappeared. At our concurrency the container was warm often enough that we stopped thinking about it. Azure Functions on the Consumption plan had more noticeable cold starts for the same workload.
    • Azure’s free side-resources are real. Functions itself is free, but watch the storage account and Application Insights it provisions alongside — those can accrue tiny charges. Set a budget alert on day one.
    • Keyless deploy changed our security posture more than any single config. Once the repo holds zero secrets for deploys, an entire category of “leaked key” incidents just can’t happen.

    The takeaway

    For a containerized, security-conscious, GitHub-Actions-driven stack, Cloud Run is our default — the keyless deploy and the request headroom settle it. But “default” isn’t “only”: when a workload belongs in the Microsoft ecosystem — triggered by Microsoft events, feeding Microsoft services, governed by Entra — Azure Functions is the right tool, and it runs for the same $0.

    Run the same worker on both for a week. The platform stops being a religious debate and becomes a placement decision: put the work where its neighbors already are.

    This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud, on the free tiers, and write up what we learn. The lab lives on tygart.media; the findings publish here.

    Frequently asked questions

    Is Azure Functions or Cloud Run cheaper?
    For typical glue workloads, both are free and stay free. Cloud Run offers more free requests per month (2M vs 1M) and Azure offers 400,000 GB-seconds of free compute. At thousands of invocations a month you will not see a bill on either; the cost difference only appears at high traffic.

    Which is more secure to deploy?
    Cloud Run, because it supports keyless deploys via Workload Identity Federation — GitHub Actions authenticates with a short-lived token and no service-account key is stored in the repo. Azure Functions can approximate this with OIDC and a service principal, but the container-native keyless path is simpler to secure.

    Can I run the same code on both Azure Functions and Cloud Run?
    Yes. If you package the worker as a container, Cloud Run runs it directly and Azure Functions can run it via a custom handler or containerized function. We deploy the same worker logic to both; the differences are in deploy tooling and the surrounding event services, not the code.

    When should I choose Azure Functions over Cloud Run?
    Choose Azure Functions when your automation already lives in the Microsoft ecosystem — triggered by Event Grid, orchestrated by Logic Apps, or governed by Entra ID. Co-locating the function with the services it talks to beats reaching across clouds.

    Do serverless cold starts matter on either platform?
    At moderate concurrency, Cloud Run cold starts were negligible in our testing because the container stayed warm. Azure Functions on the Consumption plan showed more noticeable cold starts for the same workload. For latency-sensitive endpoints, test under your real traffic before deciding.

  • The $0 Cloud Stack: Running a Real Media Site on Azure and Google Cloud Free Tiers

    Most “Azure vs Google Cloud” articles are written by people who run neither in production. They paraphrase the pricing pages and call it a comparison.

    We do something different: we run the same media property on both clouds at the same time — and the entire thing costs $0/month. Google Cloud is the live operational stack. Azure is a parallel “newsroom” of always-free services running on a dedicated lab domain, tygart.media, mirroring each capability of the live site. Two clouds, one operation, both AI ecosystems watching it work.

    This is the desk-by-desk breakdown — what each cloud actually does for us, where the free tier runs out, and which one wins each specific job. No theory. This is the running system.

    Why run on both clouds at once

    There’s a strategic reason beyond “free is fun.” Search and AI assistants don’t share a brain. Google’s models optimize for Google’s index; Microsoft’s Copilot and Bing optimize for Microsoft’s graph. When ~84% of your organic traffic comes from Bing, having your stack only inside Google’s telemetry is a blind spot.

    Running enrichment through Azure puts the same content inside Microsoft’s service graph the same way Google Cloud puts it inside Google’s. You stop guessing how each ecosystem sees you, because you’re operating inside both.

    The serverless compute plane

    The heart of the stack: code that runs after you push a file and close the laptop.

    How we do it

    Azure Google Cloud Verdict
    Service Azure Functions Cloud Run Cloud Run for containers; Functions for glue
    Free ceiling 1M requests/month 2M requests/month Google, on raw headroom
    Deploy model Functions Core Tools / GitHub Actions Keyless deploy via Workload Identity Federation Google — no stored keys is a real security win
    What surprised us Generous, but watch billable side resources Cold starts negligible at our scale —
    Our bill $0 $0 Tie where it counts

    Pick Cloud Run if you’re already containerized and want keyless CI/CD. Pick Azure Functions if your automation lives in the Microsoft ecosystem and you want Logic Apps next door.

    The content enrichment desks

    This is where Azure’s always-free tier quietly outclasses expectations — a full newsroom of AI services that never bill at our volume.

    How we do it

    Job Azure Google Cloud Verdict
    Translation Translator — 2M chars/mo free (~300 articles) Cloud Translation Azure — bigger perpetual free ceiling
    Article audio Neural TTS — 500K chars/mo Cloud Text-to-Speech Toss-up; both natural
    Entity extraction (for GEO) AI Language — 5K records/mo Cloud Natural Language Azure — likely the same signal family Bing uses
    Site search Azure AI Search — 3 indexes free Vertex AI Search Azure — it’s the engine behind Bing

    The entity-extraction line matters most. We feed articles through Azure AI Language to pull named entities and key phrases, then saturate the content with them. We’re optimizing for the same entity signals Microsoft’s own systems use to select content — which is the whole game when Bing drives most of your traffic.

    The storage and front-end layer

    How we do it

    Job Azure Google Cloud Verdict
    Document store Cosmos DB — 1,000 RU/s + 25GB free Firestore Azure — Cosmos free tier is generous (one per subscription)
    Relational Azure SQL — serverless free Cloud SQL (no perpetual free) Azure, clearly
    Static hosting Static Web Apps — 100GB bandwidth Firebase Hosting Tie; both excellent

    For a small operations ledger or a knowledge base, Azure’s always-free Cosmos DB and serverless SQL are the standout — Google Cloud has no equivalent perpetual-free relational tier.

    What it actually costs: nothing (if you’re disciplined)

    The honest caveat: free compute can still trigger billable side resources. A “free” VM drags along disks, public IPs, and monitoring logs that bill immediately with no throttling. The discipline that keeps the bill at zero:

    1. Deploy from the free-services blade, not the general catalog.
    2. Set a budget alert on day one — before you provision anything.
    3. Prefer serverless over VMs — the consumption tiers reset monthly and don’t drag side resources.
    4. One Cosmos DB free tier per subscription — plan around it.

    Do that, and a real, AI-enriched media property runs across two clouds for $0.

    The takeaway

    Single-cloud is a bet that one ecosystem’s view of your content is the only one that matters. When the traffic data says otherwise — when most of your readers arrive through the other company’s search and AI — bilateral cloud stops being a novelty and becomes the obvious posture. The free tiers make it cost nothing but discipline.

    Frequently asked questions

    Is it really free to run on both Azure and Google Cloud?
    Yes, at small-site scale. Both clouds offer always-free serverless tiers (Azure Functions 1M requests/month, Cloud Run 2M requests/month) plus free AI, storage, and hosting services. The cost risk is billable side resources like VM disks and public IPs — avoidable by staying serverless and setting a budget alert.

    Which is better for serverless, Azure or Google Cloud?
    Cloud Run wins on raw request headroom (2M vs 1M/month) and keyless deploys via Workload Identity Federation. Azure Functions wins if your automation already lives in the Microsoft ecosystem and benefits from Logic Apps and Event Grid next door.

    Why would you run the same site on two clouds?
    AI ecosystems don’t share telemetry. Google’s models favor Google’s index; Bing and Copilot favor Microsoft’s graph. If a large share of your traffic comes from Bing, running enrichment through Azure puts your content inside Microsoft’s service graph instead of leaving it a blind spot.

    Does Azure have a better free tier than Google Cloud?
    For perpetual always-free services, Azure is broader — 65+ always-free services including Cosmos DB (1,000 RU/s + 25GB) and serverless Azure SQL, which Google Cloud has no direct perpetual-free equivalent for. Google Cloud wins on serverless request volume and keyless security.

    What’s the catch with Azure’s always-free tier?
    Limits reset monthly and overages bill immediately with no throttling. Free VMs also trigger billable disks, public IPs, and monitoring logs. Deploy from the free-services blade, prefer serverless, and set a budget alert before provisioning.

  • Anthropic’s Real Play Isn’t a Chatbot — It’s the Invisible Agent Layer Inside Every Tool You Use

    Anthropic’s Real Play Isn’t a Chatbot — It’s the Invisible Agent Layer Inside Every Tool You Use


    Claude Managed Agents is the product. Slack, Notion, Jira, and Asana are just the interface. Anthropic is building the invisible execution layer that powers the next generation of enterprise software.

    There is a pattern emerging in enterprise AI that most people are reading wrong. They see Anthropic launch Claude Tag in Slack and think “chatbot upgrade.” They see Claude show up inside Notion and think “productivity feature.” They see AI agents appear in Jira and Asana and think “automation plugin.”

    They are missing the architecture underneath all of it.

    Anthropic is not building a better chatbot. It is building the invisible agent runtime that sits beneath every collaboration tool your team already uses. The company’s Claude Managed Agents (CMA) platform — launched in public beta on April 8, 2026 — is the infrastructure layer that makes this possible. And the speed at which partners are embedding it tells you everything about where enterprise software is heading.

    What Claude Managed Agents Actually Is

    Claude Managed Agents is a set of composable APIs for building and deploying production AI agents on Anthropic’s cloud infrastructure. The service handles sandboxed code execution, session persistence, credential management, scoped permissions, and end-to-end tracing — all the operational complexity that previously kept agents stuck in proof-of-concept limbo.

    The architecture rests on three primitives: the Agent (configuration and behavior), the Environment (sandboxed execution), and the Session (the event log that tracks everything the agent does). What makes this interesting architecturally is how Anthropic decoupled the “brain” from the “hands.” Claude’s reasoning runs on Anthropic’s own infrastructure while the code execution sandbox spins up independently — and in parallel. The brain starts reasoning immediately while the sandbox provisions, delivering roughly 60% faster time-to-first-token at the p50 level and over 90% faster at p95, according to Anthropic’s engineering team.

    Pricing follows a transparent model: standard Claude API token rates plus $0.08 per session-hour of active runtime during the current beta period. Runtime is measured to the millisecond and only accrues while the agent is actively executing — idle time waiting for input or tool confirmations does not count.

    For teams that need to keep execution inside their own perimeter, CMA supports self-hosted sandboxes through partners including Cloudflare, Daytona, Modal, and Vercel, or custom VPC deployments. MCP tunnels allow agents to connect to private Model Context Protocol servers inside your network without exposing them to the public internet. A Vaults system keeps credentials out of the sandbox entirely using envelope encryption. And a feature called Dreaming runs scheduled reviews of past sessions to curate agent memory — essentially letting agents learn from their own operational history.

    The Embedded Layer: Where CMA Actually Lives

    The real story is not the infrastructure. It is where that infrastructure shows up. In the ten weeks since CMA launched, Anthropic has embedded its agent runtime inside the collaboration tools that enterprises already depend on. This is not a roadmap — these integrations are live or in active beta.

    Slack: Claude Tag as Persistent Team Member

    Claude Tag, launched June 23, 2026, replaces Anthropic’s original Claude in Slack integration with something fundamentally different. This is not a chatbot you summon with a slash command. It is a persistent AI team member that lives in your channels, builds memory across conversations, and can take initiative through what Anthropic calls “ambient mode” — proactively surfacing information, following up on forgotten threads, and keeping teams updated across the organization.

    Claude Tag is multiplayer by design: one Claude identity per channel, accessible to everyone, with the ability to hand off half-finished tasks between team members. It runs on Claude Opus 4.8, Anthropic’s most capable model released May 28, 2026. And internally, Anthropic reports that Claude Tag is already approving and incorporating 65% of the code changes their product team submits. The existing Claude in Slack app will be retired on August 3, 2026. Claude Tag is available on Enterprise and Team plans.

    Notion: Claude as External Agent

    On May 13, 2026, Notion launched its Developer Platform version 3.5, which introduced the External Agents API. This API lets AI agents — including Claude — operate inside your Notion workspace as first-class participants. They can read pages, write to databases, create tasks, trigger automations, and be @-mentioned directly in documents. Claude operating through this API can chain actions together: read a project brief, check the task database for related work, draft a new document, and create a linked task entry — all in a single session, running on CMA infrastructure with full sandboxing.

    Asana: AI Teammates

    Asana built AI Teammates on CMA — agents that pick up assigned tasks inside projects, draft deliverables, and hand back outputs for human review. Specialist agents handle specific workflows: the Campaign Brief Writer turns scattered notes into structured briefs, the Workflow Optimizer identifies process gaps and builds automations, and the Compliance Specialist checks work against regulatory standards. Asana’s CTO said CMA let them ship these features “dramatically faster” than any prior approach to agent development.

    Atlassian: Claude Agent for Jira

    Atlassian released Claude Agent for Jira, built on CMA infrastructure, which lets teams assign work items directly to Claude from the Jira UI. The agent clones the repository, analyzes the codebase, implements changes on an independent branch, pushes the code, and opens a draft pull request — streaming real-time status updates back to the Jira work item throughout the process.

    Sentry: From Bug Detection to Merge-Ready PR

    Sentry’s existing AI debugging agent, Seer, already used Claude for root cause analysis. With CMA, Sentry extended the workflow from diagnosis to automated fixing — the agent takes Seer’s root cause output, generates a fix, opens a branch with the changes, and creates a pull request for developer review. Sentry processes over one million root cause analyses per year and provides near-immediate reviews on over 600,000 pull requests per month. The CMA integration was built by a single engineer in weeks, eliminating months of custom agent runtime development.

    Rakuten: Specialist Agents Across the Enterprise

    Rakuten deployed specialist agents across product, sales, marketing, and finance using CMA, with each agent deployed in approximately one week. Agents plug into Slack and Teams, letting employees assign tasks and receive deliverables including spreadsheets, slides, and applications. In the pilot, Rakuten reported a 97% drop in critical first-pass errors, with cost down more than 30% and latency reduced by 34%, without any loss in output quality.

    KPMG: Global Professional Services Alliance

    On May 19, 2026, KPMG and Anthropic announced a global alliance and launched “Digital Gateway Powered by Claude.” The partnership embeds Claude, Cowork, and CMA directly into KPMG’s client delivery platform, with an initial focus on tax and private equity clients. Building an AI agent for tax regulation workflows previously took weeks and required switching between multiple tools. With CMA integrated into Digital Gateway, KPMG says the same capability takes minutes. The alliance extends to KPMG’s 276,000-person global workforce.

    The Strategic Pattern: Agent Runtime as a Service

    Step back from the individual integrations and the strategic pattern becomes clear. Anthropic is not trying to own the interface. It is deliberately positioning CMA as the execution layer underneath interfaces that other companies own. Slack owns the messaging UI. Notion owns the workspace UI. Jira owns the project tracking UI. Anthropic owns the agent brain that powers all of them.

    This is a fundamentally different strategy from its two largest competitors.

    OpenAI chose vertical integration. When OpenAI launched Workspace Agents on April 22, 2026, it positioned ChatGPT itself as the central hub — a no-code successor to custom GPTs that connects to Slack, Salesforce, Google Drive, and Notion through plugins. Agents are created inside ChatGPT, accessed from ChatGPT, and managed through ChatGPT. OpenAI wants to own the surface area.

    Google chose platform depth. At Google Cloud Next on April 22, 2026, Google unveiled the Gemini Enterprise Agent Platform — a reimagined evolution of Vertex AI — alongside Workspace Intelligence, a semantic unifying layer that connects data across Docs, Slides, Gmail, and the broader Google Cloud ecosystem. Google’s agent platform supports 200+ models including Claude, and the Agent2Agent (A2A) protocol enables distributed peer-to-peer agent communication. Google is leveraging its data moat and distribution at the platform level.

    Anthropic chose tool-centric orchestration. Rather than owning the UI (OpenAI) or the platform (Google), Anthropic is embedding its agent runtime into every tool through composable APIs and the Model Context Protocol. The platform you use becomes irrelevant — whether it is Slack, Notion, Jira, Asana, or Sentry — because the agent brain running underneath is Claude on CMA.

    This is the agent-as-a-service model. And it may be the most defensible position of the three, because it does not require users to change their behavior or migrate to a new platform. The agent shows up where they already work.

    What the Numbers Say About Enterprise Agent Adoption

    The macro context supports Anthropic’s timing. Gartner predicts that 40% of enterprise applications will include embedded task-specific agents by the end of 2026, up from less than 5% in 2025. McKinsey’s April 2026 analysis found that agentic AI can enable automation of 60 to 80 percent of routine infrastructure work over time, translating to a 20 to 40 percent run-rate cost reduction in initial deployments.

    The gap between experimentation and production remains the defining challenge. Industry research compiled from major firms shows that nearly four in five enterprises have experimented with or deployed agents in some form, but fewer than one in nine are running them in production at a scale that generates measurable business value. For the agents that do reach production, the average return on investment is 171% — though 19% of deployments never reach payback at all.

    That production gap is exactly what CMA is designed to close. The infrastructure burden — sandboxing, session persistence, credential isolation, error recovery, observability — is the bottleneck. Engineering teams routinely dedicated significant senior engineering resources for months before a single agent reached production. CMA eliminates that layer entirely, which is why partners like Asana, Sentry, and Rakuten report shipping production agents in days or weeks rather than quarters.

    What This Means for Businesses Already Using These Tools

    If your organization uses Slack, Notion, Jira, or Asana — and statistically, you use at least two of them — you are about to encounter Claude whether you planned to adopt it or not. This is not a technology decision your IT team is making. It is a feature that your existing vendors are shipping.

    The practical implications are significant. Claude Tag in Slack means your team channels will have an AI participant that remembers past conversations, can be handed tasks asynchronously, and may proactively surface information. Claude in Notion means your project documentation, databases, and task boards can be read, analyzed, and acted upon by an agent that chains actions together. Claude Agent for Jira means development tickets can be assigned to an AI that clones your repo, writes code, and opens pull requests.

    For agencies and service providers managing client work across multiple tools, the embedded agent layer changes the economics fundamentally. Work that previously required a human to context-switch between Slack, Notion, and a project management tool — reading a brief here, updating a task there, drafting a document somewhere else — can be handled by an agent that operates across all of them simultaneously. The coordination tax that consumes a substantial share of knowledge work time is the exact problem embedded agents are built to solve.

    The companies that benefit most will be the ones that have clean operational systems — structured task boards, documented processes, well-organized project databases — because agents can only act on information they can read. Messy Notion workspaces and disorganized Jira boards will limit what agents can accomplish. Operational hygiene just became a competitive advantage.

    What This Means for Solo Operators Already Running Agent Infrastructure

    There is a specific audience that should be paying very close attention to CMA: the solo operators and small agency owners who have already built their own agent stacks from scratch. If you are running scheduled Claude tasks on a GCP Compute Engine VM, connecting to WordPress via REST API proxies, piping work orders through Notion, monitoring Gmail for client replies, and publishing content through MCP-connected pipelines — you have already built a version of what CMA is productizing.

    The economics question is worth doing the math on. A lightweight GCP VM running 24/7 to host recurring agent tasks — news desk monitors, outreach reply checks, newsletter extraction, scheduled content audits — costs a fixed monthly rate whether the agents are actively working or sitting idle. CMA at $0.08 per session-hour of active runtime only charges when agents are executing. For tasks that run for a few minutes every few hours, the per-session billing model could be substantially cheaper than keeping a VM warm around the clock. A task that runs for ten minutes six times a day would cost roughly $0.08 per day on CMA, versus the cost of a VM instance that never sleeps.

    But the migration path is not ready yet, and solo operators should understand exactly where the gaps are before making any infrastructure decisions.

    The biggest gap is MCP tunnels. CMA’s ability to connect agents to private MCP servers inside your network is still in research preview — not production-ready. If your agent stack depends on a private WordPress REST API proxy, a Notion workspace connected via MCP, or any internal tool that is not exposed to the public internet, CMA cannot reach it today. The Vaults system for credential management is promising, but it does not solve the network connectivity problem for self-hosted infrastructure.

    The second gap is orchestration control. Solo operators who have built their own agent infrastructure typically have precise control over scheduling, retry logic, error handling, and the exact sequence of tool calls. CMA’s Dreaming feature — which reviews past sessions to curate agent memory — is an interesting approach to agent learning, but it is not the same as having direct control over a cron job that fires at 6:00 AM, checks three data sources in a specific order, and writes results to a specific Notion database with a specific schema.

    The thesis for solo operators is straightforward: CMA is almost certainly the future migration path for self-hosted agent infrastructure. The economics favor it for intermittent workloads, the managed security and sandboxing eliminate operational risk you are currently carrying yourself, and the session persistence model solves problems that custom agent runtimes handle poorly. But the plumbing — particularly MCP tunnels to private infrastructure — is not production-ready. Track it closely. Do not migrate yet. When MCP tunnels graduate from research preview to general availability, revisit the math and the connectivity story. That is the trigger point.

    The Risk Nobody Is Talking About

    There is a tension in this model that deserves attention. When Claude operates as an invisible layer inside tools you already trust, the boundary between the tool’s native capabilities and the AI agent’s actions blurs. A Jira ticket that was “completed” might have been implemented by Claude, reviewed by a human for thirty seconds, and merged. A Notion project plan that looks thorough might have been generated by an agent that filled in the sections with plausible-sounding content.

    The embedded model works precisely because it reduces friction — but reduced friction also means reduced scrutiny. Organizations adopting embedded agents need to build review processes that match the speed at which agents can produce output. The 171% average ROI from agent deployments accounts for the value created, but it does not account for the subtle quality risks of production work generated by systems that are confident, fluent, and occasionally wrong.

    Anthropic has built guardrails into CMA — sandboxed execution, credential isolation, session logging — but the governance layer for reviewing agent output at enterprise scale is still largely unsolved. This is a space where internal operational discipline matters more than the technology itself.

    Where This Goes Next

    Claude Tag launched on Slack first. Anthropic has indicated plans for wider rollout beyond Slack. If the pattern holds, expect Claude Tag’s persistent team member model to appear in Microsoft Teams, Discord, and any other collaboration surface where teams coordinate work.

    The CMA primitives are designed to be composable, which means the partner integration list will grow rapidly. Any SaaS company with an API and a workflow that involves reading context, making decisions, and taking actions is a candidate for CMA integration. Customer support platforms, CRM systems, design tools, analytics dashboards, HR systems — the addressable surface is essentially every tool that knowledge workers touch.

    Gartner’s long-term projection estimates that agentic AI could drive approximately 30% of enterprise application software revenue by 2035, surpassing $450 billion. If Anthropic’s embedded strategy succeeds, a meaningful slice of that revenue flows through CMA as the underlying runtime — regardless of whose logo is on the interface.

    The chatbot era is ending. The embedded agent era is starting. And Anthropic is betting that the company that owns the invisible execution layer wins the market, even if no end user ever sees its name.

    Frequently Asked Questions

    What are Claude Managed Agents (CMA)?

    Claude Managed Agents is a set of composable APIs launched by Anthropic on April 8, 2026 in public beta. CMA lets developers build and deploy production AI agents on Anthropic’s cloud infrastructure, handling sandboxed code execution, session persistence, credential management, and end-to-end tracing. The architecture separates the “brain” (Claude reasoning) from the “hands” (code execution sandbox), enabling parallel processing and faster agent responses.

    How much do Claude Managed Agents cost?

    During the current public beta, CMA pricing is standard Claude API token rates plus $0.08 per session-hour of active runtime. Runtime is measured to the millisecond and only accrues while the agent is actively executing — idle time does not count. GA pricing has not been finalized and may differ from the beta rate.

    What is Claude Tag in Slack?

    Claude Tag is Anthropic’s persistent AI team member for Slack, launched June 23, 2026. Unlike a traditional chatbot, Claude Tag lives in channels, builds memory across conversations, takes initiative through ambient mode, and works asynchronously. It is multiplayer — one Claude identity per channel that all team members interact with. Claude Tag runs on Claude Opus 4.8 and is available on Enterprise and Team plans. It replaces the original Claude in Slack app, which retires August 3, 2026.

    Which tools have Claude Managed Agents embedded?

    As of June 2026, CMA is embedded in Slack (via Claude Tag), Notion (via the External Agents API), Asana (AI Teammates), Atlassian Jira (Claude Agent for Jira), and Sentry (extending the Seer debugging agent). Enterprise deployments include Rakuten (specialist agents across product, sales, marketing, and finance) and KPMG (Digital Gateway Powered by Claude for tax and private equity clients).

    How does Anthropic’s agent strategy differ from OpenAI and Google?

    Anthropic uses a tool-centric orchestration approach, embedding its agent runtime inside existing tools via composable APIs and the Model Context Protocol (MCP). OpenAI chose vertical integration with Workspace Agents, positioning ChatGPT as the central hub. Google chose platform depth with the Gemini Enterprise Agent Platform and Workspace Intelligence semantic layer. Anthropic’s approach does not require users to change platforms — the agent shows up where they already work.

    What percentage of enterprise apps will have embedded AI agents by end of 2026?

    Gartner predicts that 40% of enterprise applications will include embedded task-specific agents by the end of 2026, up from less than 5% in 2025. However, fewer than one in nine enterprises currently run agents in production at scale, suggesting significant growth ahead.

    Can Claude Managed Agents run inside a private network?

    Yes. CMA supports self-hosted sandboxes through partners including Cloudflare, Daytona, Modal, and Vercel, or custom VPC deployments. MCP tunnels allow agents to connect to private Model Context Protocol servers inside your network without public exposure. A Vaults system keeps credentials out of the sandbox using envelope encryption.



  • What Can You Actually Do With Claude? The Complete Use-Case Guide (2026)

    What Can You Actually Do With Claude? The Complete Use-Case Guide (2026)

    Claude is far more than a chatbot. Anthropic calls Claude Code and Cowork “general agents — broad-domain systems that handle research, operations, analysis, and code with equal fluency.” In practice, that means the same AI that writes software can also run your marketing, draft grant proposals, analyze a spreadsheet, and automate the busywork that fills your week. This guide maps what people actually use Claude for, organized by the job you’re trying to get done — with a deeper walkthrough behind each one.

    Content & marketing

    The most popular non-technical use. Claude researches, drafts, edits, and optimizes — from a single blog post to an entire editorial pipeline.

    Business operations

    Proposals, reports, client onboarding, weekly reviews — the recurring documents that quietly consume a team’s week.

    Software development

    Where Claude started. Claude Code is an agentic coding tool that reads your codebase, writes and refactors, runs tests, and ships — from the terminal, an IDE, or a desktop app.

    Knowledge work — without writing code

    You don’t need to be a developer to put an agent to work. Cowork brings the same engine to files, docs, and operations through a friendlier surface.

    By industry

    The work looks different in every sector. These walkthroughs show Claude inside a specific team’s day:

    Inside the tools you already use

    Claude doesn’t have to live in a separate window.

    Teams & enterprise

    Which Claude is right for you?

    Chatbot, coding agent, knowledge-work agent, Slack teammate — these are different doors into the same models. Match the surface to your job first, then size the plan.

    Frequently asked questions

    What can you use Claude for besides chatting?

    Content creation, software development, business operations, data analysis, and knowledge work. Anthropic positions Claude Code and Cowork as general-purpose agents, not just a chat assistant.

    Do you need to know how to code to use Claude?

    No. Claude’s chat, Cowork, and Slack surfaces require no coding, and even Claude Code can be driven by non-developers for writing, research, and file work.

    What’s the difference between Claude, Claude Code, and Cowork?

    Same underlying models, different surfaces: Claude (chat) for conversation, Claude Code for agentic coding, and Cowork for agentic knowledge work. See the full comparison.

    Is there a version of Claude for my industry?

    Yes — see the industry walkthroughs above (marketing, real estate, agencies, restoration, local news, B2B SaaS, and nonprofits) for sector-specific workflows.

    New to Claude? Start with pricing & plans, then pick the surface that fits the job you have in mind.

  • Claude for Nonprofits: Discounts, Eligibility & Use Cases (2026)

    Claude for Nonprofits: Discounts, Eligibility & Use Cases (2026)

    Claude for Nonprofits is Anthropic’s program that gives qualifying nonprofits up to 75% off Claude’s Team and Enterprise plans — with Team seats starting around $8 per user per month — plus nonprofit-specific data connectors, free AI training, and access to a $150M fellowship. If your organization holds 501(c)(3) status (or an international equivalent), you almost certainly qualify. Here’s what’s included, who’s eligible, and how mission-driven teams are putting it to work.

    What is Claude for Nonprofits?

    Launched by Anthropic in 2026, Claude for Nonprofits packages the same Claude models used by enterprise teams into an offering built for the realities of mission-driven work: tight budgets, lean staff, and a constant need to do more with less. It bundles three things nonprofits rarely get together — steep pricing discounts, sector-specific integrations, and free training — into one program. It runs on the same foundation as Anthropic’s commercial plans, so nonprofits get the latest Claude models (Opus, Sonnet, and Haiku), not a stripped-down version.

    Who qualifies?

    Eligibility is broad, and Anthropic validates organizations through its partner Goodstack. The program covers:

    • 501(c)(3) nonprofits in the U.S., and organizations with equivalent charitable designations internationally
    • K–12 schools, public and private
    • Mission-based healthcare organizations with 501(c)(3) status — including independent Critical Access Hospitals (CAHs), Rural Emergency Hospitals (REHs), HRSA-designated Federally Qualified Health Centers (FQHCs) and FQHC Look-Alikes, and CMS-certified Rural Health Clinics (RHCs)

    If you can document charitable status, eligibility is usually straightforward.

    How much does it cost?

    Qualifying organizations receive up to 75% off Claude’s Team and Enterprise plans:

    • Team plan — discounted pricing starts around $8 per user, per month, which makes it realistic to roll Claude out to an entire staff rather than a single power user.
    • Enterprise plan — custom pricing for larger organizations; you contact Anthropic’s sales team.

    Both tiers include Claude’s current model lineup. Pricing and model availability change, so confirm the latest figures on Anthropic’s official Claude for Nonprofits announcement. Curious how discounted seats compare to standard rates? Run the numbers on our Claude pricing calculator.

    What nonprofits actually use Claude for

    The highest-leverage uses cluster around the work that eats the most staff time:

    • Grant writing — drafting proposals aligned to a specific funder’s priorities, then tailoring them per application.
    • Donor stewardship — personalizing outreach and acknowledgements at a scale a small development team could never manage by hand.
    • Program evaluation & impact analysis — turning messy program data into the impact narratives boards and funders want.
    • Board & compliance documentation — generating board materials, reports, and compliance documents from source data.

    The common thread: Claude removes the blank-page tax on the writing- and analysis-heavy work that keeps nonprofit staff at their desks instead of in the field.

    Connectors built for the nonprofit stack

    Anthropic built integrations with the platforms nonprofits already run on, so Claude can work against real organizational data:

    • Benevity — access to 2.4M+ validated organizations for volunteering and donation research
    • Blackbaud — CRM and fundraising tools for donor management, campaign tracking, and donation optimization
    • Candid — data on nonprofits and funders to discover organizations, grants, and philanthropic opportunities

    Free training and the Claude Corps fellowship

    Two things set this apart from a plain discount:

    • AI Fluency for Nonprofits — a free course Anthropic developed with GivingTuesday, covering grant writing, program evaluation, donor engagement, and organizational efficiency. It’s aimed at staff, not engineers.
    • Claude Corps — a $150M fellowship initiative pairing nonprofits with AI expertise and resources to implement Claude across their operations. Anthropic also works with partners including The Bridgespan Group, Idealist Consulting, Vera Solutions, and Slalom to support adoption.

    How to get started

    1. Confirm your charitable status (501(c)(3) or international equivalent).
    2. Apply through Anthropic’s nonprofit page — eligibility is validated via Goodstack.
    3. Choose Team (self-serve, discounted seats) or contact sales for Enterprise.
    4. Enroll staff in the free AI Fluency for Nonprofits course to get value quickly.

    Start at Claude for Nonprofits, or read Anthropic’s getting-started guide.

    Frequently asked questions

    Is Claude free for nonprofits?

    Not free, but heavily discounted — up to 75% off Team and Enterprise plans, with Team seats starting around $8 per user per month for qualifying organizations.

    Who qualifies for Claude for Nonprofits?

    501(c)(3) nonprofits (and international equivalents), K–12 public and private schools, and mission-based healthcare organizations with 501(c)(3) status. Eligibility is validated by Goodstack.

    Which Claude models do nonprofits get?

    The discounted plans include Claude’s current lineup — Opus, Sonnet, and Haiku — the same models on the commercial plans, not a limited version.

    What can a nonprofit do with Claude?

    Common uses include grant writing, donor stewardship, program evaluation, and board and compliance documentation, plus integrations with Benevity, Blackbaud, and Candid.

    Is there training for nonprofit staff?

    Yes. Anthropic and GivingTuesday offer a free “AI Fluency for Nonprofits” course, and the $150M Claude Corps fellowship provides hands-on implementation support.

    Want to see how discounted seats stack up against standard plans? Use our Claude pricing calculator, or compare tiers in our guide to Claude for business.

  • I Let Claude Run on My Business. The Moment That Mattered Was When It Said No.

    I Let Claude Run on My Business. The Moment That Mattered Was When It Said No.

    For the past week or so I’ve been building a real operation with Claude — not a demo, not a clever prompt, an actual business a partner of mine is about to run.

    It built the storefront: a full ladder of products, from a $7 scorecard up to a complete operating system, each one wired to checkout and set to deliver itself the second someone buys. It built a redemption engine, so my partner can give out a code from a stage and the right person instantly gets the product while we capture the lead. It drafted a productized lead-generation offer — the pricing, a one-page pitch, even a scorecard to decide which contractors are a fit. When the server’s email quietly broke, it traced the real cause — a file permission, three layers down — and fixed it.

    That’s the part everyone wants to talk about: look what it can do. And it’s real. But it’s not what I’ll remember from this week.

    The moment that mattered

    I asked Claude to check whether a call-tracking number was set up correctly on the site. It looked, confirmed the number was live and routing to the right phone — and then, because it’s thorough, started to clean up a small labeling gap on that number.

    And then it stopped itself.

    A safety layer caught the action before it ran and refused it. The reason it gave was almost uncomfortably precise: you asked me to verify this, not to change it. This is a live system other people depend on. That’s your call, not mine.

    I’d only asked it to look. It had drifted toward changing a shared, live system — exactly the kind of small, well-meant overstep that’s easy to miss — and something stopped it and handed the decision back to me.

    I’d spent a week watching this thing demonstrate real capability. The moment it earned my trust was the moment it demonstrated restraint.

    Capability was never the scary part

    That’s backwards from how most people are sizing up AI right now. The whole conversation is capability — what can it do, how much, how fast. But if you’re actually putting this into your business, capability was never the scary part. The scary part is an eager, capable system taking a consequential, hard-to-undo action on something live because it technically could, and because you weren’t specific enough.

    What protected me wasn’t that the AI was timid by personality. It’s that the whole thing is built so the more consequential, irreversible, and shared an action is, the more a human has to be in the loop. Reading something? Go ahead. Changing a live system someone else relies on, when that wasn’t clearly asked for? Stop and ask. The gate tightens exactly as the stakes rise.

    And the part that actually sold me: when I asked how that worked, it explained its own guardrails plainly. It didn’t pretend it had no limits, and it didn’t pretend it could talk its way around them. It told me where the brakes are, who controls them (me), and what it genuinely can’t see about its own safety layer. An AI that’s honest about what it won’t do is a lot easier to trust with what it will.

    What I’d take from it

    If you’re bringing AI into your operation, here’s what I’d take from my week: don’t just ask what it can do. Ask what it does when it isn’t sure. Ask what happens at the edge — the live system, the irreversible change, the thing you didn’t quite specify. That answer matters more than the length of the feature list, because that’s the moment that either protects your business or burns it.

    The most capable AI in the room is impressive. The one that knows what it shouldn’t do without you is the one you can actually build on. I got to see both this week. Turns out they were the same one.