DEV Community: Cristian Tala

The US is pushing the world toward Chinese AI (its own goal)

Cristian Tala — Mon, 29 Jun 2026 20:30:56 +0000

In June 2026, the United States put a lock on its own AI models. It ordered Anthropic to block access to Mythos 5 and Fable 5 for anyone who isn't American, and days later it asked OpenAI to limit the rollout of GPT 5.6 to a handful of government-approved partners. Its best models, the newest ones, were placed out of reach for the rest of the world.

That adds to something older: years of restrictions that already left Nvidia almost out of China's chip market. Two brakes, one new and one accumulated, with the same effect. And the effect isn't the one Washington was after: demand, money and talent ran toward Chinese AI.

I live this firsthand. I'm a founder in Chile, I can't use the newest from Anthropic or OpenAI, and my stack leans more and more on Chinese models like GLM and DeepSeek. This isn't ideology. It's what's left when they close the door on you.

What exactly did the United States block?

Two different brakes that ended up coinciding.

The first, the models, and it's from this month. In mid-June 2026, the US government ordered Anthropic to block access by non-Americans to Mythos 5 and Fable 5, its most powerful models. The official reason was national security, after suspicion that a China-linked group had accessed one of them. Anthropic suspended them worldwide to comply, and the Commerce Department lifted the restriction only for a short list of American companies.

Days later it was OpenAI's turn. The administration asked it to limit the rollout of GPT 5.6 to a small number of partners approved by the government itself, over its cybersecurity capabilities, which it considers equivalent to Mythos's. Sam Altman called it a "strange moment," with no clear rules, and accepted the condition to be able to launch the model. So it wasn't an isolated case: the two US leaders, Anthropic and OpenAI, ended up with their best technology under government control. When the owners of the frontier have to ask permission to hand out what they build, the rest of the world looks elsewhere.

The second brake, the hardware, isn't from June: it's a policy that's been tightening for years. The US has restricted the sale of Nvidia's AI chips to China since 2022, turn after turn. The state of things in 2026 is the most extreme, with an ironic twist: early in the year the government loosened up to let the H200 in, but by then China had already told its own companies not to buy the H20 or the H200, on security grounds. Nvidia ended up practically out of that market, squeezed from both shores. An analysis by Brookings puts it bluntly: the game's over, the US is out of the AI chip market in China.

The world runs to Chinese AI

When you take the best Western model away from the world, the world doesn't sit and wait. It moves to the next one. And the next one, today, is Chinese and open.

The clearest signal: shares of Z.ai, the company behind GLM, jumped more than 30% after it released its new open source model. Global demand shifted toward the Chinese alternatives, cheaper and with no access restrictions. It's no accident that right now half the internet talks about GLM 5.2 as if it were free: the block opened the door for it.

And it's not just that they're available. They're much cheaper. DeepSeek had already shown you can build a top-tier model for a fraction of what American labs spend, and that gap carries over to the price per use. For a founder counting every dollar, an open, accessible and cheap model stopped being plan B. It's the plan A that Washington made obvious.

I'm part of that statistic. As a founder outside the United States, I'm not on the list that can use the newest from Anthropic. So I test, I measure, and I use what I do have available, and a lot of it comes from China. In my AI model benchmark, DeepSeek and the Chinese models fight for the top spots. I don't pick them by flag. By access and by result.

And China stopped needing Nvidia

Here's the part that should worry Washington more than any other.

Blocking the chip didn't stop China. It pushed it to make its own. Analysts estimate that the export cap alone could increase China's domestic compute capacity by 250%. Huawei plans to ship 600,000 of its Ascend 910C chips in 2026, no matter what the US decides.

And it's no longer theory. Huawei leads the AI chip market inside China, where it beat Nvidia, and it's projected to control 60% of that market by the end of 2026, with revenue over 12 billion dollars. Its Ascend 950 series is comparable to the H200, one of Nvidia's most powerful chips. And DeepSeek's V4 model has already been adapted to run on Huawei's chips: a full stack, a Chinese model on Chinese hardware, with no stop in the United States.

The honest caveat: the individual chip is still behind. The Ascend 910C performs at around 60% of an H100, and China still depends on manufacturing equipment it doesn't fully produce at home. But the direction is clear, and so is the speed. When someone with resources has no other choice, they build. And they improve fast.

Why this is an own goal

The logic of the block is intuitive: take the best technology from your rival and you leave them behind. It works when the rival can't build the substitute. China can.

Every restriction did the opposite of what it promised. The model block sent the world to try the Chinese ones. The chip block handed Huawei a captive market of hundreds of thousands of units and a national reason to accelerate. The United States didn't stop China. It funded its independence.

It's an old lesson, and it's not geopolitics, it's business: when you close the door on someone with resources and pride, you don't stop them. You force them to build their own house. And sometimes they build it better than yours.

What this means for you, founder

Let's bring this down to earth, because what matters to you is what you build with.

First: your stack can't depend on a single provider. If you depend on one model and tomorrow a political decision cuts your access, you're left without operations. Mine is split across several models on purpose, and that stopped being a technical preference to become insurance.

Second: Chinese AI is part of the map, like it or not. GLM and DeepSeek are among the most capable and cheapest models out there today. Ignoring them by flag is competing with one hand tied.

Third, and that's why it's not blind faith: Chinese models come with their own fine print. It matters where your data is processed, what's stored and what's censored. I use them with judgment, for the right tasks, not for everything. Just like with any provider, the question isn't what country it's from, but what it does with what you give it.

The day the best model and the best chip come from the same place

The United States wanted to buy time and ended up giving away ground. For the founder on the outside, the takeaway is simple and a little uncomfortable: the future of your stack is no longer decided by Silicon Valley alone.

Test the Chinese models with the same coldness you'd test any other: by capability, by cost, by where your data goes. And don't take your eyes off the hardware. Today the Chinese chip is behind; in a year or two, that sentence may stop being true. The day the best model and the best chip come from the same place, and that place isn't the United States, the block will have achieved exactly the opposite of what it set out to do.

I write about AI and test models at cristiantala.com. Every month I publish a benchmark of 89 models.

GLM 5.2 isn't free: not even my US$4,000 Spark can run it

Cristian Tala — Mon, 29 Jun 2026 20:30:55 +0000

GLM 5.2 is open source and free to download. Running it is another story. At best it needs around 240 GB of memory, and that's only in its most compressed version. I have a US$4,000 DGX Spark dedicated to this, with 128 GB, and it doesn't have enough to even start. This isn't opinion, it's arithmetic. What bothers me isn't the model. It's the smoke from people shouting "free" who never opened a terminal.

Why does everyone say GLM 5.2 is free?

Because they mix up two different things. One is the license. GLM 5.2 shipped under the MIT license on June 13, 2026: anyone can download the weights, no payment, no permission. That's real and it's great.

The other is the cost of using it. Downloading the model costs nothing. Making it run at a usable speed costs money, and a lot of it. Both facts coexist, but the posts you see only tell you the first one. "Open weights under MIT" doesn't pull as many likes as "it's free and it beats the paid model."

What's the best free AI? The question is wrong

It's the search everyone makes, so I'll answer it straight: the best open source AI today (GLM 5.2, DeepSeek, the big Qwens) isn't free to run for almost anyone. The word "free" assumes you already have somewhere to run it. That's the trap.

The open source models that compete with the paid ones are huge. They don't run on your laptop. They run on a tiny fraction of the computers that exist in the world. The small model that does fit on your machine isn't the one you saw winning the rankings.

What it really costs to run GLM 5.2

GLM 5.2 is a mixture-of-experts model with around 750 billion parameters. What it costs to run depends on two things: how much you compress it (and how much quality you give up) and how fast you want it. Here's the real map:

Version	Memory	Typical hardware	Approx. cost	Speed
FP16 (full, no quality loss)	~1,642 GB	2-3 DGX servers (16-24 GPUs)	US$500,000 to 1M+	like a provider
4-bit (decent, near-full quality)	~411 GB	several datacenter GPUs	~US$150,000	good
2-bit (minimum usable, degraded quality)	~240 GB	Mac Studio 256 GB or 4× RTX 4090 rig	~US$10,000	3-6 tokens/s
Doesn't fit	128 GB	DGX Spark	US$4,000	won't run

Read it from the bottom up. My US$4,000 Spark, bought precisely for this, doesn't even reach the minimum: GLM 5.2 needs 240 GB and it has 128. It doesn't even fit.

The first rung where the model runs is a US$10,000 Mac, compressed to 2-bit (quality drops) and at 3 to 6 tokens per second. At that speed you type faster than the model. To have it decent and fast you're already in six figures. And to run it the way a provider hands it to you (OpenRouter, Nvidia NIM and friends), at full precision, you're at two or three DGX servers and up to a million dollars.

And that's just buying the gear. It doesn't include the electricity bill of keeping it on, or that in a few months a bigger model ships and your investment falls short, or your hours maintaining all of it. The provider spreads that datacenter cost across thousands of users and charges you fractions of a dollar per million tokens. You'd pay it whole, just for you, with the machine off most of the day.

DeepSeek, Qwen, GLM: "free" is marketing

The pattern repeats with every launch. An open source model that fights the paid ones drops, and the next day half the internet announces that top-tier AI is now free. DeepSeek went through this. The big Qwens too.

The part that doesn't make it into the video: to run those models at a usable speed, you need a hardware investment that pays for several years of an API subscription on its own. The open license doesn't save you that cost. It just changes who pays it. Instead of the model provider, you pay it, in gear.

The pattern shows up in dozens of posts from creators talking about models they never ran. The formula is always the same: an epic image, a vault swinging open and the model flowing out toward a desktop computer, and a headline like "the best coding model is no longer rented, it's open source." Sounds incredible. It has two problems. First: that desktop computer with one graphics card doesn't run GLM 5.2, not even close. The image draws something that can't be done. Second: "no longer rented" is exactly backwards. You keep renting it through an API, because you have nowhere to run it. The vault opened, yes, but inside there's something that only fits in a US$12,000 machine. Open isn't the same as accessible. For most people, that "freed" model stays as far away as the paid closed one.

So what do I run locally? And for what

I'm not talking about this from the outside. I use open source models every day, in my operation and my work. On the Spark I run Gemma 4 and Qwen 3.6, smaller models that do fit. They work well. But because of memory bandwidth, the tokens per second aren't enough to use them in a live conversation.

So I give them the work where speed doesn't matter: my agents, processes I leave running overnight, and my own AI model benchmark. For that they're perfect and I pay no API.

And when I need an open source model with real speed (almost all my n8n automations), I run it through an API on Ollama Cloud. Open source, yes. Free, no. That's the point that gets lost: open source doesn't mean you don't pay. It means you choose where you pay, between your own hardware or an API. Same when I use Claude Code connected to open source models: the model is open, someone provides the compute and someone pays for it.

When does running a model locally actually make sense?

When the reason is your data, not your wallet. If you handle sensitive information and you don't want it leaving your machine, running the model at home makes all the sense in the world. Privacy and control are the honest argument for self-hosting. Savings aren't. When someone sells you local because it's cheap, be suspicious. When they sell it to you for privacy, listen. That's the filter.

The final proof is in the OpenRouter ranking

If running GLM 5.2 free at home were practical, nobody would pay to use it. Look at the OpenRouter usage ranking: GLM 5.2 is among the most-used models on the platform at the end of June 2026. And OpenRouter is a paid service, where you call the model through an API and they charge you per token.

In other words: even the people who love GLM 5.2 use it paying. Because that's what makes sense. The model is excellent. "Free" is the made-up part.

Before you share the next "it's free"

Let me be clear: I'm glad open source is this good. That's why I have the Spark, that's why I test every model that ships, that's why my stack is split across several models depending on the task. This isn't against open source. It's against the smoke.

Next time you see "this model is free and it beats the paid one," ask yourself two questions before hitting share: how much does the computer that runs it at a usable speed cost?, and do I need it answering live or does it work for me running overnight? With those two answers you decide for real, with your case and your budget. Not with the excitement of someone who never opened a terminal.

I write about AI and test models at cristiantala.com. Every month I publish a benchmark of 89 models.

How I Export 700+ Skool Members to CSV with One API Call (Email, Tier, LTV, Survey)

Cristian Tala — Fri, 29 May 2026 14:45:24 +0000

If you run a community on Skool, you've probably noticed something annoying about the member list: the email field is blank for most members. Not your bug. Skool's server-rendered member list returns email: "" for everyone except the authenticated user. Even community owners get masked emails for third parties when calling GET /users/{id}.

The admin panel has an "Export" button that does give you everything — emails, tiers, LTV, survey answers — but only if you click it manually. For a CRM sync pipeline, that's not enough.

This post shows how to call that same export programmatically via the Skool All-in-One API actor on Apify. One HTTP request, full member roster as JSON, ready to pipe into NocoDB / Airtable / Postgres / anywhere.

It's the foundation of the CRM single-source-of-truth pipeline I run for Cágala, Aprende, Repite (700+ members).

What you'll need

An Apify account (free tier covers this — the export costs ~$0.05/run)
Skool admin/owner cookies for your community
A community where you're admin (export is admin-only)

If you've never used the actor before: it wraps Skool's entire REST surface so you don't have to handle cookies, WAF token rotation, weekly buildId changes, or the 3-step async pattern Skool's export uses internally. One JSON POST → parsed response.

The one-liner that returns your full roster

curl -X POST \
  "https://api.apify.com/v2/acts/cristiantala~skool-all-in-one-api/run-sync-get-dataset-items?token=$APIFY_TOKEN&timeout=60&build=latest" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "members:export",
    "cookies": "auth_token=...; client_id=...; aws-waf-token=...",
    "groupSlug": "your-community",
    "params": { "status": "active" }
  }'

Response (one item per member, already parsed — no CSV parsing on your side):

[
  {
    "firstName": "Maria",
    "lastName": "Lopez",
    "email": "maria@example.com",
    "invitedBy": "Cristian Tala",
    "joinedDate": "2026-04-12 18:14:56",
    "survey": [
      { "question": "What's your LinkedIn?", "answer": "linkedin.com/in/marialopez" },
      { "question": "What are you building?", "answer": "SaaS for restaurants" },
      { "question": "How did you find us?", "answer": "Newsletter" }
    ],
    "tier": "standard",
    "ltv": "$0"
  }
]

The actor handles the underlying 3-step flow Skool's admin UI runs when you click Export:

POST /groups/{id}/request-bulk-action?type=bulk-export-csv → returns {token, file_id}
GET /wait?token={token} → polls until completed (2-8 sec typically)
POST /files/{file_id}/download-url → signed CloudFront URL → GET that → CSV body → parse to JSON

You don't see any of that. One call in, parsed JSON out.

Filter what you export

{
  "params": {
    "status": "active",
    "tiers": ["premium", "vip"]
  }
}

Param	Values	Default
`status`	`active` / `cancelling` / `churned` / `banned`	`active`
`tiers`	array of your community's tier slugs	all tiers

Useful for cohort analysis: "all premium members who joined in the last 30 days" → filter status: active, tiers: ["premium"], then client-side filter by joinedDate.

The data quality reality nobody mentions

Measured against a real production community of 700+ members:

~68% of members have a populated email field. The other ~32% (typically members who joined via the Skool Discovery network — the platform's "browse communities" feature) don't share their email with the community owner. Skool keeps that field empty in the export. This is structural, not a bug.
~88% have a LinkedIn URL in their first survey answer (when the apply form asks for it). Apply-form answers are far more complete than the email field.
invitedBy is empty unless the member came through a tracked Skool referral link.

For the ~32% with no email, fall back to the LinkedIn URL from the survey. That's typically enough to identify the member for outreach.

What the export does NOT include

One important gap: the acquisition source (Joined from LinkedIn / Joined from your blog / Joined from Skool network) is NOT in the export. It lives in member.metadata.attrSrcComp on the SSR member object — accessed via a separate call:

{ "action": "members:list", "cookies": "...", "groupSlug": "...", "params": { "all": true } }

members:list returns joinedFrom / joinedVia per member — the missing piece for attribution analytics. Merge both responses by memberId if you need the full picture.

Pipe straight to your CRM

Two production patterns I use:

A. Nightly snapshot → NocoDB. Cron runs the export, diffs against yesterday's, upserts into a personas table keyed by email. New rows get joined_at, missing rows get churned_at. This is the single-source-of-truth for the CRM.

B. On-demand cohort pull. Export tier: ["premium"], filter rows where joinedDate >= 30 days ago, send each to a personalized email sequence in Postmark. The survey array gives the personalization data: their LinkedIn, what they're building, where they heard about you.

# JSON snapshot
curl ... > members-$(date +%F).json

# Or convert to CSV with jq
curl ... | jq -r '
  (.[0] | [.firstName, .lastName, .email, .joinedDate, .tier, .ltv] | @csv),
  (.[]  | [.firstName, .lastName, .email, .joinedDate, .tier, .ltv] | @csv)
' > members-$(date +%F).csv

Gotchas I hit so you don't have to

build.stale error = expired cookies, not a bug. Skool's aws-waf-token rotates every ~3.5 days. Re-run auth:login with email+password to get fresh cookies. The actor returns a clear errorCode: BUILDID_STALE with the exact JSON payload you need to re-auth.
Don't poll the export every 5 minutes. Designed for daily/weekly snapshots. The CSV is generated on-demand by Skool — calling it on every webhook is wasteful and you'll eventually hit rate limits.
Large communities (10K+ members) can take 30+ seconds to generate. Set your HTTP client timeout to at least 90 sec.
invitedBy is empty unless the member came through a tracked referral. All blanks doesn't mean broken — just means no member came through your ref link.

Why this actor exists

I run my own Skool community alone — no team, no virtual assistants. Approving members, replying to posts, publishing courses, exporting member data for follow-up. Everything in this actor (and the 20 production recipes in the docs) exists because I needed it to keep up with the daily work as a solo admin.

If you're running a Skool community without a team and the manual admin clicks are eating your day, the actor is built for you.

→ Use the Skool All-in-One API actor on Apify — pay-per-event (~$1.50/mo typical).

→ Full recipe with all the edge cases

New to Skool? Launch your community here — 14-day free trial.

How I Uploaded an 18-Course Classroom to Skool With One Script (and the Bug That Almost Killed My Paywall)

Cristian Tala — Sun, 17 May 2026 14:43:10 +0000

How I Uploaded an 18-Course Classroom to Skool With One Script (and the Bug That Almost Killed My Paywall)

When I sat down to build the curriculum for my Skool community, I had two options.

Option A: open the Skool UI, click New Course, type the title, drag in a cover image, click Add section, type the section title, click Add lesson, type the lesson title, paste the body, fix the formatting Skool's editor mangled, save, repeat. For 18 courses with an average of 12 lessons each.

That's ~220 manual operations, each in a UI that adds modal friction at every step. Realistic time: a full week of clicking.

Option B: structure the curriculum as markdown files in a local directory. Write a script that walks the directory and calls Skool's API to create the courses, folders, lessons, and bodies. Run the script. Drink coffee. Done in two hours.

I went with Option B. I'd already built the Skool API actor on Apify for other automations (member approvals, podcast publishing, comment replies), and the classroom endpoints were already there. The actor wraps Skool's reverse-engineered API with read-then-write semantics, markdown-to-Skool's-internal-format conversion, and structured error handling.

What I didn't expect was the bug that nearly stripped the paywall off all 12 of my paid courses. We'll get there.

What the directory looked like

The whole curriculum lived in one folder structure on my laptop. Each course was a subdirectory; each module was a subdirectory inside that; each lesson was a markdown file. Cover images and the script to regenerate them lived next to each course.

cursos-car/
├── intro-llms-mastermap/
│   ├── M01-el-llm-no-es-oraculo/
│   │   ├── L1.1-el-llm-no-es-oraculo-ni-google.md
│   │   ├── L1.2-tokens-y-ventanas-de-contexto.md
│   │   └── L1.3-el-coste-real-de-tokens-a-dolares.md
│   ├── M02-mapa-de-modelos-2026/
│   ├── M03-framework-de-decision/
│   ├── M04-matchmaking/
│   ├── M05-tu-primer-experimento/
│   └── assets/
│       ├── cover.html         # Tailwind synthwave template
│       ├── cover.jpg          # Playwright-rendered output
│       └── render-cover.mjs   # script to regenerate the JPG
│
├── idea-validation/
│   └── [same structure, 15 lessons across 5 modules]
│
├── podcasts-car/
│   └── [12 lessons in one folder, no modules — flat archive]
│
└── [15 more courses]

Each L*.md file is a self-contained lesson. First line is # Title. Body is normal markdown with the occasional callout block.

The build pipeline reads this directory, creates one course on Skool per top-level folder, one Skool section (folder) per M*-* subdirectory, and one Skool lesson per L*.md file. The body of the lesson is the markdown content converted to Skool's internal TipTap JSON format.

The whole pipeline is straightforward to describe. It hides four traps. Let me walk you through them.

Trap 1: Skool prefixes folders with "Section N:" — don't do it manually

My first pass at the directory naming put the module number in the folder name itself: M01-intro, M02-mapa-modelos, etc. The script passed those titles straight through to classroom:createFolder on Skool.

Result in the UI: every folder displayed as "Section 1: M01 — Intro", "Section 2: M02 — Mapa de Modelos", etc. Double-numbered. Awful.

Skool prefixes every section in a course with "Section N:" automatically based on its position. If you also number manually in the title, you get the duplication.

Fix: drop the M01-, M02- prefix from the folder titles you pass to the API. Keep the prefix in your local directory names if you want them ordered on disk — just don't pass them to Skool.

Now my titles are just 🧱 El LLM no es un Oráculo, 🗺️ Mapa de Modelos 2026, etc. Skool renders them as Section 1: 🧱 El LLM no es un Oráculo, which is what I wanted.

Trap 2: `classroom:updateCourse` silently resets `privacy` to 0

This is the one that almost cost me real money.

A few weeks into running the pipeline, I needed to update the description on a few courses. Trivial — classroom:updateCourse with the new desc field. Worked fine.

Until I checked the courses in the Skool UI and noticed the lock icons had disappeared. Twelve paid courses were now showing as Open (free) to all members. The Premium tier I'd set was wiped. amount: 147 was now amount: 0.

What happened: Skool's PUT /courses/{courseId} endpoint is a replace, not a merge. If you omit a field in the body, Skool doesn't preserve it from the existing record — it resets it to the default. privacy defaults to 0 (Open). amount defaults to 0. minTier happens to be preserved (because it's an integer with no default that fits "I omitted this"), but privacy and amount are not.

The actor now does updateCourse as read-then-write internally. It fetches the current course state, merges your input on top, sends the full body. Cost: +1 GET (~200ms per update). Worth every millisecond.

But the day I figured this out, I had to fix twelve courses by hand in the UI before any paying member noticed they had free access to everything.

If you build any automation against Skool's classroom endpoints, never send a partial PUT. Always read the current state first, merge, and write the full body. The actor handles this for updateCourse. If you call the Skool API directly: read-then-write everywhere, no exceptions.

Trap 3: Markdown converter quirks

The actor accepts markdown for lesson bodies and converts it to Skool's internal [v2]<JSON_array> TipTap format. The conversion is mostly faithful, but a few things bit me when my source markdown wasn't strict.

Brackets without URLs become plain text. A line like [Read more] - in this guide is not valid markdown link syntax (no parentheses with URL). Most renderers tolerate it. Skool's converter respects the spec — it stays as literal text with brackets visible. Audit your "For more reading" sections before publish. This bit me three times in lessons generated by an AI agent that wasn't strict about link syntax.

### [Sección 1] Title is literal text, not auto-numbered. Two of my lessons had ### [Sección 1] The economy... and ### [Sección 2] When to use them... literally in the markdown. False alarm: I thought the converter was adding the "Sección 1" prefix. It wasn't — the source content had it. Skool renders it verbatim. Strip those patterns from your source before converting.

Headings inside blockquotes get flattened. Skool only renders the blockquote's left border on paragraph children. A real bulletList inside a blockquote visually escapes the callout. The converter handles this by flattening nested lists inside blockquotes to paragraphs with • prefixes. Cosmetic, but a fact to know if your markdown style relies on nested structure inside callouts.

Tables with many columns degrade. Tables that fit (≤5 cols × ≤10 rows × ≤30 chars/cell) render as monospace code blocks (preserves alignment). Larger tables degrade to bulleted lists with bold-key prefixes. Acceptable, but plan your tables accordingly.

Trap 4: Re-running creates a NEW course (course-create is not idempotent)

The script that creates a course top-to-bottom is not idempotent. Re-running it creates an entirely new course with the same name, not an update.

Skool has no "upsert course by name." There's no unique constraint on course title within a community. If your script fails halfway and you re-run it, you now have two half-built courses with the same name.

How I handle this:

For initial course creation: dry-run against a test Skool community first. I use nyx-trial-run-8420 for this. Only push to production (CAR) once the test passes.
For incremental updates (add a lesson, fix a typo): use a different code path that takes the existing courseId and pageId as inputs. No course creation involved. The IDs are checked into the script as constants — yes, hardcoded, on purpose.
For full re-publishes (rare): delete the old course manually in the UI first, then re-run the script.

The pattern I land on for any Skool automation now: the create-course path and the update-course path are different scripts, with different inputs, and only the create-course one ever runs against a test community first.

The actor calls (the actual flow)

Skipping the markdown parsing, the cover image render, and the directory walk — the Skool side of the pipeline is four actor calls per course.

Step 1: Upload the cover image

{
  "action": "files:uploadImage",
  "groupSlug": "cagala-aprende-repite",
  "cookies": "<from auth:login>",
  "params": {
    "file": "<base64-encoded JPG of the cover>"
  }
}

Returns coverImage (the S3 reference) + coverImageFile (a UUID Skool stores separately). You need both for the next call.

Step 2: Create the course

{
  "action": "classroom:createCourse",
  "groupSlug": "cagala-aprende-repite",
  "cookies": "<...>",
  "params": {
    "title": "🧠 Intro a LLMs · Decide cuál usar",
    "desc": "Aprende a elegir el modelo correcto para cada caso de uso.",
    "coverImage": "<from step 1>",
    "coverImageFile": "<from step 1>",
    "privacy": 1,
    "minTier": 2,
    "state": 1
  }
}

Returns courseId. Course is now visible (but empty) in the classroom.

Step 3: For each module folder, create a section

{
  "action": "classroom:createFolder",
  "groupSlug": "cagala-aprende-repite",
  "cookies": "<...>",
  "params": {
    "parentCourseId": "<from step 2>",
    "title": "🧱 El LLM no es un Oráculo",
    "state": 1
  }
}

Returns the section's folderId.

Step 4: For each lesson markdown, create the page + set the body

{
  "action": "classroom:createPage",
  "groupSlug": "cagala-aprende-repite",
  "cookies": "<...>",
  "params": {
    "courseId": "<from step 2>",
    "parentId": "<folderId from step 3>",
    "title": "1.1 El LLM no es un Oráculo ni un Google"
  }
}

Returns pageId. Then:

{
  "action": "classroom:setBody",
  "groupSlug": "cagala-aprende-repite",
  "cookies": "<...>",
  "params": {
    "pageId": "<from above>",
    "title": "1.1 El LLM no es un Oráculo ni un Google",
    "bodyMarkdown": "<the contents of L1.1-el-llm-no-es-oraculo-ni-google.md>"
  }
}

Lesson is live in the classroom.

One detail: delete the placeholder page

Skool auto-creates an empty New page in every new course. The script deletes it after step 4 so the user doesn't see an empty placeholder. The actor exposes this via classroom:deletePage if you need it.

What this saved me

The math on a single course:

Step	Manual (UI clicks)	Automated (actor calls)
Create course + cover	~3 minutes	2 calls (~2s)
Create 5 folders	~5 minutes (1/folder, modal friction)	5 calls (~3s)
Create 15 lessons + bodies	~30-45 minutes (1.5-3 min/lesson)	30 calls (~30s)
Total per course	38-53 minutes	~35 seconds

Across 18 courses: roughly 12 hours of clicking vs ~10 minutes of script execution + the time it took to write the script (one afternoon, reusable across all courses).

The first course paid back the entire build investment. The next 17 are pure margin.

Costs on the actor side: ~$0.20 per course at current pricing ($0.005 per result for the 1 result returned by each call, $0.01 per write for ~35 writes per course). Eighteen courses cost less than $4 to publish. Less than the hourly value of fifteen minutes of clicking.

How to copy this for your community

If you're sitting on a directory of course content (markdown, Google Docs, Notion exports) and looking at the manual upload path with dread, the pattern is:

Normalize your source content to markdown files in a consistent directory structure. One .md file per lesson, first line is the title, content is everything below.
Render or upload your course covers once. Each course needs a cover; you can either prerender all of them or generate them from a template (I use a Tailwind HTML template + Playwright screenshot).
Authenticate once with auth:login. The actor returns cookies valid for ~3.5 days.
Walk your directory, calling classroom:createCourse → classroom:createFolder per module → classroom:createPage + classroom:setBody per lesson.
Dry-run against a test community first. Spin up a free Skool community for testing if you don't have one. Skool's create-course is not idempotent — get a clean publish out of the test community before pointing the script at production.
Save the resulting course IDs and page IDs if you'll ever need to update individual lessons. Hardcode them in your incremental-update script.

The whole thing is one Apify actor with one consistent input shape. In n8n / Make.com / Zapier, each call is a single node.

👉 Skool API — Posts, Members & Classroom on Apify

What this unlocks

The directory-as-source-of-truth pattern is what makes the rest of my Skool operations sustainable. The curriculum lives in version-controlled markdown. Editing a lesson is a git commit away from being live. New courses are a copy of an existing directory + node scripts/build-course.mjs.

The Skool UI is now the viewer for community members. The editor is my laptop.

If you want the broader picture of what the actor can do beyond classroom — posts, members, comments, files, events — I wrote the pillar guide here: The Complete Skool API Guide (2026).

And if you want the other case study from this series — how I publish podcast episodes to the classroom 100% automatically with the same actor — that's here: How I Publish Podcast Episodes to Skool 100% Automatically.

Currently testing a similar pipeline for the next 18 courses. If you've automated something on Skool that needs an endpoint not in the actor today, open an issue on the actor's Apify page. That's how the roadmap moves.

How I Publish Podcast Episodes to a Skool Classroom 100% Automatically

Cristian Tala — Sun, 17 May 2026 14:40:24 +0000

How I Publish Podcast Episodes to a Skool Classroom 100% Automatically

We record an episode of Es La Hora De Aprender every week. Three hosts, hour and change of conversation about AI, startups, and the LATAM ecosystem. By the time we finish recording, the next 60 minutes of work are mechanical:

Transcribe.
Cut a thumbnail.
Publish to the podcast website.
Notify the email list.
Cross-post to two WordPress sites for SEO.
Add the episode as a lesson in the Skool community classroom.

I do exactly zero of those steps by hand. The whole chain runs from one shell command. The Skool step — adding the new episode as a lesson in the Podcasts CAR course inside my community — is what I want to walk through here.

This is one of the few automations that requires the Skool API. Skool's UI doesn't expose any bulk-add for classroom lessons. If you want a new episode to appear in your classroom every week, you either click through eight modals manually, or you call the API.

I run the Skool API actor on Apify for this. The actor exposes the classroom endpoints I reverse-engineered. Here's what the pipeline does end-to-end, and the gotchas I hit building it.

What the automation produces

The end state, for context: a course inside my community called Podcasts CAR, free for all members, with one folder per show and one lesson per episode. Episodes are ordered newest-first.

Each lesson is a single page with:

A 1-2 line hook for the episode
The YouTube thumbnail (full size, clickable to YouTube)
Direct links to YouTube, Spotify, Apple Podcasts
Two short paragraphs on what's covered
Five concrete takeaways
An open question for the community
Footer with hosts + episode date

The lesson is not the transcript. The transcript lives on eslahoradeaprender.com for SEO. The classroom lesson is a curated synthesis — the version a community member skims to decide whether the episode is worth their hour.

That distinction matters. If you dump the transcript into the classroom, you cannibalize your own SEO and the lesson becomes too long to skim. Synthesis in the classroom, full transcript on the podcast site.

12 episodes published this way so far. Zero manual clicks per episode.

The pipeline, end to end

The chain is six steps. Skool is step 5.

Episode published on the podcast website (Astro static site)
Build check + git push + IndexNow notification to Bing/Yandex
Syndicated to cristiantala.com (WordPress, as a podcast_episodes custom post type) and ecosistemastartup.com (WordPress, as a regular post)
Google Search Console sitemap resubmit
Skool lesson created in the Podcasts CAR course → this post is about this step
Email notification to the newsletter list

Steps 1-4 and 6 are out of scope for this post. Step 5 is what the Skool API handles.

Why Skool needed the API

When I designed the Podcasts CAR course, I had two options:

Option A: publish each episode as a separate Skool post in the community feed.

Option B: publish each episode as a lesson inside a course in the classroom.

Option A is what most Skool community owners do. It's the path of least resistance because the UI makes it easy. It also means the episode scrolls out of the feed in two days and is never findable again.

Option B (classroom) gives you a permanent, indexed, browsable archive. New members can binge old episodes the way they binge any other course. Episodes don't compete with daily feed activity. And the format scales: I added a second folder for the Ecosistema Startup podcast without rebuilding anything.

But Option B has zero UI affordance for "add a new lesson to an existing course from outside Skool." You have to log in, navigate to the course, click "Add lesson", fill in the modal, drag the lesson into the right position, click save, repeat for the body content, set the cover, save again. Every. Single. Week.

The API lets me do it in two function calls.

The actor calls (the actual code)

Here's the slimmed-down version of what the pipeline does after the episode is published on the podcast site. Skipping error handling and the YouTube ID extraction so the flow is clear.

Step 1: Build the lesson body in markdown

# EP12: Ley IA Chile · agentes autónomos · default a IA

Mediados de mayo. Cristian, Diego y Rodrigo discuten el borrador
de la ley IA chilena, qué significa "agente autónomo" en la
práctica, y por qué cada vez más gente vuelve al default de
preguntarle a la IA antes que a Google.

## Ver o escuchar el episodio

![EP12 en YouTube](https://img.youtube.com/vi/VIDEO_ID/maxresdefault.jpg)

▶️ **YouTube** — [youtube.com/watch?v=VIDEO_ID](https://youtube.com/watch?v=VIDEO_ID)
🎧 **Spotify** — [open.spotify.com/episode/...](https://open.spotify.com/episode/...)
🍎 **Apple Podcasts** — [podcasts.apple.com/...](https://podcasts.apple.com/...)

## Lo que se cubre

[Two paragraphs of synthesis — what the episode is about, written
to be skimmable in 45 seconds]

## 5 takeaways concretos

1. ...
2. ...
3. ...
4. ...
5. ...

## Pregunta abierta para la comunidad

[A real open question that invites a comment in the community,
not a rhetorical one]

---
*Cristian Tala · Diego Arias · Rodrigo Rojo · 15-may-2026*

This is just a string in my pipeline. Skool eats markdown via the actor; I don't have to learn their internal TipTap JSON format.

Step 2: Authenticate (once per 3.5 days)

The actor's auth:login action returns a cookie string that's valid for ~3.5 days. I cache it in my pipeline's KV store and only re-login when it expires.

{
  "action": "auth:login",
  "email": "admin@cristiantala.com",
  "password": "...",
  "groupSlug": "cagala-aprende-repite"
}

Returns:

{
  "success": true,
  "cookies": "auth_token=...; client_id=...; aws-waf-token=...",
  "expiresAt": "2026-05-20T22:51:34.636Z",
  "buildId": "1778782667413"
}

Step 3: Create the lesson page

{
  "action": "classroom:createPage",
  "groupSlug": "cagala-aprende-repite",
  "cookies": "<from auth:login>",
  "params": {
    "courseId": "76b80da4e0ef48cb9da7b7f23229f44a",
    "parentId": "<folder-id-for-ELHDA>",
    "title": "EP12: Ley IA Chile · agentes autónomos · default a IA"
  }
}

The response includes a pageId. We use that next.

Step 4: Set the lesson body

{
  "action": "classroom:setBody",
  "groupSlug": "cagala-aprende-repite",
  "cookies": "<from auth:login>",
  "params": {
    "pageId": "<from step 3>",
    "title": "EP12: Ley IA Chile · agentes autónomos · default a IA",
    "bodyMarkdown": "<the markdown from step 1>"
  }
}

That's it. The episode is now a lesson in the classroom, ordered at the top of the ELHDA folder.

End-to-end from "episode published on podcast site" to "lesson live in Skool classroom" — about 30 seconds, mostly waiting on Skool's API.

Three gotchas that cost me time

1. YouTube embeds: thumbnail-only, no native player

I wanted an embedded YouTube player in the lesson. Skool's REST API accepts a videoId field in setBody — but it requires Skool's internal video ID, not the YouTube ID.

When you paste a YouTube URL into Skool's UI editor, Skool's frontend hits some endpoint, resolves the YouTube URL into an internal video ID, and stores that. There's no documented REST endpoint to do this resolution programmatically.

For now I render the YouTube thumbnail as a markdown image and put the YouTube link immediately below. Visually it looks like a clickable embed. Functionally, the click goes to YouTube instead of playing inline. Acceptable trade-off.

Capturing the YouTube → Skool video ID endpoint with Playwright is on the roadmap. If you'd find it useful, open an issue on the actor — that's how I prioritize.

2. YouTube ID regex: don't use `\w+`

My first version of the pipeline extracted YouTube IDs from URLs with a regex that used \w+. That matches letters, digits, and underscores — but not hyphens.

YouTube IDs are exactly 11 characters from [A-Za-z0-9_-]. Two of my episodes had IDs starting with or containing hyphens. The regex captured 43nvC instead of 43nvC-1fxKY and Ph instead of Ph-7H1atqoA. Episode 7's ID started with - and the regex didn't match at all.

Fix: use [A-Za-z0-9_-]{11} for YouTube IDs. Always specify the character class and the fixed length.

Generic-feeling gotcha, but it cost me an afternoon. Sharing in case it saves you one.

3. Re-running the pipeline creates a NEW course

The script I use for one-shot course creation (initial publish of the Podcasts CAR course, all 12 episodes at once) is not idempotent. Re-running it creates an entirely new course, not an update. Skool has no "upsert course by name."

For incremental episode additions, I use a different code path that:

Looks up the existing courseId (hardcoded in my pipeline)
Looks up the existing folderId (also hardcoded)
Creates just the new page (createPage) and sets the body (setBody)

If you build this kind of automation: keep the course ID and folder IDs as constants in your pipeline. Don't recompute them by name lookup unless you want a course nuke on a typo.

What this saves me per week

The manual version of this:

Log in to Skool
Navigate to Podcasts CAR course
Click Add lesson on the ELHDA folder
Type the title
Drag the new lesson to position 1 (newest first)
Click into the lesson
Type or paste the body content
Save
Confirm cover renders, save again if it doesn't

Realistic time: 8-12 minutes per episode if you're focused, more if you context-switch in the middle. Weekly podcast = 35-50 minutes/month, every month, forever.

The automated version: zero seconds of human time. The shell command that publishes the episode to the website fires the whole chain.

Multiply this across all the other things I automate against Skool (member approvals, daily engagement bot, course publishing) and the actor pays for itself the first week.

How to copy this

If you have a Skool community and a podcast (or any recurring content), the pattern transfers directly:

Create one course in your Skool classroom to hold the archive (do this manually, once)
Note down the courseId and folderId — you'll hardcode these in your pipeline
Authenticate once with auth:login, cache the cookies for 3.5 days
For each new content item, call classroom:createPage + classroom:setBody

The whole automation is two actor calls per episode (plus the auth refresh every few days). In n8n, that's two HTTP request nodes. In Make.com, two Apify modules. In Zapier, two steps.

👉 Skool API — Posts, Members & Classroom on Apify

Pricing: pay-per-event. Two writes per episode + auth occasionally = a few cents per week per podcast.

If you want the full pillar on what the actor can do beyond classroom (posts, members, comments, files): I wrote that here — The Complete Skool API Guide (2026).

And if you want the next case study — uploading an 18-course classroom from markdown in a single script — that's here: How I Uploaded an 18-Course Classroom to Skool With One Script.

Found a gotcha I didn't cover, or you've automated something on Skool that requires an endpoint the actor doesn't expose? Open an issue on the actor's Apify page. That's how the roadmap gets built.

The Complete Skool API Guide (2026): Posts, Members, Classroom, and 100% Automations

Cristian Tala — Sun, 17 May 2026 14:40:21 +0000

The Complete Skool API Guide (2026): Posts, Members, Classroom, and 100% Automations

Skool doesn't have a public API. They've said this publicly, repeatedly, for years.

That's a problem if you run a community on Skool and want to do anything beyond clicking buttons in their UI: bulk-approve members, auto-reply to comments, publish a course from markdown, sync members to your CRM, post the latest podcast episode to your classroom without opening a browser.

I run a Skool community called Cágala, Aprende, Repite (CAR). 484 members, paid tiers, daily activity. There's no way I'm clicking buttons for all of that. So I reverse-engineered the API. Then I built it into an Apify actor so you don't have to.

This guide is everything I learned. Real endpoints, real auth flow, real gotchas — including the ones that cost me a week of debugging.

One thing upfront: every code snippet here shows you how to call the actor on Apify, not the actor's source code. The implementation lives in a private repo for reasons I'll explain at the end. You can run the actor today without touching the source.

How Skool actually works under the hood

Skool runs on two backends, and most third-party tools get this wrong.

Reads go through Next.js SSR endpoints. When you load a community page in your browser, the data comes from https://www.skool.com/_next/data/{buildId}/{slug}.json. Fast, no auth challenge, perfect for scraping.

Writes go through a separate REST API at https://api2.skool.com. Different auth surface, different headers, different error patterns.

This split has two consequences you'll hit:

The buildId rotates roughly weekly when Skool deploys a new version of their frontend. If your scraper caches a buildId and that build expires, every read returns 404 with no clear hint that you need to refresh.
Authentication tokens expire on different clocks. The session JWT lasts months, but the Cloudflare WAF token (aws-waf-token) expires after about 3.5 days. After that, all writes return 403 until you re-authenticate through a fresh browser session.

A naive scraper breaks every 3-7 days for one of these two reasons. The actor handles both automatically.

Authentication: cookies vs Playwright

Skool's login flow is protected by Cloudflare WAF. You can't just POST /login with email + password and get a token. You need a real browser to clear the challenge, which is why the actor uses Playwright for the initial login.

The full cookie set Skool requires:

auth_token — JWT, long-lived (months)
client_id — 32-char hex, stable per session
aws-waf-token — Cloudflare WAF cookie, expires ~3.5 days

All three are required. Drop any one and writes fail with 403.

The actor exposes an auth:login action that runs the Playwright flow once and returns a cookie string you can reuse:

{
  "action": "auth:login",
  "email": "you@example.com",
  "password": "...",
  "groupSlug": "your-skool-group"
}

Response:

{
  "success": true,
  "cookies": "auth_token=...; client_id=...; aws-waf-token=...",
  "expiresAt": "2026-05-20T22:51:34.636Z",
  "expiresInDays": 3.5,
  "buildId": "1778782667413"
}

Subsequent calls pass the cookies string and skip the Playwright bootstrap. A login takes about 10 seconds. A cookie-authenticated call takes about 2. If you're running a workflow that does many operations, this matters.

When the WAF cookie expires (every 3.5 days), the actor returns a structured error with errorCode: AUTH_REQUIRED and you re-run auth:login. Schedule this in your automation and you never think about auth again.

The endpoint catalog (what you can actually do)

The actor covers every Skool resource I've reverse-engineered. Each one is a separate action in the actor input.

Posts

Action	What it does
`posts:list`	List posts in a community (with pagination, sort, category filter)
`posts:get`	Fetch a single post by ID, with author, likes, label
`posts:create`	Create a top-level post. Requires `labelId` if the community has categories (it does)
`posts:update`	Edit title/content/label of an existing post
`posts:delete`	Delete a post (admin only)
`posts:createComment`	Reply to a post or to another comment
`posts:getComments`	Up to ~30 top-level comments per call
`posts:getCommentsFull`	Playwright-based scrape that returns ALL comments in a thread (slower, charged at scrape rate)

Posts and comments are the same object in Skool's data model. A comment is just a post with rootId (the original post) and parentId (its direct parent). This matters for one specific case I'll get to in a minute.

Members

Action	What it does
`members:list`	List members of a group
`members:pending`	List waitlist (people who applied but not yet approved)
`members:approve`	Approve a pending member
`members:reject`	Reject a pending member
`members:ban`	Ban an existing member
`members:batchApprove`	Approve multiple at once

Classroom (courses, folders, lessons)

Action	What it does
`classroom:createCourse`	Create a top-level course with cover image, privacy, tier gate, drip schedule
`classroom:createFolder`	Add a section (folder) inside a course
`classroom:createPage`	Add a lesson page inside a folder
`classroom:setBody`	Set the lesson body. Accepts markdown and converts to Skool's TipTap JSON format internally
`classroom:updateCourse`	Update course metadata. Read-then-write internally because of a subtle Skool quirk (see "Gotchas" below)
`classroom:updateResources`	Attach uploaded files to a lesson's Resources section

Files

Action	What it does
`files:uploadImage`	Upload a cover image. Returns the S3 reference Skool expects
`files:uploadFile`	Upload any file (PDF, ZIP, etc.) for use as a lesson resource. Sets `privacy:1` automatically — Skool silently rejects files without it

Groups

Action	What it does
`groups:get`	Fetch a group's full metadata: members count, categories (`labels`), tiers, settings

Events

Action	What it does
`events:list`	List events with real next-occurrence times + timezone + occurrenceId for RSVP

System

Action	What it does
`system:health`	Cheap, no-auth health check
`system:debug`	Returns Apify egress IP, raw Skool homepage status, extracted buildId, and a full `posts:list` replication — invaluable when something breaks intermittently

Common gotchas (the stuff that bit me, so it doesn't bite you)

These aren't theoretical. Each one cost me hours.

1. `posts:create` requires `labelId` if your community has categories

If your Skool community has post categories (almost all do), posts:create without labelId returns:

HTTP 422: {"object_type":"post","fields":[{"name":"metadata.labels","error":"You must select a category","user":true}]}

The actor surfaces this as errorCode: MISSING_CATEGORY with a hint. Fetch the available labels with groups:get, then pass the labelId.

2. Top-level comments need `parentId = rootId`

This is the most unintuitive piece of Skool's data model. To create a top-level comment on a post, you set BOTH parentId AND rootId to the post's ID. To reply to an existing comment, you set rootId to the original post and parentId to the comment you're replying to.

{
  "action": "posts:createComment",
  "params": {
    "rootId": "post-id",
    "parentId": "post-id",    // same as rootId for top-level
    "content": "..."
  }
}

Skip this and you get a 404 that says nothing useful.

3. `posts:update` body shape is flat, not wrapped

posts:create wraps its data in a metadata object. posts:update does NOT — it expects flat fields. Sending the wrapper returns 200 OK and silently ignores your update.

The actor handles the shape difference for you. If you're talking to the Skool API directly, this will burn you for a day. (It burned me for a day.)

4. `classroom:updateCourse` silently resets `privacy` to 0

If you PUT a course with a partial body, Skool quietly resets privacy (your paywall) to 0 (Open) and amount (price) to 0. Tier gating is preserved. Privacy and amount are not.

I caught this against twelve production courses. The actor's updateCourse does a read-then-write internally: fetches the current state, merges your input on top, writes the full body. Slower by ~200ms, but your paywall doesn't disappear.

5. `BUILDID_STALE` 404s are usually transient

Skool deploys a new build of their frontend, your cached buildId goes stale, you get 404s on reads. The actor's retry handler refreshes the buildId from the homepage and retries automatically.

If you see this in your error logs and it self-resolves 30 minutes later, that was a Skool deploy mid-flight (or a Cloudflare blip on Apify's egress IP). The actor logs system:debug snapshots so you can diagnose without redeploying.

6. `x402-payment-required` ≠ payment problem

If the actor returns x402-payment-required on every action including reads, this is not a billing issue. It's Apify's notice: UNDER_MAINTENANCE flag, triggered automatically when a published actor fails its daily quality check.

The actor's default action is system:health, which never throws — so the quality check stays green. If you ever see this flag, clear it with one PUT to the Apify API. (Documentation in the actor README.)

7. `members:approve` and `members:reject` need `memberId`, not `id`

Skool returns two IDs per member: id is the global user ID (stable across Skool), memberId is the group-specific membership ID. Approve/reject/ban operations need memberId. Using id returns HTTP 404 with no useful message.

The actor surfaces both fields and uses the correct one. If you're talking to Skool directly, this single mismatch will silently kill a batch of 50 approvals.

How I use this in production

I'm not building this as a toy. CAR has 484 members, 19 courses in the classroom, daily posts, daily approvals, a podcast that syndicates new episodes to the community. None of that is manual.

A few examples (each one is its own deep-dive post — links below):

Publishing podcast episodes to the classroom 100% automatically. New episode lands on eslahoradeaprender.com → my pipeline syndicates the show notes to the community classroom as a new lesson with the YouTube thumbnail, all in under 30 seconds. Twelve episodes published this way so far, zero manual clicks.
Uploading an 18-course classroom from markdown. When I shipped the curriculum, every course (folders, lessons, covers, tier gates) came from .md files in a local directory. One script, ~3 hours of total runtime to push 18 courses. The R-PUT-COURSE gotcha above came from this exact project.
Daily engagement bot for the community feed. Detects unanswered posts in the community feed, drafts a reply using the community's content (podcast back-catalog, blog, course corpus), sends to Telegram for approval, publishes on click.

If you want the deep-dives:

Get started

The actor is on Apify, ready to use:

👉 Skool API — Posts, Members & Classroom

Pricing is pay-per-event: $0.005 per result returned, $0.01 per write operation, $0.05 for Playwright-based deep scrapes. No subscription. If you're testing it, you'll spend cents.

A complete 10-line example to create a post in your community:

curl -X POST "https://api.apify.com/v2/acts/cristiantala~skool-all-in-one-api/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "action": "posts:create",
    "groupSlug": "your-skool-slug",
    "cookies": "auth_token=...; client_id=...; aws-waf-token=...",
    "params": {
      "title": "Hello from the API",
      "content": "First post via Apify.",
      "labelId": "your-category-id"
    }
  }'

For workflow tools, it's a single Apify node in n8n, Make.com, or Zapier. Pass action, groupSlug, cookies, and the action-specific params. Same shape everywhere.

If you're building AI agents (Claude, ChatGPT function calling, LangChain, OpenClaw) that need to interact with a Skool community: same actor, called as a tool. The action names map cleanly to capabilities.

What's next

The actor covers most of Skool's surface area, but not all. On the wishlist (open as GitHub issues on the actor's Apify page):

Pin to Course Page — pin a post to a specific course view rather than the global feed. Endpoint exists in Skool's UI; needs capture.
About Page API — programmatically read/write a group's About page.
Per-page drip schedules — investigating whether Skool supports drip at the lesson level (not just course level).
YouTube video embed in lessons — Skool generates an internal video ID when you paste a YouTube URL in the editor. We can render thumbnails today, but native embeds need that endpoint captured.

If you have a Skool automation that's currently impossible because the endpoint isn't covered, open an issue. Most of them are an afternoon of Playwright capture away.

Why the source is private

A common question: "Is this open source?"

It's not. The TypeScript SDK behind the actor (skool-js) and the actor wrapper itself live in a private GitHub repo. There are three reasons:

The actor IS the product. If the SDK were public on npm, the conversion path to actual revenue collapses. The actor pays for itself plus my time maintaining the reverse-engineering against Skool's deploys.
Skool deploys frequently. When the WAF flow changes, the buildId path changes, or a new captcha is added, the actor needs a patch within hours. A private repo with paid distribution gives me a sustainable maintenance loop. An open repo with infinite forks does not.
The reverse-engineering itself has cost. Each endpoint captured took 30 minutes to several hours of UI interception. That work compounds in the actor — not in a free clone.

If you need self-hosted SDK access for a specific use case, that's a different conversation; reach out. For everything else, the actor is the fastest path from "I have a Skool community" to "my Skool community runs itself."

If this guide was useful, the best way to help me keep improving the actor is to use it. Every run validates a real use case and tells me what to capture next. Find a gap or hit a gotcha I haven't documented? Open an issue on the actor page — they get answered.

Cambié el Cerebro de Mi Coding Agent: De Opus a Modelos Open-Source por $30/mes

Cristian Tala — Tue, 12 May 2026 19:00:04 +0000

Cómo Reemplazar Claude Pro ($20/mes) y Ahorrar un 96% en Producción

Hace dos años, si me hubieran dicho que iba a reemplazar Claude Pro por algo open-source, me hubiera muerto de risa. «Seguí soñando», te habría dicho. «Los modelos de arriba son mejores porque sí.»

Abril 2026. Anthropic removió silenciosamente a Claude Code del plan Pro de $20/mes. La página de precios quedó con una X donde antes había un check. No hubo comunicado. No hubo email. Un developer lo tweeteó y generó 900K views en Twitter y 400+ comentarios furiosos en Hacker News.

¿Qué pasó realmente? Que el plan «Pro» nunca fue para uso real de un coding agent. Si estás corriendo un agente 3-4 horas por día, el costo real de Opus no es $20/mes — es $11,250/mes por desarrollador. Esto no es un bug. Es una feature del modelo de suscripción: te hace pensar que pagás $20 cuando en realidad consumís $11,250.

El costo real de Opus en producción: hasta $11,250/mes por desarrollador

Mi benchmark corrió 8,000+ tests en 70 modelos para responder exactamente esta pregunta. Los números duelen:

El escenario coding agent es el más revelador. Un agente que lee ~50K tokens de contexto por archivo y genera ~5K tokens de output por archivo. Si haces 1,000 archivos por día, Claude Opus te sale $11,250/mes. La alternativa open-source más capaz para ese caso de uso sale $484/mes.

Calidad no es el problema. Opus 4.7 tiene quality score de 8.08 — top 5 entre todos los modelos medidos. El problema es que estás pagando por una capability que no necesitas en la forma en que la estás usando.

Thinking forzado empeora tus agentes: 8 de 9 modelos rinden peor

Acá viene el hallazgo más contraintuitivo del benchmark.

De los 9 modelos hybrid medidos con force_reasoning=high en la suite de tests agénticos multi-turno:

8 de 9 empeoran su score vs sin thinking forzado
Opus 4.7: -0.67 puntos
Sonnet 4.6: -0.50 puntos
Hermes 4 70B: -0.54 puntos
Solo Kimi K2.5 sube (+0.73 puntos) — la excepción

Un sistema que es 95% correcto en cada paso es solo 36% correcto en 20 pasos. No es un failure de prompting. Es un architecture failure. La forma en que orchestration, persistence, tool driving y verification composition determinan el resultado tanto como el modelo mismo.

La implicación para founders que arman agentes en n8n o OpenClaw: no pagues premium por modelos con thinking forzado. Estás pagando más por un resultado peor en multi-turno real.

¿Por qué 8 de 9 modelos rinden peor con reasoning forzado?

El reasoning extendido extiende la cadena de pensamiento del modelo antes de emitir una respuesta. En benchmarks estáticos (HumanEval, MATH), esto ayuda. En agentes multi-turno que interactúan con herramientas, archivos y APIs en tiempo real, cada segundo adicional de «pensar» es un segundo en que el estado del sistema puede cambiar.

El modelo piensa más, pero el mundo también cambió mientras pensaba. La respuesta correcta cuando empezó a procesar ya no es correcta cuando termina. Esto lo confirma también el postmortem de Anthropic del 23 de abril de 2026: «On March 4, we changed Claude Code’s default reasoning effort from high to medium to reduce very long latency.» — el mismo Anthropic encontró que menos thinking era mejor para la experiencia de usuario. Y cuando revirtieron a high effort después de las quejas, descubrieron que venía con sus propios problemas de calidad.

Provider matters: Groq direct supera a OpenRouter por +0.16 a +0.25 puntos

Otro hallazgo del benchmark que no es obvio a menos que midas.

El mismo modelo rinde mejor cuando el provider es directo (Groq, NIM, Xiaomi) que cuando pasa por un agregador como OpenRouter. Patrón consistente verificado en 4 proveedores con el mismo modelo.

Groq usa hardware dedicado (LPU — Language Processing Unit) en lugar de GPUs tradicionales. El resultado: hasta 10x más velocidad de inferencia. Los números reales de MorphLLM:

Llama 3.1 8B @ Groq: 840 tok/s (el más rápido del mercado)
Llama 4 Scout @ Groq: 594 tok/s
Competencia GPU-based: típicamente 80-150 tok/s

Groq no solo es más rápido — el mismo Llama 3.3 70B rinde mejor ahí que en OpenRouter porque el routing overhead del agregador introduce latencia y variabilidad. La recomendación entonces no es solo «elegí el modelo correcto». Es «elegí el modelo correcto EN el provider correcto».

El costo de la dependencia: por qué un founder no debería depender de un solo proveedor a $100/mes

Les cuento algo que me costó dos exits aprender.

En Pago Fácil, en 2018, dependíamos de un solo proveedor de pagos para el core del negocio. Cuando el proveedor decidió cambiar sus condiciones a mitad de año, nos dejó 60 días para renegociar o migrar. 60 días con un negocio que procesaba $2M/mes en transacciones. Yo estaba solo — sin cofundadores, sin equipo de legal sofisticado, sin leverage. Tuve que aceptar las condiciones porque no había alternativa real en ese momento.

La dependencia tiene un costo que no aparece en el sticker price. Lo escribí en detalle en «La dependencia perfecta«.

Con los modelos de IA pasa lo mismo. Si tu flujo de automatización completo depende de Opus a $25/MTok y Anthropic decide subir precios (como ya hizo removiendo Claude Code de Pro), no tienes opción real. O aceptás las nuevas condiciones o reconstruís todo desde cero.

La estrategia correcta no es «encuentra el modelo más barato». Es «arquitecta para tener siempre un plan B que no te destruya». Esto significa:

-模型的que usas en producción tener al menos un backup en otro provider que renda comparable

NUNCA architecturalizar con la assumption de que un solo provider va a estar disponible o accesible en 12 meses
Preferir modelos con licencias open-source (Apache 2.0, MIT) sobre modelos proprietary cuando el delta de calidad lo permita

8 de los 10 primeros del benchmark usan licencia Apache 2.0 o MIT. No es casualidad.

Top 10 del benchmark: 8 de 10 son open-source

El open-source no es «la opción del pobre». Es la opción que maximiza valor real por dólar invertido — especialmente cuando la métrica es «qué tan bien funciona en MI agente de producción», no «qué tan bien sale en HumanEval».

Paso a paso: cómo migré mi stack de $200/mes a $30/mes

Esto es lo que hice en la práctica, no la teoría.

Semana 1: Evaluar Corrí el benchmark completo en mis casos de uso reales — no en los benchmarks sintéticos. Los que importaban: automation scripts de n8n, parsing de emails, generación de reportes, code review de PRs en GitHub. Identifiqué qué modelos rendían >=90% de la calidad de Opus en CADA caso de uso específico.

Semana 2-3: Dual run Corriste ambos sistemas en paralelo durante 2 semanas. OpenCode con MiniMax M2.7-highspeed para desarrollo day-to-day. Claude Pro seguía disponible para arquitectura y decisiones complejas donde Opus genuinamente aporta. Medí output quality con revisiones manuales.

Semana 4: Cortar Apagué la suscripción a Claude Pro cuando el dual run showed <5% de tareas donde Opus había sido significativamente mejor. Exploré esta dinámica a fondo en Claude Code sin pagar $200 al mes. El corte fue en marzo 2026 — antes del movimiento de Anthropic, pero la decisión ya estaba tomada con datos propios.

Resultado:

Antes: $200/mes en Claude Pro (usaba API directa + Pro seat)
Después: $30/mes aproximadamente ($20 MiniMax subscription + $10 Ollama Cloud + electricidad)
Productividad en tareas de coding: no medí baja objetiva
Tasks donde todavía uso Opus (API directa, pay-per-use): ~2-3 por semana, <$20/mes adicional

Stack recomendado por presupuesto

$0/mes: 100% local con Ollama

Si tienes hardware decente (32GB+ RAM), puedes correr modelos open-source directamente en tu máquina. DeepSeek-Coder V3, Qwen 2.5 Coder 32B, Mistral 7B — todos disponibles en Ollama con install one-liner. Tengo una guía completa de herramientas self-hosted donde reviso las opciones en detalle.

Costo real: $0/mes en subscriptions. Solo electricidad (~2-3/kWh dependiendo de dónde estés).

Limitación: latencia más alta que cloud, sin internet no funciona. Para tareas batch o que no son tiempo-real, perfectamente viable.

$20-50/mes: Groq + Ollama Cloud

Groq tier gratuito tiene 40 RPM con modelos como Llama 3.1 8B y 70B. Para automatización con volumen bajo-medio, esto alcanza. Si necesitas más volumen, el tier pago de Groq corre ~$15/mes por 500K tokens/mes en los modelos más rápidos.

Complementás con Ollama Cloud para modelos que Groq no tiene.

$100+/mes: API directa + Cursor Pro

Si todavía necesitas Opus para tareas complejas con volumen alto, la API directa de Anthropic (pay-per-use) es más flexible que el plan Max $100/mes. Pagas por lo que usás realmente.

A este nivel de gasto, Cursor Pro ($20/mes) como IDE con Claude Code integration puede reemplazar el workflow completo de desarrollo. No es lo mismo que Claude Code standalone, pero para un developer individual es suficiente.

El cierre que Anthropic no te dice

Cuando Anthropic removió Claude Code de Pro, no fue un accidente. Les estaban diciendo algo en código: «el modelo de suscripción $20 no cierra con el uso real de un coding agent.»

Y tenían razón.

Para founders que construyen agentes en producción, la alternativa no es «buscar el mejor descuento en Anthropic». Es arquitecturar para producción con modelos que maximized value per dollar en el caso de uso real — y con la resiliencia de no depender de un solo proveedor.

Todo esto está medido. Los datos del benchmark — 8,000+ runs, 70 modelos — están públicos en GitHub. Publiqué el benchmark completo de abril 2026 con metodología. La calculadora interactiva te deja filtrar por presupuesto, calls/mes y caso de uso.

No me creas a mí. Corré los números vos mismo.

FAQ

¿Realmente puedo reemplazar Claude Code con un modelo open-source?

Para la mayoría de casos de uso, sí. Para coding asistido (autocomplete, refactors simples, code review), modelos como Llama 3.3 70B o Devstral rinden al nivel de Sonnet 4.6. Para tareas de código complejo o architecture decisions de alto nivel, Opus sigue siendo top. El punto es que no necesitas Opus para todo — solo para lo que realmente lo requiere.

¿Qué pasa si ya pago Claude Pro?

Si usas Claude Code 3+ horas por día, el plan Pro se te queda corto igual. Los límites de uso de Pro son agresivos para uso agéntico real. La alternativa más económica es API directa de Anthropic + un wrapper como Aider o Cline, que te sale $15-40/mes según uso real.

¿Groq es confiable para producción?

Groq tiene rate limits más bajos que OpenRouter en el tier gratuito (40 RPM). Para automatización de producción con volumen alto, la recomendación es combinar Groq (para modelos que ya conoces y rinden bien) + un provider de backup para cuando Groq tiene degraded performance. Mi stack usa ambos.

¿El costo es realmente tan diferente o es clickbait?

Los $11,250/mes son para un escenario específico: 1,000 archivos de código procesados por día con Opus 4.7. Si tu volumen es menor, el costo baja proporcionalmente. Un developer que usa Claude Code 1 hora por día puede estar en $30-50/mes con API directa. El punto no es que todos van a pagar $11,250/mes — es que el modelo de suscripción oculta el costo real cuando tu uso escala.

¿Dónde están los datos del benchmark?

Todo el dataset, metodología y código fuente están públicos en github.com/ctala/ai-benchmarks-alternativos bajo licencia MIT. 8,000+ runs, 70 modelos, scoring ponderado por costo real para founders LATAM. La calculadora interactiva está en benchmarks.cristiantala.com.

The post Cambié el Cerebro de Mi Coding Agent: De Opus a Modelos Open-Source por $30/mes appeared first on Cristian Tala Sánchez.

Este articulo fue publicado originalmente en cristiantala.com. Si te interesa emprendimiento, IA y automatizacion, unite gratis a la comunidad Cagala, Aprende, Repite.

The Complete Skool API: 9 Months of Reverse-Engineering 33 Actions (n8n + TypeScript + AI Agents)

Cristian Tala — Tue, 12 May 2026 18:16:50 +0000

TL;DR: I spent 9 months reverse-engineering Skool.com — the community platform with millions of paying members but no public API. The result is a production Apify actor that handles posts, comments, members, classroom courses, file uploads, Auto DM, and group settings — usable from n8n, Make.com, Zapier, or LLM agents (Claude, ChatGPT, LangChain) with pay-per-event pricing. Documentation, recipes, and the full API reference are at github.com/ctala/skool-api-docs. This post is the technical story: what I learned, where Skool's architecture surprised me, and how this is being used in production today.

The problem: Skool has no public API

Skool is one of the fastest-growing community platforms — used by creators, course sellers, agencies, and SaaS founders to host paying communities ($30K+ MRR cases are common). It has tens of thousands of paying communities, millions of members.

It has zero public API.

If you're an admin running a community at scale, this means:

Manually approving every new member application
Manually replying to welcome threads
Manually uploading course content one page at a time
Manually copying content from other platforms into Skool
No way to integrate Skool with n8n, Make.com, or your CRM
No way to build AI agents that operate inside your community

For a $30K MRR community, "manual" stops scaling fast. The official recommendation is "hire a community manager." That's a $3-5K/month line item to do data entry. For a single founder with AI agents available, it's absurd.

So I started reverse-engineering.

Skool API architecture: SSR for reads, REST for writes

When you look at Skool with browser DevTools, you don't see clean REST endpoints. You see two patterns intermixed:

Reads go through Next.js SSR data endpoints: /_next/data/{buildId}/{slug}.json. These return the same data the page would render server-side, in JSON. Fast, public-ish (still requires auth cookies), and oddly stable. The buildId changes on every Skool deploy (~weekly), so you need to refresh it dynamically.
Writes go through a separate REST API at api2.skool.com. Create post, update comment, approve member, ban — all POST/DELETE to api2.skool.com/.... Uses Authorization: Bearer ... with JWT tokens.

This split is unusual. Most platforms either: (a) have a uniform REST/GraphQL API, or (b) hide reads behind an internal /api/... route on the same domain. Skool does neither.

Why it matters for an API consumer: you can't just hit one base URL. Your library needs two clients — one for SSR reads (with buildId rotation logic), one for REST writes (with bearer token rotation logic).

The buildId rotation gotcha

Every Skool deploy invalidates the cached buildId. If your library hardcodes one, all reads stop working until you refresh.

The fix: extract the current buildId from the homepage HTML (/) before reading. Skool exposes it in a <script id="__NEXT_DATA__"> tag that contains {"buildId":"..."}. Parse it, cache it, retry your read.

Initially I extracted from /dashboard, but Skool quietly removed that route in March 2026. Switched to / with /about fallback. Lesson: buildId extraction needs to live in your library as a refreshable concern, not a constant.

The Skool data model: posts and comments are the same object

This is the elegant part of Skool's data model and the part most reverse engineers miss.

In Skool, a post and a comment are the same database entity. The difference is just two fields:

rootId: the original post ID. For a top-level post, rootId == id. For a comment, rootId points to the post it's commenting on.
parentId: the immediate parent. For a top-level post, parentId == id. For a comment on a post, parentId == postId. For a nested reply, parentId == commentId.

This means:

Reply to a post: create with rootId = postId, parentId = postId
Reply to a comment (nested): create with rootId = postId, parentId = commentId
Edit a comment: use the post-update endpoint with the comment's ID
Delete a comment: use the post-delete endpoint with the comment's ID

There is no /comments endpoint. There is no comments: namespace. Everything is posts:.

Once you see this, the whole API gets simpler. I exposed it as the same Posts module in my library, with createComment() just being a thin wrapper around createPost() that sets rootId and parentId correctly.

Skool content format: plain text for posts, TipTap JSON for classroom

For posts and comments: plain text. No HTML, no markdown rendering server-side. The Skool editor handles formatting client-side via simple character codes (**bold** becomes bold in the UI, but the stored content is literal characters).

For classroom course bodies: TipTap JSON. Skool's classroom uses TipTap (the rich text editor library built on ProseMirror) and stores course/lesson bodies as TipTap JSON documents.

This split made classroom:setBody the most complex action in my library. To make it usable by non-developers, I wrote a markdown → TipTap converter from scratch (zero dependencies, ~500 LOC) that handles:

Headings (h1-h6)
Bold, italic, code, links
Bullet and ordered lists
Code blocks
Blockquote callouts (Skool renders these as colored boxes)
Tables (simple)
Images and embeds

This means you can write your course content in .md files in Git, push to your repo, and have a CI job publish updates to Skool. Course-as-code.

Skool API authentication: cookies, JWT, and AWS WAF tokens

Skool sits behind AWS WAF (Web Application Firewall) Captcha. Your authenticated session has three cookies that matter:

auth_token: JWT, ~30 day expiry
client_id: device fingerprint, ~1 year
aws-waf-token: rotating, ~3.5 day expiry

If aws-waf-token expires and you keep using the cached cookies, you get 403 errors that look like auth failures. The fix isn't to refresh auth_token — it's to do a full Playwright login (which solves the WAF challenge and gets a fresh aws-waf-token).

My actor exposes this as auth:login — runs Playwright once, returns a cookies string with all three tokens, and your subsequent calls can reuse those cookies for ~3.5 days at ~2s per call (no browser needed for reads/writes once you have valid cookies).

Why this matters for scheduled jobs

If you run a cron that hits Skool daily, you need to re-authenticate every 3-3.5 days. Either schedule it explicitly or build a retry-on-403 pattern that triggers re-auth. The actor returns structured errorCategory: "auth_error" with errorCode: "WAF_EXPIRED" so n8n / Make.com workflows can branch on it.

From skool-js TypeScript library to a production Skool API actor on Apify

After 6 months of building skool-js internally for my own use (operating Cágala, Aprende, Repite, a 500+ member community), I realized other community operators had the same problem. The internal library was solid, the test suite covered ~85% of real-world use cases, but distributing a TypeScript library as the consumption layer was wrong: most community operators aren't developers, and shipping it as open source meant abandoning maintenance the moment my own community didn't need an update.

The fix: wrap it in an Apify actor with three properties:

Single HTTP endpoint — any HTTP client (curl, Postman, n8n's HTTP node, Make.com's HTTP module) can call it
Pay-per-event pricing — $0.005 per dataset result, $0.01 per write operation, $0.05 per scrape operation. No subscription, no minimums. You pay for what you use.
Action-based API — single input with action: "posts:create" (or 33 other actions), groupSlug, cookies, and params. Consistent shape across the entire surface.

Single consumption layer: the Apify actor, HTTP-callable from anything (n8n, Make.com, Zapier, Pipedream, custom backends, LLM tool-use), pay-per-event pricing, no infra to maintain on your side. The internal skool-js library powers it but stays private — that's what keeps the actor sustainably maintained instead of becoming another abandoned reverse-engineering project on GitHub.

33 Skool API actions: posts, comments, members, classroom, files, groups

The actor exposes these namespaces:

Posts — list, filter (by date, by unanswered, combine criteria), get, create, update, delete, pin/unpin, vote (like/unlike), createComment, getComments (REST, fast, max ~35), getCommentsFull (Playwright scroll, returns ALL comments in a thread bypassing Skool's REST cap)

Members — list active, list pending applications, approve, reject, ban, batch approve

Events — list all calendar events, list upcoming

Classroom (courses) — create course, create folder, create page (lesson), set body from markdown, update course/page (preserves privacy/min_tier/amount), delete unit (cascades), get full tree, list courses, update resources (downloadable files)

Files — upload cover image, upload private file (PDF/JSON/ZIP for classroom Resources with privacy:1)

Groups — get group info, set Auto DM message (with #NAME# and #GROUPNAME# tokens)

System — health check (no auth, no Skool calls — deterministic 2s response for monitoring)

Every action returns either the requested data or a structured error payload (success: false, errorCode, errorCategory, retryable, hint). The hint field is designed for LLM tool-use: an agent can read it and self-correct on errors like missing categories or expired auth.

How to integrate Skool with n8n, Make.com, and Zapier

The Skool API actor is designed as a single HTTP endpoint, which makes it drop-in compatible with every workflow automation platform:

n8n: use the HTTP Request node. One node per Skool action. Pattern: auth:login once → save cookies to workflow variable → reuse cookies across subsequent calls. Free n8n template here shows the exact wiring for auto-approving members with GPT-4o screening.

Make.com: use the HTTP module. Same pattern — login once, reuse cookies. The structured errorCategory field in actor responses lets you build Router branches without try/catch logic.

Zapier: works via webhook-trigger + HTTP action. Zapier's free tier supports this but you'll hit the task limit fast on busy communities. n8n self-hosted is the cost-efficient option once you have >10 daily workflow runs.

Pipedream: native HTTP support. Drop the actor URL into any Pipedream step, pass cookies from a stored secret.

Why a single-endpoint, action-based API beats traditional REST for these platforms: every workflow node maps to one HTTP request with a different action value. No URL templating, no header juggling per endpoint, no documentation hunt for "is it POST or PUT for editing?". Just action: "posts:update" and you're done.

Using the Skool API with AI agents (Claude, ChatGPT, MCP, LangChain)

Because every action has a consistent shape and structured error responses with recovery hint fields, the Skool API actor is unusually well-suited as a tool in LLM tool-calling stacks:

Anthropic Claude (tool use): define a single tool skool_api with parameters action (enum of 33 values), groupSlug, cookies, and params. The model picks the right action per user request. Error hints feed back into the conversation for self-correction.

OpenAI function calling: same pattern, define one function. Function calling format is compatible.

LangChain Tool: wrap in a Tool class. The actor returns dataset arrays which LangChain agents handle natively.

Model Context Protocol (MCP): Apify exposes any public actor via https://mcp.apify.com?tools=cristiantala/skool-all-in-one-api. Configure once in Claude Desktop / Cursor / any MCP client, and the model sees all 33 actions as discoverable tools. No separate server to host — Apify handles the MCP layer for you, and the same pay-per-event billing applies (publishers earn from MCP invocations the same as regular runs).

Custom AI agents (OpenClaw, Cline, Aider, etc.): any agent that supports HTTP tool calls works. The actor docs include schemas in JSON Schema format for autogenerated tool definitions.

This is where the "structured error payload with hint field" design pays off. A naive HTTP wrapper around Skool's REST endpoints would return raw 422 errors. The actor returns:

{
  "success": false,
  "errorCode": "MISSING_CATEGORY",
  "errorCategory": "skool_api_error",
  "hint": "This Skool group requires posts to have a category. Pass `params.labelId` in posts:create. Get available labels with groups:get."
}

An AI agent reads that hint and self-corrects without human intervention. That's the difference between a wrapped REST API and an API designed for agents.

Production use cases (real examples)

These are workflows running in production today:

1. Auto-approve members with AI screening

n8n workflow:

Cron every 6h → auth:login (if cookies expired)
members:pending → returns list of pending applications with whyJoin text
For each: pass whyJoin + LinkedIn URL to GPT-4o with a screening prompt ("does this person fit the community? rate 1-10")
If rating ≥ 7 → members:approve. If < 4 → members:reject with message. Else → manual review in Telegram.

Result: hours per week saved. Spam applications filtered in seconds. Published as a free n8n template here.

2. Auto-DM new members with personalized welcome

One-time setup with groups:setAutoDM, then runs forever inside Skool's own infra (Skool sends the DM, the actor just sets the template). Use #NAME# and #GROUPNAME# tokens for personalization. Skool's UI limits this to 300 chars, but you can fit a meaningful welcome + first action.

3. Publish a complete course from markdown files

I write course content in .md files in a private GitHub repo. CI job:

Detects changes to a course directory
For each new lesson: classroom:createPage + classroom:setBody (markdown → TipTap conversion)
For each updated lesson: posts:update with new content
For attached resources (PDFs): files:uploadFile (with privacy:1) + classroom:updateResources

Course-as-code. Lessons get reviewed via PR. Skool stays in sync with the repo.

4. Scrape ALL comments in a thread (bypass Skool's ~35 REST cap)

Skool's REST endpoint for comments returns a maximum of ~35 per thread. For threads with hundreds (welcome threads, AMA posts, popular discussions), posts:getCommentsFull uses Playwright to scroll the post page and extract every comment from the DOM. Slower (~30-60s) and costs $0.05 per invocation, but returns everything.

I use this to audit my welcome thread: 229 introductions, find anyone I haven't replied to yet, generate personalized welcome messages, batch reply.

5. Auto-reply to unanswered posts

Filter posts by commentCount === 0 after 24h, run them through an LLM with the community's context, generate a thoughtful first reply, post via posts:createComment with manual approval before send. Stops valuable questions from sitting in the void.

Skool API alternatives: choosing the right tool for your use case

There are roughly three approaches today to programmatic access to Skool:

Subscription-based API services — third-party developers who built their own reverse-engineered API and resell access via API keys. These typically focus on read operations (list posts, list members) and have limited write coverage. Pricing is monthly subscription, regardless of usage. Good fit if you have predictable monthly volume and only need read access.
Generic scrapers on Apify Store — single-purpose actors that extract one type of data (member emails, course videos, post lists). No write operations. Useful for one-off data extraction, not for ongoing automation.
Full read+write Skool API actor — pay-per-event, complete CRUD across all surface area (posts, comments, members, classroom, files, groups, Auto DM). The Apify actor I built falls in this category. Best fit if you need ongoing writes (auto-approve, auto-comment, course publishing, Auto DM updates).

	Subscription API services	Generic Apify scrapers	This Skool API actor
Read access	Limited endpoints	Single purpose	All 33 actions
Write access	Very limited	None	Full CRUD
Classroom support	No	Some scrapers only	Full (create, update, delete, body, resources)
Auto DM	No	No	Yes (`groups:setAutoDM`)
Pricing model	Monthly subscription	Pay-per-event	Pay-per-event
Best for	Predictable read volume	One-off extraction	Ongoing community automation
AI agent ready	Manual schema	Manual schema	Action-based + hint field

The "best" tool depends on your use case. If you only need to read data once, a generic scraper is fine. If you need ongoing writes (auto-approve members, auto-comment, course publishing, Auto DM updates), the full read+write actor is the only option that won't hit limits.

💡 Try the Skool API actor: apify.com/cristiantala/skool-all-in-one-api. First call gets you a cookies string you can reuse for 3.5 days. Pay-per-event means typical "auto-approve 10 members" run costs $0.10. No subscription, no minimums. Used in production at CAR (500+ members) — before: 4h/week of manual approvals; after: 10 min/week of review.

Why I'm not building Skool's "official" API

Skool will likely build a public API eventually. When they do, mine becomes redundant. That's fine.

In the meantime: every community operator running at scale today either has this problem solved (using a tool like mine, or a custom in-house scraper) or doesn't scale. The market for community operations automation is real — Discord has Apps, Slack has Bots, Circle has Workflows, every modern platform has SOME automation surface. Skool's absence here is the gap, and someone has to fill it until they do.

The actor itself is the product, but everything around it is in the open: github.com/ctala/skool-api-docs has the full API reference, recipes, and a CHANGELOG that tracks every Skool-side change I detect. If you're a Skool community operator and you want to automate, the actor is one HTTP call away. If you're someone at Skool reading this — please ship a public API. I'll happily deprecate the actor when you do.

Architecture decisions I'd make again

If I had to rebuild from scratch tomorrow:

Cookie reuse with explicit refresh action — better than transparent re-auth. Users want to control when Playwright runs (it's the expensive call).
Action-based API instead of REST-style endpoints — posts:create reads better than POST /posts when you're building tool-use schemas for LLMs.
Structured error payloads with hint field — saved me from writing exhaustive error docs. The hint tells the user (or LLM agent) exactly what to do next.
Markdown → TipTap converter as a separate exported function — testable, reusable, and the most common request from users.
Never throw, always push — every error becomes a success: false dataset item. Apify runs never exit_fail. Workflows can branch on errorCategory without try/catch.

The one I'd change: I'd start with TypeScript strict mode from day 1. I retrofitted it after the library was already large and that was painful.

What's next

On the roadmap:

Events (list/create/RSVP) — endpoints discovered but not yet stable
Analytics (engagement, revenue, member growth) — currently returns empty pageProps, likely needs paid Skool plans
Chat / DMs — would require a different auth flow
Search — likely Elasticsearch-backed, endpoint TBD
"Send email to all members" toggle on posts:create — discovered the field, needs validation in test community
Webhooks — Skool doesn't expose them yet, would need polling fallback

If any of these are blocking you, open an issue at github.com/ctala/skool-api-docs — prioritized by demand.

Skool API FAQ — common questions

Does Skool have a public API?

No. Skool does not provide a public API. The endpoints used by the Skool web app are not documented or supported for external use. This actor and library reverse-engineer those endpoints and expose them as a clean, AI-friendly Skool API.

Is reverse engineering the Skool API legal?

Reverse engineering for interoperability with software you legitimately use is broadly accepted in most jurisdictions (US DMCA section 1201(f), EU Software Directive 2009/24/EC). I only use it against communities where I am an admin or have explicit permission. This is the same legal framing under which thousands of third-party Twitter/X clients, scraping libraries, and platform automation tools operate.

How do I authenticate with the Skool API?

Two options: (1) Email + password every call (uses Playwright, slower at ~10s, simpler), or (2) Cookie reuse — run auth:login once, save the returned cookies string, pass in subsequent calls for ~2s response time. Cookies last ~3.5 days before the AWS WAF token rotates. See the authentication section above.

What's the rate limit of the Skool API?

Skool doesn't publish official rate limits. Empirically: ~60 reads/minute and ~20-30 writes/minute work without 429 errors. The library handles automatic retry on transient 429s with exponential backoff. For batch operations (e.g. approving 100 pending members), the actor paces requests automatically.

Can I use the Skool API with n8n?

Yes. The actor is HTTP-callable from any platform with HTTP nodes — n8n, Make.com, Zapier, Pipedream, custom backends. There's a free n8n template showing the full auto-approve workflow.

How is this different from third-party Skool API services?

Three differences. Coverage: 33 actions including full classroom, file uploads, and Auto DM — most third-party services are read-only. Pricing: pay-per-event ($0.005-$0.05 per call) instead of fixed monthly subscription — cheaper for low-to-medium usage. AI agent design: action-based API with structured error hints, optimized for LLM tool use.

Can I publish Skool courses programmatically?

Yes. The classroom:* actions create courses, folders, and pages. The classroom:setBody action accepts markdown and converts to Skool's internal TipTap JSON format. You can publish a complete course from .md files in a Git repo via CI.

How many Skool comments can I retrieve from a thread?

Skool's REST endpoint for comments caps at ~35 per thread. For threads with hundreds of comments (welcome posts, AMAs), the posts:getCommentsFull action uses Playwright to scroll the page and extract every comment. $0.05 per invocation but bypasses the cap entirely. Critical for community audits where you need to verify every member's introduction got a reply.

What happens if Skool changes their API?

The skool-js library is actively maintained. When Skool deploys a new version (typically weekly), the buildId changes — the actor handles this automatically by refreshing from the homepage. WAF token expiration is handled (auto-retry with re-auth). Breaking changes are documented in the CHANGELOG of the docs repo.

Can I expose this Skool API as an MCP server for Claude / Cursor?

Yes. Apify exposes any public actor via https://mcp.apify.com?tools=cristiantala/skool-all-in-one-api. Configure once in your MCP client (Claude Desktop, Cursor, Cline), and the model sees all 33 Skool API actions as discoverable tools. Same pay-per-event billing applies.

Try it

Actor: apify.com/cristiantala/skool-all-in-one-api
Docs + recipes (open, MIT): github.com/ctala/skool-api-docs
n8n template (free): Auto-approve members with GPT-4o

If you're operating a Skool community at any scale and this would save you time — try the actor, leave feedback in the Apify Store or open an issue in the docs repo. The pay-per-event pricing means you only pay when it's actually saving you work.

If this resonated with you and you're building in public around community automation, AI agents, or Skool tooling, I'd love to hear about it. I'm building this stuff in the open at cristiantala.com.

— Cristian Tala

Cómo crear una landing page gratis para validar tu idea (con video tutorial y casos reales)

Cristian Tala — Mon, 11 May 2026 20:00:04 +0000

Si estás validando una idea de negocio, **crear una landing page gratis* es la diferencia entre validar en horas o gastarte $50-100/mes en herramientas que no necesitas todavía. Acá está el stack completo que uso hoy en producción —incluyendo el repo público que puedes clonar—, video tutorial paso a paso, y los 3 niveles de evolución según en qué fase esté tu proyecto.*

Por qué la mayoría de emprendedores paga de más en la fase de validación

Lo cuento desde mi propia experiencia: durante años yo pagaba $99/mes en un SaaS de landing pages optimizado para performance. Bien armado, sin queja del producto. Pero cada mes el cargo aparecía y empezaba a doler — porque me daba cuenta de que estaba pagando por algo que yo mismo podía hacer con un stack abierto, en menos tiempo del que pensaba, y sin sacrificar la performance que era lo que me había llevado al SaaS en primer lugar.

Cuando hice el switch al stack que comparto en este post (HTML estático generado con IA + GitHub Pages, después Astro + Cloudflare Pages para los proyectos serios), mi factura mensual de landing tools pasó de $99 a $0. Tiempo invertido en el switch: un fin de semana. Performance final: igual o mejor.

Hay un patrón que veo todas las semanas en la comunidad: alguien tiene una idea, decide «validarla en serio», y antes de saber si la idea funciona ya está pagando $200 al mes en herramientas. Carrd $19, Framer $20, Webflow $29, un dominio en GoDaddy con add-ons innecesarios, Mailchimp $30, Hotjar $40, y así.

Resultado típico: gasta $1,000-2,000 en los primeros tres meses y la idea ni siquiera estaba validada.

Soy fiel creyente de contratar servicios. Cuando ya tienes tracción real, pagar por un stack profesional acelera todo. Pero soy fiel creyente también de no gastar dinero para validar ideas. En fase de validación, lo que necesitas es: una página que comunique tu propuesta, capture interés, y mida si la gente reacciona. Punto. Eso se puede hacer con costo prácticamente cero.

La razón por la que la mayoría igual paga $20-99/mes en SaaS de landing pages es porque nadie les contó la alternativa.

La filosofía: ser rata para validar, gastar bien cuando ya factures

El frame mental que uso: en cada fase del journey, el founder pregunta dos cosas distintas.

Fase validación: ¿hay demanda real? ¿alguien pagaría por esto? Lo que importa es velocidad de iteración y costo cercano a cero.
Fase tracción: ¿cómo escalo lo que ya funciona? Acá sí pagas por herramientas que te ahorran tiempo y dan calidad consistente.

Mezclar las dos fases es el error más caro de bootstrapped founders. Pagás por SaaS profesionales antes de validar y, cuando la idea no resulta, sentís que «ya invertiste demasiado para abandonar». Sunk cost fallacy 101.

Los 3 niveles del stack según fase del proyecto

Cuando alguien me pregunta «qué uso para mis landings», la respuesta cambia según la fase. Estos son los 3 niveles que recomiendo —y que uso yo mismo en distintos proyectos hoy mismo—:

Nivel 1 — Validar rápido (HTML + IA + GitHub Pages)

Para cuando tienes una idea cruda y quieres saber si alguien levanta la mano antes de invertir más tiempo o dinero.

Stack: prompt a Gemini/Claude/ChatGPT → te devuelve un único index.html estático → subes a un repo público de GitHub → activas GitHub Pages → SSL automático → opcionalmente conectas un dominio personalizado vía Cloudflare DNS.
Tiempo: 18-30 minutos para landing + dominio personalizado.
Costo: $0 si usas el subdominio usuario.github.io/repo, o ~$10/año si compras un dominio.
Cuándo usarlo: validación cero-a-uno, MVP de marketing, lead magnet rápido, landing para un experimento de paid ads chico.

Este es el nivel que cubro en el video tutorial más abajo.

Nivel 2 — Landing pulida (Astro + GitHub Pages o Cloudflare Pages)

Para cuando la idea validó, quieres algo con SEO técnico serio y la landing va a evolucionar (agregar testimonios, casos, secciones nuevas).

Stack: Astro como framework + GitHub Pages o Cloudflare Pages como hosting.
Por qué Astro: genera HTML estático en build time, zero JS cliente innecesario, performance brutal (LCP

«Necesito el HTML completo de una landing page para validar una idea de negocio. La idea es: [DESCRIBÍ EN 2-3 FRASES]. Audiencia objetivo: [QUIÉN]. La landing debe incluir: hero con CTA principal, 3 secciones de beneficios, formulario de captura de email, footer simple. Estilo: moderno, minimalista, mobile-first. Devolveme un único archivo index.html con todo embedded: HTML, CSS y JS. Sin frameworks pesados (nada de React, solo HTML estático con JS vanilla). Optimizado para cargar en menos de 200ms.»

Lo importante: pídele HTML único y estático. Si la IA te devuelve un proyecto con npm, package.json y carpetas, dile que NO, quieres un solo index.html con todo incluido. Eso es lo que GitHub Pages puede servir directo.

Tip: si después de generar quieres ajustes, pégale un screenshot del resultado y dile «esta parte de acá cambia esto». Funciona mucho mejor que describir con palabras.

Paso 2: Crear repo público en GitHub (3 min)

Crear cuenta en github.com si no tienes
New repository → nombre tipo landing-mi-idea → público → Create
Click en «uploading an existing file» o «Add file → Create new file»
Nombre del archivo: index.html
Pegar el HTML que te dio la IA
Commit

Paso 3: Activar GitHub Pages (2 min)

En el repo, ir a Settings → Pages (sidebar izquierdo)
En «Source», elegir branch main y carpeta / (root)
Save
Esperar 1-2 minutos
URL queda activa en: https://tuusuario.github.io/landing-mi-idea/

Ya tienes landing online, gratis, con SSL automático.

Paso 4 (opcional pero recomendado): Conectar dominio personalizado vía Cloudflare (5 min)

Esto agrega 5 minutos pero da credibilidad real (URL profesional vs usuario.github.io/repo).

Si todavía no tienes un dominio, cómpralo (en Cloudflare Registrar son de los más baratos sin upsells: $9-12/año típico)
En tu DNS de Cloudflare, crear un CNAME record: nombre validar (o lo que quieras como subdominio) → destino tuusuario.github.io
En GitHub, Settings → Pages → Custom domain: pegar validar.tudominio.com
Esperar 5-15 minutos a que se genere el certificado SSL automáticamente

Ya tienes landing con dominio personalizado, SSL, gratis. Total invertido: ~$10/año del dominio.

Video tutorial paso a paso (Nivel 1 en vivo)

Acá te dejo el tutorial completo en vivo donde lo hicimos con Rodrigo, levantando una landing real (bananas.cristiantala.com) en 18 minutos. Verlo te ahorra mucho del trial-and-error del primer intento:

Casos reales en producción que puedes inspeccionar

Acá están los 3 sitios que opero hoy con este stack —en distintos niveles— por si quieres ver qué se puede hacer:

Caso 1 — `lp.cristiantala.com` (Nivel 2)

lp.cristiantala.com es el dominio donde hosteo todas mis landings de marketing: lead magnets, lanzamientos, cheatsheets descargables. Stack: Astro + Cloudflare Pages.

Ejemplo concreto: lp.cristiantala.com/linkedin-cheatsheets/ es la landing del cheatsheet del benchmark IA mensual que distribuyo. Performance LCP SEO > mantenibilidad > diseño, en ese orden) y usarlo como template para tu propio sitio agéntico.

Lo que vale la pena copiar de ese repo:

CLAUDE.md: cómo definir reglas duras de proyecto que el agente respeta
.claude/agents/: cómo modelar agentes custom para tareas repetibles
scripts/indexnow.sh: cómo notificar a buscadores cuando publicas contenido nuevo (clave para indexación rápida)
scripts/validate-build.sh: validar antes de cada deploy

Caso 3 — Tu primera landing (Nivel 1)

Esta es la que vas a hacer si sigues el tutorial del video. Empieza simple, valida rápido, después escala si la idea funciona.

Lo que SÍ necesita una landing de validación (no negociable)

Una landing técnicamente perfecta pero que no captura datos no sirve para validar. Estos son los 4 elementos no negociables:

1. CTA único y claro

Una sola acción que el visitante debe hacer. Punto. No «compra Y suscribite Y compartí Y miranos en Instagram». Una acción.

Para validación, el CTA típico es: capturar email para waitlist, o pre-orden con pago real (más fuerte como señal).

2. Captura de email funcional

Conectar un formulario que efectivamente guarde el email en algún lado. Opciones gratis: Listmonk self-hosted, Tally + Google Sheets, ConvertKit free tier (hasta 1,000 subs), Brevo free tier (hasta 300 emails/día).

El que uso yo: Listmonk self-hosted. Costo cero, control total. Si recién empiezas y no quieres tocar servidores: Tally + Google Sheets es lo más simple.

3. Tracking básico

Saber cuántos visitantes recibís + dónde están + qué porcentaje convierte. Opciones gratis:

Cloudflare Web Analytics (gratis si ya estás en Cloudflare, lo más fácil)
Google Analytics 4 (gratis, completo pero pesado en privacy)
Plausible (gratis self-hosted, simple y privacy-friendly)

Sin tracking no estás validando, estás adivinando.

4. Meta tags básicos para SEO/social

Cuando alguien comparta tu landing en LinkedIn / WhatsApp / Twitter, quieres que se vea bien (Open Graph). Mínimo:

<title> con la propuesta principal
<meta description> clara y atractiva
og:image con una imagen (1200×630 recomendado)
og:title y og:description para social shares

Pedile esto a la IA en el prompt original y te lo deja listo.

Las 3 métricas que dicen «sí valida» vs «no valida»

Después de 1-2 semanas con la landing live y tráfico inicial (mín 100-200 visitantes), mira:

Métrica 1: Conversion rate de visitante a email

Benchmark realista:

5%: señal fuerte

Métrica 2: Calidad de los emails capturados

¿Son personas reales con perfil de tu cliente target? Si capturas 200 emails pero el 80% son founders mirando «cómo lo hizo este» en vez de tu cliente target, no validaste demanda real.

Métrica 3: Pre-órdenes o «yo pago ya»

La más fuerte. Si en el CTA pedís pre-pago o señal con pago, cada conversión vale 10× una captura de email. Conversion rate baja a 0.5-2%, pero cada uno es señal sólida.

Los 3 errores más comunes que veo en landings de validación

Tráfico cero con expectativa de validar. La landing perfecta sin tráfico no valida nada. Mínimo: $50-100 en Twitter/LinkedIn ads o tráfico orgánico de tu red, para tener 100-200 visitantes mínimo antes de sacar conclusiones.
CTA confuso o múltiple. «Suscríbete o agendá demo o miranos en redes» mata el conversion rate. Una acción.
No iterar. Si después de 200 visitantes tienes 1% conversion, no esperes a 1000 visitantes para cambiar. Iterá hero, copy, propuesta. La landing es un experimento, no un monumento.

Cuándo subir de Nivel 1 a Nivel 2 o 3

No subas de nivel antes de tiempo. Las señales claras para graduar:

De Nivel 1 a Nivel 2 (HTML simple → Astro):

La idea ya validó (>3% conversion sostenido)
Vas a invertir tiempo en hacer la landing «definitiva»
Necesitás múltiples páginas (about, pricing, casos, blog)
SEO empieza a importarte como canal de adquisición

De Nivel 2 a Nivel 3 (Astro manual → Astro agéntico):

Publicás contenido recurrentemente (semanal, quincenal)
Estás copiando-pegando setups entre páginas
El 70% del trabajo de «agregar contenido» es repetitivo
Querés que un agente se encargue de la metadata SEO y validaciones

Si todavía no validaste la idea, mantente en Nivel 1. Subir de nivel antes es over-engineering y consume tiempo que necesitas para hablar con tus primeros clientes.

¿Y ahora qué?

Si seguiste los pasos del Nivel 1, ya tienes tu primera landing online por $0 (o ~$10/año si conectaste un dominio). Si quieres ver cómo se ve esto cuando escala, te dejé los 2 sitios reales arriba —incluyendo el repo público de ELHDA que puedes clonar—.

El siguiente paso es traerle tráfico real y medir. Eso es la parte que requiere más arte que técnica.

Dentro de Cágala, Aprende, Repite tenemos founders compartiendo casos reales de validación: landings que funcionaron, landings que fallaron y qué iteraciones llevaron al «sí valida». Si estás en fase de validación, esa data te ahorra meses de trial-and-error solo.

Entrás gratis, descargás el template HTML como recurso de bienvenida, y si te suma el resto te quedás.

— Cristian

Preguntas frecuentes

¿Cuánto cuesta crear una landing page gratis con GitHub Pages?

Cero pesos si usas un subdominio de GitHub (tuusuario.github.io/turepo). Si conectas un dominio personalizado, solo pagas el dominio (típico $9-12/año en Cloudflare Registrar). El hosting + SSL + ancho de banda son gratis. Para sitios con tráfico moderado (decenas de miles de visitas/mes) sigue siendo gratis.

¿Astro o HTML simple para una landing?

Depende de la fase:

HTML simple: validación cero-a-uno. Una sola página, copy estático. 18 min y listo.
Astro: post-validación o sitios que evolucionan. Mejor performance, mejor SEO, más mantenible si vas a agregar páginas. Requiere 2-4h de setup inicial.

Si recién empiezas: HTML simple. Si ya validaste o el sitio va a crecer: Astro.

¿GitHub Pages o Cloudflare Pages: cuál usar?

Para empezar y validar: GitHub Pages. Es más simple de configurar, todo en una plataforma.

Para producción seria, especialmente con Astro: Cloudflare Pages. Performance superior (CDN global más rápido), mejor analytics nativo, integración directa con DNS Cloudflare. Lo que uso yo en lp.cristiantala.com y eslahoradeaprender.com.

¿Necesito saber programar para crear una landing con IA + GitHub Pages?

No para el Nivel 1. Pedile a Gemini, Claude o ChatGPT el HTML completo. Después es solo copy-paste a GitHub. Lo único técnico es activar Pages en Settings, que son 3 clicks. Si nunca tocaste GitHub, el primer intento te toma 30-45 min. El segundo, 10 min.

Para Nivel 2 (Astro) sí ayuda saber lo básico de cómo correr npm install y npm run build. Para Nivel 3 (agéntico) ayuda haber usado Claude Code antes.

¿Qué es un sistema «agéntico» para mantener un sitio?

Un sistema donde uno o más agentes IA (típicamente Claude Code con prompts custom) se encargan de tareas repetitivas: agregar contenido nuevo, generar metadata SEO, validar builds, notificar a buscadores. El humano define las reglas (en archivos como CLAUDE.md) y el agente las ejecuta.

Caso real público: github.com/ctala/landing-es-la-hora-de-aprender — el sitio del podcast Es La Hora de Aprender, donde agregar un episodio nuevo es 1 comando que el agente ejecuta de punta a punta.

¿Puedo conectar un dominio que ya tengo a GitHub Pages?

Sí. En tu DNS, agregas un CNAME que apunte a tuusuario.github.io, después en Settings → Pages → Custom Domain pones tu dominio. SSL automático. Demora 5-15 min en propagar. Funciona igual con Cloudflare DNS si tienes el dominio ahí.

¿Para qué NO sirve este stack (GitHub Pages / Astro)?

Para sitios con backend (procesar pagos directo, base de datos, autenticación de usuarios), e-commerce complejo, o aplicaciones SaaS. Para todo eso necesitas server real (Vercel, Railway, AWS, etc.). Para landing pages, blogs, sitios de podcast, sitios de producto estáticos, es ideal.

¿Qué herramientas uso para email capture y tracking?

Email capture: Listmonk (self-hosted, gratis), Tally + Google Sheets (sin backend), ConvertKit free tier (hasta 1,000 subs), Brevo free tier (300 emails/día).

Tracking: Cloudflare Web Analytics (gratis si estás en CF), Google Analytics 4 (gratis pero pesado), Plausible (privacy-friendly).

The post Cómo crear una landing page gratis para validar tu idea (con video tutorial y casos reales) appeared first on Cristian Tala Sánchez.

Este articulo fue publicado originalmente en cristiantala.com. Si te interesa emprendimiento, IA y automatizacion, unite gratis a la comunidad Cagala, Aprende, Repite.

El verdadero gap de la IA en LATAM no es la tecnología

Cristian Tala — Mon, 11 May 2026 19:00:04 +0000

67% de las grandes empresas de LATAM tienen al menos un proyecto de IA en producción. Solo 23% reporta impacto medible en métricas de negocio.

Esa brecha de 44 puntos es el verdadero estado de la IA empresarial en la región. No es un problema de tecnología — el mercado tiene Claude, GPT, Gemini, MiniMax, modelos open source corriendo en cualquier laptop decente. Es un problema de ejecución, calidad de datos y decisiones que se toman antes de elegir un modelo.

El número que nadie quiere mirar

Tres datos definen el momento:

El primer número se lee bonito en conferencias. El segundo es el que importa. El tercero es la señal de hacia dónde va la siguiente ola.

Brasil concentra la inversión empresarial más alta: las grandes corporaciones gastan en promedio R$77.7M anuales en AI, con un ROI actual del 16% que esperan llevar al 31% para 2027 (SAP + Oxford Economics). En Nubank el AI ya está dentro del credit underwriting; PicPay, PagSeguro y Creditas tienen agentes de fraude y compliance corriendo todos los días. En fintech, el ROI promedio del primer año en sistemas de credit scoring y fraud detection con AI es de 3.2×. Eso es producción real, no slide deck.

Pero esos casos son la minoría. La mayoría sigue atrapada en pilotos.

El gap no es la tecnología — es la ejecución

Cuando le pregunto a founders y CTOs por qué su piloto de IA no se escaló, las respuestas se repiten:

«Los datos están sucios y fragmentados.»
«No teníamos a alguien que entendiera cuándo el modelo se equivocaba.»
«El costo de mantener el agente subió cuando el proveedor cambió las reglas.»
«Empezamos con OpenAI, después Claude, después no sabíamos cuál era el dueño del workflow.»

Ninguna de esas respuestas habla del modelo. Hablan de gobernanza del flujo.

Tres cosas determinan si un proyecto de IA llega a producción con impacto medible:

Calidad y disponibilidad del dato. Sin esto, ningún modelo te salva. El 80% del costo de un proyecto productivo es preparar el dato.
Métrica clara que defienda el caso de uso. Si no podés decir qué KPI mueve el agente, no debería estar en el P&L.
Independencia del proveedor. El día que el proveedor te cambia el precio o saca una feature del plan, tu unit economics se rompe — y eso no es hipotético.

El último punto es donde el 38% que está migrando a open source está jugando distinto.

Por qué 38% ya está en open source

En abril 2026 Anthropic sacó silenciosamente a Claude Code del plan Pro de $20. Lo restauraron 24 horas después por presión pública, pero el experimento existió: la pricing page completa decía X, no un test del 2% como después intentaron explicar. Amol Avasare (Head of Growth) tuvo que admitirlo en X.

Ese día quedó claro algo que las empresas con stack robusto ya sabían: un proveedor, un punto de falla. Y no importa que tu suscripción cueste $20 o $100 — el riesgo no es el costo, es que las reglas pueden cambiar un martes cualquiera.

El 38% que migró parcial o totalmente a AI open source no es por ideología — es por unit economics. Modelos como Llama, Qwen, DeepSeek, Mistral corren localmente, no dependen de un dashboard externo, y la cuota la define tu hardware, no el contrato.

Mi setup personal lo refleja: corro MiniMax M2.7 highspeed ($40/mes, cuota infinita en uso real) en paralelo a Claude Code, con Ollama Cloud para producción y una NVIDIA DGX Spark local para correr Qwen 3.6 cuando la privacidad o el costo es crítico. No es por hobby — es porque el día que cualquiera de esos proveedores mueva el queso, el resto del stack sigue funcionando.

Cómo se ve un proyecto que sí llega a producción

Hay un patrón común en los casos que llegan al 23% con impacto medible:

Vertical bien definido. No «vamos a usar IA»; sí «vamos a automatizar el scoring de microcréditos con datos transaccionales + telco». Ámbito acotado, métrica clara.
Data pipeline antes que modelo. Limpieza, enriquecimiento, governance. El modelo viene después.
Multi-modelo desde el día 1. Un primario, un secundario, un fallback open source. Cero proveedor exclusivo.
Métrica de negocio, no técnica. No «accuracy del 92%»; sí «reducción de fraude en X% sostenida tres meses».
Humano en el loop al principio. Aprobación, corrección, retroalimentación que mejora el agente.
Costos medidos por unidad de negocio. No «$200/mes en API»; sí «$0.03 por transacción procesada».

JPMorgan (que no es LATAM pero es el benchmark que cualquier banco regional compara) lo hace exactamente así: $17.5B de presupuesto tecnológico anual, 450+ casos de uso en producción, 200,000 empleados usando su LLM Suite a diario. La meta declarada es $2.5B de valor anual de AI. Nadie llega ahí «probando OpenAI».

Lo que viene en LATAM Q3-Q4 2026

Tres movimientos a observar:

Verticales reguladas migran a open source. Fintech y healthcare van a forzar setups híbridos por compliance — open source local + APIs externas solo donde la regulación lo permite.
El presupuesto AI deja de ser «proyecto» y pasa a «capacidad continua». Las empresas que lo traten como CapEx (gasto único) se quedarán atrás. Las que lo traten como OpEx con métricas mensuales van a capitalizar.
El gap de talento se cierra con templates probados. No con frameworks teóricos — con repositorios open source que muestren el código real de cómo un agente productivo está armado.

El 23% que mide impacto va a crecer. La pregunta es si vas a ser parte de ese 23% o seguir en el 44% que adopta sin medir.

The post El verdadero gap de la IA en LATAM no es la tecnología appeared first on Cristian Tala Sánchez.

Este articulo fue publicado originalmente en cristiantala.com. Si te interesa emprendimiento, IA y automatizacion, unite gratis a la comunidad Cagala, Aprende, Repite.

Cómo construí una comunidad de founders sin sentirme un estafador

Cristian Tala — Mon, 11 May 2026 16:00:04 +0000

Construir una **comunidad para emprendedores con IA* y monetizarla siempre me generó la misma tensión: cobrarle a quien recién empieza se siente horrible, y cobrarle al que ya puede pagar no me molesta. Después de cinco años, encontré el sistema que resuelve esa tensión. Hoy clarifiqué cómo funciona, para mí y para todos los que están dentro.*

El problema que arrastré 5 años: ¿cómo cobrar una mentoría sin sentirme impostor?

Llevo cinco años pensando cómo apoyar a otros founders y emprendedores sin sentirme un estafador.

No es una frase de marketing. Es literal. Cada vez que alguien me preguntaba cuánto te cobro por una sesión, sentía un nudo. No por el monto. Por la pregunta de fondo: ¿le estoy cobrando a alguien que todavía no puede pagarme, o a alguien que ya puede y para quien esto no significa nada?

Cobrarle a quien todavía no puede pagarte se siente horrible. A quien ya puede pagar, nunca me molestó. El problema es que la mayoría de los formatos clásicos —mentorías 1:1, cursos cerrados con pricing único, programas pagados— no distinguen entre los dos. Le cobran lo mismo al founder que ya facturó $1M ARR que al emprendedor que está validando una idea en una hoja de Notion.

Encontrar ese equilibrio me tomó años. Hoy lo encontré.

¿Comunidad pagada o gratuita? El reset que cambió todo

Hace cuatro o cinco meses dejé de pensar en CAR (Cágala, Aprende, Repite) como «comunidad pagada» o «comunidad gratuita». Esa dicotomía es justo el problema.

Empecé a pensarla como una comunidad para emprendedores con un sistema de progresión. Como un videojuego, pero para emprendimiento.

La idea es vieja —el modelo freemium con gamification existe hace años en Skool, Discord, Reddit—. Lo nuevo, al menos para mí, fue darme cuenta de que el sistema de progresión podía resolver exactamente esa tensión que arrastraba:

Los que recién empiezan, entran gratis y desbloquean conocimiento aportando —comentando, posteando, ayudando a otros, participando en eventos—. No pagan nada.
Los que ya pueden pagar y quieren ir más profundo —tiempo real conmigo, eventos en vivo, asesorías grabadas, biblioteca premium— pagan. Y ese pago no compra el conocimiento (el conocimiento ya está adentro). Compra mi tiempo y los recursos curados que uso a diario para correr mis empresas.

Es la misma comunidad. Es el mismo conocimiento. Lo que cambia es la velocidad y la profundidad del acceso, según en qué punto del journey estés.

Por qué una comunidad para emprendedores con IA tiene sentido en 2026

Hay una segunda razón por la que recién ahora se materializó este modelo: la forma de emprender ya cambió.

Emprender en 2026 sin apalancar IA es como hacerlo en 2010 sin internet.

No es una opinión. Es una realidad operativa que vivo cada día corriendo Ecosistema Startup (200K visitas/mes con un equipo de 1 persona + IA) y la comunidad de CAR.

Hoy un founder puede:

Validar una landing en 2 horas
Automatizar customer support con un agente IA en producción
Producir contenido sin contratar a nadie
Operar una empresa con un equipo mínimo sin sacrificar la calidad de lo que sale

La pregunta ya no es si se usa IA. Es cómo. Y la respuesta no la encuentras leyendo papers ni en cursos de gurús que nunca operaron una empresa. La encuentras en una comunidad donde otros founders están aplicando esto en producción, compartiendo qué funciona y qué no, sin filtro.

El stack que uso para operar Ecosistema Startup y la comunidad CAR no es secreto: n8n para automatizaciones, agentes IA con Claude/Qwen para contenido y soporte, OpenClaw como mano derecha, NocoDB como fuente de verdad. Esto es lo que enseño dentro de la comunidad — no como teoría, como playbooks que uso hoy.

¿Por qué Skool y no Circle, Teachable, Hotmart o Discord?

Antes de quedarme con Skool probé varias plataformas. Vale la pena contar qué pasó con cada una, porque la pregunta «qué plataforma uso para mi comunidad» la tengo seguido en el WhatsApp y la respuesta no es obvia.

Teachable. Es buenísimo como LMS para vender cursos, pero no es una comunidad. Es un repositorio de videos con foro adjunto. Si tu producto es «el curso», funciona. Si tu producto es «la gente que entra al curso», no. Para CAR necesitaba la comunidad como protagonista, no el curso.

Hotmart. Plataforma de pago + cursos muy fuerte en LATAM, pero mi experiencia fue paupérrima — UI sobrecargada, soporte mediocre, fees altos, y la comunidad como tal es accesoria. El golpe final fue que me debían dinero y me aburrí de pedirlo. Si vas a confiar en una plataforma para manejar tu monetización, lo mínimo no negociable es que te paguen lo que generaste, cuando corresponde. Funciona si tu modelo es vender infoproductos individuales con afiliados y tienes paciencia infinita para reclamos. No funciona si tu modelo es comunidad recurrente.

Circle. Acá la cosa fue interesante. Circle me gustó genuinamente — UI limpia, features potentes (DMs, eventos, cursos integrados, segmentación), branding propio. Pero las personas no interactuaban como deberían. La fricción del onboarding (cuenta nueva, app aparte, no hay efecto red) hacía que entraran, miraran y se fueran. El engagement nunca despegó. Para alguien que recién está construyendo audiencia, ese costo de adopción mata el sistema.

Discord. Excelente para chat en tiempo real, voice channels y comunidades de gaming/dev. Pero para una comunidad de emprendedores con sistema de progresión, falla en tres cosas: 1) la gamification nativa es básica (sin niveles, sin desbloqueo de contenido), 2) los cursos hay que hostearlos afuera y romper el flujo, 3) el ruido del chat constante mata el deep work.

Skool gana por dos razones contraintuitivas. Una es que tiene pocas funcionalidades —comparado con Circle es casi austero— y eso es exactamente lo que la hace simple para gente no técnica. La curva de aprendizaje es cero: feed, cursos, eventos, classroom. Punto. Sin paneles avanzados, sin segmentaciones complicadas, sin features que nadie usa. La otra es network effect: hay buena probabilidad de que la persona que invitás a CAR ya tenga cuenta en Skool porque pertenece a otra comunidad (ej. SchoolOfMentors, Imperio, Agentic Architects). Eso reduce la fricción del onboarding a casi cero. Y la gamificación nativa (niveles, puntos, leaderboard que premian aportar) más el transaction fee 2.9% vs 14% Patreon, terminan de cerrar la decisión.

En resumen: si tu modelo es freemium con progresión por niveles y cursos desbloqueables, Skool gana. Si tu valor principal es chat en vivo permanente, Discord. Si quieres customización máxima y tu audiencia ya está adentro de tu marca, Circle. Si tu producto es el curso individual y no la comunidad, Teachable.

Cómo funciona el modelo freemium con gamification en mi comunidad de Skool

Para que no quede en abstracto, así funciona hoy la comunidad de CAR:

Si entras gratis, tienes acceso al feed, a la mayoría de eventos comunitarios y a los cursos del journey de founder (validación de ideas, pricing, marca personal, n8n, agentes IA, fundraising, postular a fondos públicos). Cada curso se desbloquea al subir de nivel aportando a la comunidad. Si comentas, posteas, ayudas a otros — desbloqueas.

Si quieres ir más profundo, hay dos tiers de pago: Premium y VIP.

Premium te da acceso inmediato a todos los cursos sin esperar niveles, el Cofre del Pirata completo (la biblioteca con prompts, workflows n8n, AGENTS.md templates, plantillas, cheatsheets y playbooks que uso a diario para correr mis empresas), y eventos quincenales en vivo.
VIP suma lo que Premium no incluye: WhatsApp directo conmigo, Cafecitos mensuales en grupo cerrado de 8 founders, LinkedIn Posting Party, Roast My Pitch, y acceso a asesorías grabadas con casos reales.

El pricing actual lo encuentras en la página de la comunidad —cambia cuando se justifica, así que no lo cierro acá—. Cuando lanzamos un tier nuevo o subimos el pricing, los founders que ya están adentro mantienen el suyo. No buscamos retroactivos.

Por qué publico cómo construir una comunidad de founders hispanohablantes

Hoy clarifiqué cómo funciona el sistema —para mí mismo, para los miembros que llevan tiempo y para los que vienen entrando—. Cerramos meses de trabajo aclarando reglas, curando contenido, construyendo el Cofre del Pirata (que pasó de 35 piezas a 69 en dos semanas), y validando el modelo con los miembros activos.

Ya somos más de 500 founders hispanohablantes operando con IA. Comunidad pequeña, con calidad arriba —o al menos eso intentamos—. La forma de crecer bien para este tipo de proyecto no es por anuncios pagados. Es de boca en boca, como cuando las comunidades cierran brechas del emprendimiento en LATAM. Founder a founder. Emprendedor a emprendedor.

Si esto te suma, entrá gratis a CAR acá. Si conoces a otros founders o emprendedores hispanohablantes que están emprendiendo con IA, mándales el link. Eso me ayuda más que cualquier anuncio.

Preguntas frecuentes sobre comunidades para emprendedores con IA

¿Qué es Cágala, Aprende, Repite (CAR)?

Es una comunidad para emprendedores con IA hispanohablantes que operan o quieren operar sus empresas apalancando inteligencia artificial. Funciona sobre Skool con un sistema de progresión: entras gratis y desbloqueas cursos aportando a la comunidad (no pagando).

¿Cómo funciona el sistema gratuito?

Comentas, posteas o ayudas a otros en el feed. Acumulas puntos. Al subir de nivel se desbloquean los cursos del journey de founder (validación de ideas, pricing, n8n, agentes IA, fundraising, postular a fondos públicos). Sin tarjeta, sin trial trampa, sin paywall escondido.

¿Hay tiers de pago?

Sí, dos: Premium y VIP. No son para acceder al conocimiento (ese está disponible aportando). Son para acceso inmediato sin esperar niveles, recursos curados (el Cofre del Pirata) y tiempo real conmigo en eventos en vivo. El pricing actual está en la página de la comunidad —puede cambiar, y no quiero estar editando este post cada vez que lo movemos—.

¿En qué se diferencia VIP de Premium?

Premium te da acceso completo a cursos + Cofre del Pirata + eventos quincenales. VIP suma tiempo 1:1 y grupal: WhatsApp directo conmigo, Cafecitos mensuales en grupo cerrado de 8 founders, LinkedIn Posting Party, Roast My Pitch, y asesorías grabadas con casos reales. Es para founders que ya están operando y quieren tiempo real con un founder con exit.

¿Qué pasa si ya soy miembro pago?

Tu pricing original se mantiene. Cuando el pricing público sube, los que ya están adentro siguen con el suyo. No buscamos retroactivos. Si querés mantenerte al día con cómo evoluciona el sistema, podés suscribirte al newsletter Navegando Sin Un Mapa donde escribo cada lunes sobre cómo opero esto en vivo.

¿Qué es Skool y para qué sirve?

Skool es una plataforma fundada por Sam Ovens que combina foros, cursos, eventos en vivo y gamification en un solo lugar. Sirve para crear comunidades online monetizables con baja comisión por transacción (2.9% vs 14% Patreon). En español hay comunidades activas como CAR, Emprendedores.com, Líderes Skool y Valida Tu Startup.

¿Skool, Circle, Teachable o Discord: cuál elegir para una comunidad de emprendedores?

Depende del producto. Si tu modelo es freemium con progresión por niveles y cursos desbloqueables: Skool (gana por simplicidad + efecto red — la gente ya tiene cuenta). Si quieres customización máxima y branding propio: Circle (gran UI pero más fricción de adopción). Si tu producto es el curso individual y no la comunidad: Teachable. Si tu valor principal es chat en vivo permanente: Discord. Hotmart es mejor evitarlo para comunidad — funciona como marketplace de cursos individuales.

¿Cuánto cobrar por una mentoría sin sentirse impostor?

El framework que uso: no cobres por compartir conocimiento (eso está disponible aportando a la comunidad). Cobra por tu tiempo (sesiones 1:1, eventos en vivo) y por recursos curados (plantillas, workflows, playbooks). Si la mentoría es 1:1 y tu experiencia operacional es real, $100-300/hora es defendible. Si solo tienes teoría, no cobres todavía.

¿Cómo funciona el modelo freemium para una comunidad online?

El modelo freemium ofrece acceso básico gratuito y reserva funcionalidades avanzadas para usuarios pagos. En una comunidad funciona si: 1) el tier gratuito entrega valor real (no demo), 2) el tier pago compra algo que no escala (tiempo del founder, recursos curados), 3) la conversión es por afinidad cultural, no por paywall agresivo.

¿Por qué cobrarle a un emprendedor que recién empieza se siente mal?

Porque le estás pidiendo capital escaso a alguien que aún no facturó. La solución no es regalar todo (insostenible), es separar conocimiento (puede ser gratuito y desbloqueable por aporte) de tiempo del founder (cobrable sin culpa). Es el principio Cliefnotes-style: 80% del valor accesible gratis, 20% premium para quienes ya están operando.

¿Qué diferencia hay entre una comunidad para emprendedores y una comunidad para founders?

En español la línea es difusa: «emprendedor» abarca desde freelancer hasta CEO con ronda Series A. «Founder» suele acotarse a quien fundó una empresa con tracción o ambición de scaleup. Mi comunidad usa «founder hispanohablante» para señalar el perfil: gente que está operando un proyecto propio, no estudiando emprendimiento como hobby.

¿Se puede emprender en 2026 sin saber de IA?

Sí, pero competirías en desventaja. Emprender en 2026 sin apalancar IA es como hacerlo en 2010 sin internet — no imposible, pero el costo de oportunidad es alto. Un founder con IA puede validar landings en horas, automatizar soporte, producir contenido sin equipo y operar una empresa con un equipo mínimo. Los que no la apalancan terminan compitiendo contra equipos de 10 personas siendo 1.

¿Cómo elegir entre comunidad gratis o de pago al empezar a emprender?

Si estás validando idea: comunidad gratis con sistema de progresión (Skool, Reddit, Discord). Si ya facturas y quieres profundizar: comunidad de pago con tiempo real del founder + recursos curados. La señal de que es momento de pagar: ya tienes preguntas específicas de operación que no aparecen en buscador, y necesitas alguien con experiencia operacional real (no teoría).

P.D. — Si llegaste hasta acá y esto te resonó: el mejor regalo que me puedes hacer no es comprarme nada. Es compartir esta publicación —o el link a la comunidad— con algún founder o emprendedor hispanohablante que creas que le puede sumar. Eso es lo que mueve la aguja para un proyecto que no se construye con anuncios.

— Cristian

The post Cómo construí una comunidad de founders sin sentirme un estafador appeared first on Cristian Tala Sánchez.

Este articulo fue publicado originalmente en cristiantala.com. Si te interesa emprendimiento, IA y automatizacion, unite gratis a la comunidad Cagala, Aprende, Repite.

La guerra de IA se terminó. Y sí, alguien ganó — pero eso no es lo importante

Cristian Tala — Sat, 09 May 2026 15:00:04 +0000

Hace dos años, si me hubieran dicho que una empresa de 500 personas iba a valer $900 mil millones de dólares, me habría reído.

No porque sea imposible — en tech hemos visto valuaciones absurdas — sino porque esa empresa estaba detrás de OpenAI en casi todo: en usuarios, en brand, en ecosistema.

Hoy, Anthropic está cerrando una ronda a $900B. OpenAI está a $852B. Y lo que pasó en el medio es un caso de estudio en lo que realmente determina quién gana en tecnología cuando la infraestructura se commoditiza.

No es el que llega primero. No es el que tiene más dinero. Es el que resuelve un problema que el mercado necesita urgentemente — y lo hace mejor que nadie.

Pero antes de llegar a la conclusión, vamos a lo que realmente importa para ti que estás leyendo esto: qué diablos significa para tu próxima decisión.

La historia que nadie cuenta bien

Bloomberg, TechCrunch y The Next Web reportearon en abril-mayo 2026 que Anthropic está en conversaciones para levantar $40-50 mil millones a una valoración de $850-900 mil millones. Eso representa más del doble de su valoración de febrero 2026, cuando levantó $30 mil millones a $380B.

La ronda aún no está cerrada. Anthropic no ha commentado. Pero los números de revenue cuentan una historia que hace que esta valuación, aunque parezca loca, tenga sentido.

Anthropic llegó a $30 mil millones de ARR en abril de 2026, según Bloomberg via The Next Web. Eso es crecimiento de $1B en enero 2025 a $30B en 15 meses. El crecimiento más rápido en la historia de una empresa de tecnología en Estados Unidos.

No es un KPI inventado. Es revenue real de empresas reales pagando licencias empresariales de seis y siete dígitos anuales.

El «split»: cuando un mercado se divide en dos y no te avisan

Lo que está pasando ahora tiene nombre: el mercado de modelos de IA para empresas se está dividiendo en dos segmentos claros, y cada segmento tiene un ganador distinto.

Anthropic = coding + B2B workflows. OpenAI = consumer + search.

Los números cuentan la historia mejor que cualquier análisis:

Fuente: KuCoin News, Tech Insider, Michael Parekh/Substack

Claude Code generó $2.5 mil millones en ARR en solo 9 meses. Nueve meses. Eso es más de lo que muchas empresas de software generan en toda su existencia.

OpenAI, por su parte, tiene más del 80% de su revenue viene de suscripciones de consumidor (ChatGPT), con una tasa de conversión pagada de solo ~5%. Eso no es un modelo de negocio — es una apuesta por el consumidor que todavía no ha demostrado ser sostenible a escala enterprise.

El CFO de OpenAI, Sarah Friar, reportedly advirtió internamente que sin aceleración, OpenAI podría tener problemas para financiar sus futuros contratos de compute. Eso es una voz de alarma seria viniendo de alguien que debería estar vendiendo la historia opuesta.

La capa de infraestructura tiene 5 jugadores. No puedes ganarle a 5

Aquí es donde la cosa se pone incómoda para quienes piensan que pueden «competir en el layer de modelos.»

Miremos el mapa actual:

Cinco jugadores. Todos con acceso a capital prácticamente ilimitado. Todos con contratos de cloud que representan cientos de miles de millones en revenue comprometido. El capex combinado de hyperscalers en 2026 es de ~$650B, con 70-75% destinado explícitamente a infraestructura de AI.

No puedes ganar ahí. No porque no seas bueno — porque el capital requerido para jugar en ese nivel ya no tiene sentido para un startup. Estamos hablando de miles de millones en GPUs, energía, data centers, y talento que puede ir a cualquier lado.

Esto es lo que pasó con cloud: AWS, Azure y GCP commoditizaron la infraestructura. Lo que vino después fueron Salesforce, HubSpot, Workday. Aplicaciones sobre infraestructura.

La misma dinámica se está jugando ahora en AI. La diferencia es que el ciclo es 10x más rápido.

Lo que DeepSeek ya te estaba diciendo

Esto no debería ser una sorpresa para nadie que haya estado prestando atención.

A principios de 2025, DeepSeek demostró algo que muchos ignoraron: puedes tener modelos competitivos sin los cientos de miles de millones que OpenAI y Anthropic están quemando. El inference cost se derrumba. La capacidad de entrenar se distribuye.

Pero DeepSeek también mostró otra cosa: el infrastructure layer está saturado. Incluso con un modelo competitivo, la batalla por quién controla el acceso a compute y distribución es la que realmente importa.

Para founders en mercados emergentes — América Latina, África, Sudeste Asiático — el mensaje es claro:

No intentes ser el próximo OpenAI. No intentes ser el próximo Anthropic. Intenta ser el próximo Stripe sobre AWS.

Pago Fácil no compitió con Visa ni con Transbank. Construyó una capa encima que resolvió un problema que los demás no querían resolver: pagos online en Chile cuando nadie creía que era posible. Eso fue en 2011, con un plugin open source que 3,000 empresas usaban gratis antes de que tuviéramos nombre, web, o dashboard.

Hoy, con la capa de infraestructura de AI sellada por 5 jugadores que se están preparando para IPO, la oportunidad está exactamente en el mismo lugar: en la capa de aplicación, resolviendo problemas específicos por industria, por geografía, por tipo de usuario.

Qué significa esto para tu stack en 2026

Si eres developer o founder técnico:

Si construyes agentes de código o flujos enterprise → Anthropic (Claude) es tu base. 42-54% del mercado de code generation no es运气. Es adopción real por developers que se quedan.
Si vas a consumer apps, search, o asistentes personales → OpenAI sigue siendo el default. Brand awareness importa en ese segmento.
Si estás en LATAM, África, o mercados emergentes → La oportunidad es profunda, no en modelos, sino en workflows verticales que las empresas globales no van a construir para ti.

Si eres inversor:

La ronda de Anthropic a $900B con $30B ARR te da un 30x revenue. Eso es caro. Pero si Anthropic llega a $100B ARR en 3 años — plausible dado el momentum enterprise — estás ante un 3-4x desde el precio primario de IPO.
OpenAI perdiendo $14B en 2026 vs Anthropic siendo cash flow positivo en enterprise no es una comparación justa hoy, pero el mercado va a corregir eso cuando ambos sean públicos.

El timing importa

Según los reportes, Anthropic espera cerrar la ronda antes de fin de mayo 2026. OpenAI está planeando IPO para octubre 2026.

Esto significa que estamos en la última ventana para:

Invertir como ángel/VC en rounds primarios (si tienes acceso — y si no lo tienes, este es el momento de construir relaciones para el próximo ciclo)
Asegurar partnerships estratégicos antes de que sean corporaciones públicas con prioridades de investor relations sobre producto
Posicionarte en la capa de aplicación antes de que los fondos corporativos inunden el espacio con capital barato

Post-IPO, la dinámica cambia. Los fondos soberanos, los family offices masivos, y el capital institucional van a fluir hacia estos jugadores de forma diferente. La agilidad que existe hoy para builders individuales se va a reducir.

La pregunta que nadie hace

Todos están discutiendo si $900B es la valuación correcta para Anthropic. Si $30B ARR justifica $900B de precio. Si OpenAI va a sobrevivir la presión.

Pero la pregunta más interesante es otra:

¿Qué construyes sobre Anthropic y OpenAI que ellos nunca vão a construir?

Porque ellos no van a construir tu vertical. No van a entender tu mercado local. No van a tener tu data.

Y en technology, la data siempre gana.

Fuentes

¿Tienes dudas sobre cómo posicionarte en la capa de aplicación de AI? *Únete a mi comunidad de emprendedores en Cágala, Aprende, Repite** — ahí podemos ayudarte entre todos a pensar estas decisiones.*

The post La guerra de IA se terminó. Y sí, alguien ganó — pero eso no es lo importante appeared first on Cristian Tala Sánchez.

Este articulo fue publicado originalmente en cristiantala.com. Si te interesa emprendimiento, IA y automatizacion, unite gratis a la comunidad Cagala, Aprende, Repite.

DEV Community: Cristian Tala

The US is pushing the world toward Chinese AI (its own goal)

What exactly did the United States block?

The world runs to Chinese AI

And China stopped needing Nvidia

Why this is an own goal

What this means for you, founder

The day the best model and the best chip come from the same place

GLM 5.2 isn't free: not even my US$4,000 Spark can run it

Why does everyone say GLM 5.2 is free?

What's the best free AI? The question is wrong

What it really costs to run GLM 5.2

DeepSeek, Qwen, GLM: "free" is marketing

So what do I run locally? And for what

When does running a model locally actually make sense?

The final proof is in the OpenRouter ranking

Before you share the next "it's free"

How I Export 700+ Skool Members to CSV with One API Call (Email, Tier, LTV, Survey)

What you'll need

The one-liner that returns your full roster

Filter what you export

The data quality reality nobody mentions

What the export does NOT include

Pipe straight to your CRM

Gotchas I hit so you don't have to

Why this actor exists

How I Uploaded an 18-Course Classroom to Skool With One Script (and the Bug That Almost Killed My Paywall)

How I Uploaded an 18-Course Classroom to Skool With One Script (and the Bug That Almost Killed My Paywall)

What the directory looked like

Trap 1: Skool prefixes folders with "Section N:" — don't do it manually

Trap 2: classroom:updateCourse silently resets privacy to 0

Trap 3: Markdown converter quirks

Trap 4: Re-running creates a NEW course (course-create is not idempotent)

The actor calls (the actual flow)

Step 1: Upload the cover image

Step 2: Create the course

Step 3: For each module folder, create a section

Step 4: For each lesson markdown, create the page + set the body

One detail: delete the placeholder page

What this saved me

How to copy this for your community

What this unlocks

How I Publish Podcast Episodes to a Skool Classroom 100% Automatically

How I Publish Podcast Episodes to a Skool Classroom 100% Automatically

What the automation produces

The pipeline, end to end

Why Skool needed the API

The actor calls (the actual code)

Step 1: Build the lesson body in markdown

Step 2: Authenticate (once per 3.5 days)

Step 3: Create the lesson page

Step 4: Set the lesson body

Three gotchas that cost me time

1. YouTube embeds: thumbnail-only, no native player

2. YouTube ID regex: don't use \w+

3. Re-running the pipeline creates a NEW course

What this saves me per week

How to copy this

The Complete Skool API Guide (2026): Posts, Members, Classroom, and 100% Automations

The Complete Skool API Guide (2026): Posts, Members, Classroom, and 100% Automations

How Skool actually works under the hood

Authentication: cookies vs Playwright

The endpoint catalog (what you can actually do)

Posts

Members

Classroom (courses, folders, lessons)

Files

Groups

Events

System

Common gotchas (the stuff that bit me, so it doesn't bite you)

1. posts:create requires labelId if your community has categories

2. Top-level comments need parentId = rootId

3. posts:update body shape is flat, not wrapped

4. classroom:updateCourse silently resets privacy to 0

5. BUILDID_STALE 404s are usually transient

6. x402-payment-required ≠ payment problem

7. members:approve and members:reject need memberId, not id

How I use this in production

Get started

Trap 2: `classroom:updateCourse` silently resets `privacy` to 0

2. YouTube ID regex: don't use `\w+`

1. `posts:create` requires `labelId` if your community has categories

2. Top-level comments need `parentId = rootId`

3. `posts:update` body shape is flat, not wrapped

4. `classroom:updateCourse` silently resets `privacy` to 0

5. `BUILDID_STALE` 404s are usually transient

6. `x402-payment-required` ≠ payment problem

7. `members:approve` and `members:reject` need `memberId`, not `id`

Caso 1 — `lp.cristiantala.com` (Nivel 2)