DEV Community: Cristian Tala

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.

La dependencia perfecta: cuando tu proveedor de IA se cae y tú te quedas mirando

Cristian Tala — Sat, 02 May 2026 11:00:04 +0000

De humanos a IA, y de IA a nada

El 15 de abril de 2026 me desperté y no pude trabajar.

No fue un problema mío. No fue un problema de internet. Fue que Anthropic se cayó y yo —con mi plan Max a $100 dólares al mes, con Claude Code, con OpenClaw— estaba completamente paralizado.

Cinco veces en un mes. Cinco.

Después del tercer corte ya estaba frustrado. Después del cuarto ya estaba buscando alternativas. Y después del quinto entendí algo que llevaba meses evitándome: me había casado con un proveedor de IA.

Exactamente igual que cuando era founder y dependía de ese empleado «irremplazable» que tenía todo en la cabeza y podía irse mañana. O cuando dependía de ese integrador que era el único que entendía el sistema legacy. O cuando dependía de ese proveedor de cloud que sabías que era demasiado grande para caer — hasta que cayó.

El nombre del juego no cambió. Solo cambió el proveedor.

Los cinco casos que nadie quiere admitir

Bueno, no solo a mí me pasó. Esto está pasando a nivel enterprise, a nivel startup, a nivel gobierno. Y hay datos documentados.

1. Anthropic le cortó el acceso a Belo (fintech argentina)

En marzo 2026, Anthropic suspendió más de 60 cuentas de Belo —una fintech argentina de pagos— sin previo aviso. Todo su equipo de producto, parado. Durante 15 horas no pudieron acceder a sus prompts, a sus flujos de trabajo, a nada.

Belo había construido toda su operación interna encima de Claude. Mensajería, soporte, automatización. Todo dependía de una sola API key.

¿Qué pasó después? Después de muchas horas de soporte, de tickets, de pánico. Pero el daño ya estaba hecho: 15 horas de paralización total en una fintech que mueve dinero real.

Lección: Si tu lógica de negocio vive en un prompt, eres rehén del proveedor.

2. Sullivan & Cromwell: la firma legal que citaba casos que no existían

Sullivan & Cromwell es la firma legal que asesora a OpenAI en temas de seguridad de IA. En marzo de 2026, presentaron documentos judiciales con citas fabricadas por completo por IA.

No una. No dos. Más de 1.300 casos similares se detectaron en cortes de Estados Unidos ese mes.

¿Cuál fue el problema? Abogados usando IA para investigación legal sin verificar. Confiaron ciegamente en el modelo porque «parecía creíble». Y la firma que asesora a OpenAI sobre seguridad de IA estaba usando IA de forma insegura, sin supervisión humana.

Lección: La IA no sabe lo que no sabe. Y a veces inventa con total confianza.

3. Disney y OpenAI: el acuerdo de $1.000 millones que se derrumbó

Disney había negociado una sociedad de $1.000 millones con OpenAI. Marketing, contenido, asistente interno. Todo encarrilado.

Tres días antes del anuncio público, OpenAI cerró Sora —su generador de video— porque perdían $1 millón diario ejecutándolo.

Disney se enteró por la prensa. Cancelaron todo.

No fue que OpenAI maliciosamente hundiera el acuerdo. Fue que una decisión interna de producto destruyó una sociedad de nueve cifras. Y nadie en Disney había contemplado ese escenario.

Lección: Incluso los acuerdos más grandes dependen de la estabilidad del proveedor. Y los proveedores de IA están en constante rotación de productos.

4. AWS: drones iraníes golpearon data centers en Emiratos Árabes Unidos

Este es el que más me preocupa.

En abril de 2026, drones iraníes atacaron data centers de AWS en Emiratos Árabes Unidos. Por primera vez en la historia, infraestructura cloud comercial fue atacada en un conflicto bélico activo.

Caída regional completa. Banca. Streaming. Gobierno. Todo offline.

AWS —el proveedor de cloud más grande del mundo— tuvo una región entera inoperable. No por un bug. Por un ataque físico con drones.

Lección: La nube es física. Los servidores están en edificios. Y esos edificios pueden ser alcanzados.

5. OpenAI cerró Sora: 67% sin plan B

OpenAI cerró Sora en marzo de 2026. Razones: perdían $1 millón diario.

67% de las empresas que tenían GenAI en producción NO tenían plan B. Ninguno. Si Sora fallaba, su contenido de video se detenía. Si el modelo principal se caía, su automatización se caía.

81% de las empresas expresan preocupación por dependencia de proveedores. Casi nadie tiene estrategia multi-vendor.

Eso no es una estadística. Es un accidente esperando ocurrir.

Cómo me afectó a mí

Yo tenía la arrogancia de pensar que estaba más preparado.

A principios de 2026 me «casé» con Anthropic. Plan Max. Claude Code para desarrollo. OpenClaw como agente principal. Todo mi flujo de trabajo encima de un solo proveedor. Duró poco —unas semanas— hasta que las caídas me obligaron a cambiar.

Y funcionó. Por semanas. Hasta que dejó de funcionar.

La primera caída: 40 minutos. «Seguro fue mi conexión», pensé.

La segunda caída: 2 horas. Ya estaba nervioso.

La tercera caída: 5 horas. Empecé a buscar qué hacer.

La cuarta caída: 3 horas. Ya tenía a MiniMax como backup.

La quinta caída: 1 hora. Pero ya no me importó. Ya había tomado la decisión.

No dejé Anthropic. Eso es importante decirlo. Pero sí agregué opciones.

Mi stack actual (qué hago diferente)

Esto no es un tutorial. Es lo que realmente uso. Cada día.

Para planificación estratégica:

Anthropic Max ($100/mes) — sigue siendo mi modelo principal para razonamiento complejo. No lo voy a negar.
Nemotron Super 3 — también para planificación, como backup activo.

Para agentes y uso de herramientas:

MiniMax 2.7 ($~40/mes) — mi opción predeterminada para agentes que ejecutan tareas, automatización y trabajo pesado. Es rápido, es barato, y no depende de quién sea trending en TechCrunch.

Para cómputo local:

NVIDIA DGX Spark — tengo un servidor con GPU local. Corro Qwen-code-next, Gemma 4 31B, Nemotron. Mis datos no salen de mi casa.
Esto es importante: la información más sensible no vive en la nube de ningún proveedor.

Capa de abstracción:

OpenRouter — me permite cambiar entre proveedores sin cambiar código. Si mañana Google lanza algo mejor que Anthropic, migro en minutos, no en semanas.
Ollama Cloud — cómputo abierto, sin vendor lock-in.

Lo que NO hago:

No confío en un solo modelo para todo
No tengo lógica de negocio crítica en un solo prompt
No asumo que el proveedor de hoy existe mañana

El benchmark público

Lancé benchmarks.cristiantala.com para tener datos reales, no marketing. Porque los números que dan los proveedores en sus landing pages son cherry-picked.

Ahí puedes ver comparativas reales de latencia, costo por token y calidad de salida. Sin bullshit.

La razón por la que hice eso es simple: si vas a depender de algo, al menos elige con datos, no con intuición.

Si la información de tu negocio vive en un prompt

Eres rehén del proveedor.

No lo digo yo. Lo dicen los cinco casos de arriba. Lo dice el dato de que 81% de empresas están preocupadas y casi ninguna tiene plan B.

No se trata de ser paranoico. Se trata de ser realista.

La dependencia en sí no es mala. Depender de AWS tiene sentido si entiendes los riesgos. Depender de Anthropic tiene sentido si tienes estrategia de mitigación.

Lo que es malo es depender sin saber qué vas a hacer cuando el proveedor falle.

Porque van a fallar. Es una certeza, no una posibilidad.

Dos reglas que me repito

1. Diversifica antes de que te obliguen.

No esperes a la primera caída para buscar alternativas. El momento de tener backup no es cuando el proveedor se cae. Es antes.

2. Si vive en un prompt, tiene backup.

Tu flujo de trabajo más crítico no puede depender de una sola API. La arquitectura para eso existe. Es más caro, sí. Pero es resiliente.

¿Tienes dudas sobre dependencia de proveedores de IA en tu negocio? Únete a mi comunidad de emprendedores en Cágala, Aprende, Repite — ahí podemos ayudarte entre todos a pensar tu estrategia de IA sin convertirte en rehén de nadie.

The post La dependencia perfecta: cuando tu proveedor de IA se cae y tú te quedas mirando 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.

How to Use Claude Code with ANY LLM Provider (2026 Guide)

Cristian Tala — Wed, 29 Apr 2026 20:32:33 +0000

I'm Cristian Tala. I founded and sold a fintech (Pago Fácil) for $23M, and now I invest in startups and build with AI. When my $200/month Anthropic Max subscription stopped being enough, I found a better way.

Recently me encontré con un problema que drove me crazy. I've been using Claude Code, pero it was never enough. I started with la subscription Max de $100 al mes, then upgraded to la de $200 — la más cara que existe — y and still. O se me acaba la cuota a mitad de mes, o los servidores de Anthropic están caídos, o noto que las respuestas cada vez son más genéricas. Como si al saturarse la plataforma, el modelo se estuviera volviendo más tonto.

That's when I realized something: estoy pagando $200 al mes (la subscription más cara que existe) por un servicio que me falla más de lo que funciona.

So I started looking for alternatives. Y what I found changed how en que trabajo con IA.

Pero acá viene the part almost nobody knows: Claude Code isn't a model. It's an interface. Y esa interfaz se puede conectar a casi cualquier provider de LLM que exista.

I'm not talking about hacking ni de hacer algo ilegal. Te estoy hablando de una funcionalidad que el propio Claude Code soporta: cambiar el ANTHROPIC_BASE_URL para apuntar a otro provider con endpoint compatible. Y cuando hice eso, descubrí algo que blew my mind.

What nobody tells you sobre Claude Code

Claude Code es una CLI (command-line interface). Envía requests a una API que sigue el formato de Anthropic. Pero ese formato no es exclusivo de Anthropic.

Proveedores como Z.ai (GLM), Xiaomi (MiMo), Moonshot (Kimi), DeepSeek, y muchos otros exponen endpoints que son Anthropic-compatibles. Claude Code envía un request, el provider responde, y todo funciona como si nada hubiera cambiado.

En la práctica: clonas una carpeta de configuración, pegas tu API key, y claude arranca usando un modelo que cuesta $6/mes en vez de $200.

Too good to be true? Yo también lo pensé. Por eso hice dos cosas:

Monté un repositorio con workspaces listos — 20+ provideres configurados, cada uno con su settings.json, instrucciones y troubleshooting. MIT license, úsalo como quieras.
Corrí 7,725 benchmarks con 68 modelos — 91 tests por modelo, 23 suites de evaluación, juez Phi-4 local (Microsoft, 14B, sin conflicto de interés). No tomé la palabra del marketing de ninguno. Medí.

Los resultados me sorprendieron. Y creo que a ti también te van a sorprender.

El dato que incomoda: los modelos más caros son los peores

Antes de pasar a la configuración, you need to see something. Porque sino you'll think I'm selling you snake oil.

Corrí 68 modelos a través de 91 tests cada uno — razonamiento, coding, generación de contenido, tool calling, agentes, traducción, y más. El juez fue Phi-4 de Microsoft corriendo local en Ollama. Cero sesgo comercial.

La correlación entre precio y calidad fue ρ = −0.460 (p = 0.001). Negativa. O sea: los modelos más caros tienden a rendir peor en tests single-turn.

Y en contenido, la correlación es ρ = −0.603 (p < 0.001). Fuerte. El modelo más caro del benchmark, GPT-5.5 a $46.50/1k calls, sacó un score de 6.44. Mientras tanto, Llama 3.1 8B en Groq a $0.14/1k calls sacó 7.66.

55× más barato, 19% mejor.

This isn't opinion. Es la data que cualquiera puede replicar si clona el benchmark.

¿Por qué pasa esto?

Porque los modelos premium suelen ser «thinking models» — consumen tokens de razonamiento interno antes de responder. En un test single-turn corto, ese razonamiento extra no mejora el resultado pero sí dispara el costo. Kimi K2.6 facturaba ~3,500 tokens de output cuando el texto visible era solo ~700. Un multiplicador de 5× en costo por la misma respuesta.

Además, los modelos económicos modernos (Llama, GPT-OSS, Gemma 4) están tan bien afinados que para la inmensa mayoría de tareas de coding y contenido, la diferencia con los premium es imperceptible en la práctica.

The Top 10 Nobody Expected

Esto es lo que salió del benchmark v2.4 (29 de abril 2026):

Modelo
Score
$/1k calls
tok/s
Provider

1
Llama 4 Scout 17B
7.67
$0.54
244
Groq

2
Llama 3.1 8B Instant
7.66
$0.14
368
Groq

3
Llama 3.3 70B
7.64
$1.36
238
Groq

4
Mistral Small 4
7.54
$0.94
110
OpenRouter

5
GPT-OSS 20B
7.53
$0.47
633
Groq

6
Gemini 3.1 Flash Lite
7.50
$2.33
148
Google

7
Grok 4.1 Fast
7.50
$0.81
116
xAI

8
GPT-OSS 120B
7.41
$0.00
75
Ollama Cloud

9
Devstral Small
7.35
$0.48
147
OpenRouter

10
MiMo V2.5 (Xiaomi)
7.32
$0.13
79
Xiaomi

8 of 10 are open-source. Los 4 modelos en Groq directo tienen más de 200 tokens/segundo, score arriba de 7.5 y cuestan menos de $1.50 por 1k llamadas. Esa combinación no existe en provideres cerrados.

Y for those wondering: sí, Claude Opus 4.7 quedó fuera del top 10. Saca 7.16 y cuesta $117 por 1k calls. 20× más caro que DeepSeek V4 Flash, que via NIM gratis saca 7.07.

The hard question: ¿pagarías 20× más para ganar 8% de score?

El mismo modelo, distinto provider: matters more than you think

Otro hallazgo que me hizo repensar todo: el provider importa tanto como el modelo.

Gemma 4 31B corrió en tres provideres distintos:

Provider
Score
Costo
tok/s

NVIDIA NIM
7.20
$0.00
22.8

OpenRouter
7.20
$0.99
22.8

DGX Spark local (Q4)
6.84
$0.00
9.3

NIM gratis da exactamente el mismo resultado que OpenRouter pagado. Y Kimi K2.5 en NIM gratis empata al 100% con OpenRouter a $1.26/1k calls. Pagar por ese modelo cuando NIM lo da gratis es, literalmente, literally burning money.

La regla es simple: si Groq tiene el modelo, usa Groq. Su LPU entrega 5-10× más velocidad a precio competitivo. Si quieres costo cero con calidad FP16, usa NIM (con límite de 40 RPM, pero gratis).

Cómo configurar Claude Code con cualquier provider — paso a paso

Here comes the practical part. Todo lo que describo está documentado con archivos de configuración listos en github.com/ctala/claude-code-providers.

Preparación: limpia tu entorno

Antes de cualquier cosa, verifica que no tengas variables del shell sobrescribiendo la configuración:

env | grep ANTHROPIC

Si ves ANTHROPIC_AUTH_TOKEN, ANTHROPIC_BASE_URL o ANTHROPIC_API_KEY en tu ~/.zshrc o ~/.bashrc, las variables del shell tienen prioridad sobre los settings por carpeta. Desactívalas antes de probar:

unset ANTHROPIC_AUTH_TOKEN ANTHROPIC_BASE_URL ANTHROPIC_API_KEY

La estructura: cada provider es una carpeta independiente

El repositorio funciona así: cada subcarpeta es un workspace Claude Code completo con su configuración aislada:

provider/
├── .claude/
│   ├── settings.json              # Config compartible (BASE_URL, modelos)
│   ├── settings.local.json.example # Plantilla con placeholder para tu key
│   └── settings.local.json        # Tu API key real (gitignored)
├── .gitignore                     # Incluye settings.local.json
└── README.md                      # Instrucciones específicas

Setup genérico (3 pasos)

## 1. Entra a la carpeta del provider
cd /

## 2. Copia la plantilla y pega tu API key
cp .claude/settings.local.json.example .claude/settings.local.json
$EDITOR .claude/settings.local.json

## 3. Lanza Claude Code
claude

## Dentro de Claude, verifica:
/status    # Confirma BASE_URL + modelo activo
/model     # Cambiar modelo si el provider tiene varios

Tienes 20+ provideres configurados así. Cambias de uno a otro con un cd. No hay conflicto porque cada settings.local.json vive en su propia carpeta.

Proveedores por category — cuál elegir según tu situación

Plan mensual: alternativas fijas a Anthropic Max

Carpeta
Proveedor
Modelos
USD/mes

xiaomi/
Xiaomi MiMo Token Plan
MiMo V2.5, V2.5-Pro, V2-Omni
$6-$88

zai-coding/
Z.ai GLM Coding Plan
GLM-4.7, GLM-5.1, GLM-4.5-Air
~$10-$80

minimax/
MiniMax Coding Plan
M2.7, M2.7-highspeed
$19-$50

qwen-coding/
Alibaba Qwen Coding Plan
Qwen3-Coder-Plus, Qwen3-Max
Variable

Mi recomendación personal: Xiaomi MiMo a $14/mes (plan Standard). MiMo V2.5 salió #10 global en el benchmark con score 7.32 — por encima de Claude Opus 4.7 en 3 de 4 pilares. A 42× menos del costo.

Pay-as-you-go: para cuando no quieres subscription

Carpeta
Proveedor
Modelos
Notas

deepseek/
DeepSeek
DeepSeek-V3, Coder
De los más baratos del mercado

openrouter/
OpenRouter
300+ modelos
Una key para todo, fallback automático

moonshot/
Moonshot Kimi
Kimi K2 Turbo
Endpoint Anthropic-compat oficial

zai-api/
Z.ai BigModel API
GLM-4.7, GLM-5.1
Pay-per-token

OpenRouter es el comodín: una sola API key te da acceso a Anthropic, xAI, Google, Meta, Qwen, DeepSeek — 300+ modelos. Si quieres flexibilidad sin compromisos, es la opción.

Cloud enterprise: AWS, GCP, Azure

Carpeta
Plataforma
Variables

aws-bedrock/
AWS
CLAUDE_CODE_USE_BEDROCK=1

google-vertex/
GCP
CLAUDE_CODE_USE_VERTEX=1

azure-foundry/
Azure
Endpoint Anthropic-compat

Si tu empresa ya tiene cuentas en AWS/GCP/Azure, esto te permite consumir Claude (Bedrock, Vertex) o modelos third-party (Foundry) bajo tu IAM y facturación corporativa. Sin APIs sueltas, sin credenciales fuera del ecosistema.

Local: si tienes el hardware, la privacidad no tiene precio

Carpeta
Stack
Modelos típicos

ollama-local/
Ollama 0.11+ (Anthropic-compat nativo)
Qwen3-Coder, Llama 3.3, DeepSeek-V3

lmstudio-local/
LM Studio + LiteLLM proxy
Cualquier GGUF

nvidia-nim/
Docker NIM container
NIMs publicados por NVIDIA

Ollama 0.11+ expone el endpoint Anthropic-compat de forma nativa en :11434. Sin proxy, sin traductor. Es tan simple como correr el container y apuntar ANTHROPIC_BASE_URL=http://localhost:11434.

Si tienes un DGX Spark (o cualquier GPU potente con 24GB+), puedes correr Qwen3-Coder:480B, Llama 3.3:70b, o DeepSeek-Coder-V2 localmente. Costo: $0 (más electricidad). Privacidad: total.

La trampa de ANTHROPIC_AUTH_TOKEN vs ANTHROPIC_API_KEY

Un error que me quitó 2 horas la primera vez — y por eso lo puse en el docs/troubleshooting.md del repo:

ANTHROPIC_AUTH_TOKEN — Para provideres third-party con endpoint Anthropic-compat (Z.ai, Xiaomi, Moonshot, DeepSeek).
ANTHROPIC_API_KEY — Solo para Anthropic directo (pay-as-you-go en api.anthropic.com).

Confundirlas = error 401 inmediato. Y no es obvio hasta que lees la documentación del provider.

¿Pero funcionan de verdad estos modelos para coding?

The million-dollar question. Si vas a usar Claude Code, es para programar. Probé 23 suites distintas, incluyendo code_generation, tool_calling, y structured_output.

Los resultados por suite:

Suite
Mejor modelo
Score

Code generation
Llama 4 Scout 17B
8.04

Tool calling
Llama 3.1 8B Instant
8.45

Structured output
Llama 3.1 8B Instant
8.00

String precision
Devstral Small
8.12

Razonamiento
GPT-OSS 20B
7.97

Deep reasoning
Llama 4 Scout 17B
7.68

Devstral Small (Mistral, Apache 2.0, $0.10/$0.30 per M tokens) es la sorpresa del benchmark — open-source, barato, y domina coding con un tool calling excelente.

Ahora, an honest warning: el benchmark mide modelos solos, single-turn, sin herramientas. En producción real, un workflow N8N con herramientas (búsqueda web, RAG, API calls) puede invertir el ranking. Qwen 3.5 397B, por ejemplo, parece «regular» en el benchmark (score global 6.72) pero en producción genera artículos excelentes para ecosistemastartup.com porque se integra perfecto con tools de búsqueda.

El benchmark te da la línea base. Tu workflow real te da el resultado.

Setups recomendados por presupuesto

$0/mes — Solo local

Si tienes el hardware (DGX Spark, GPU 24GB+, Apple Silicon):

Modelos:

- Gemma 4 31B → tareas rápidas

- Qwen 3.5 72B → coding y razonamiento de calidad

- Phi-4 14B → juez local

Setup: ollama-local/ carpeta

$14-20/mes — Una subscription fija

Opción
Qué obtienes
Mejor para

Xiaomi MiMo ($14)
MiMo V2.5 (score 7.32)
Content + coding económico

GLM Coding ($10)
GLM-5.1, GLM-4.7
Coding con costo fijo

OpenRouter pay-as-you-go
300+ modelos, ~$20 crédito
Flexibilidad máxima

Mi recomendación: OpenRouter. Una API key para todo. Si un modelo falla o se deprecata, cambias sin reconfigurar nada.

$50/mes — Combo óptimo

OpenRouter pay-as-you-go: ~$15-20 (DeepSeek + Gemini Flash + Devstral)
MiniMax Agent Pro: $19 (M2.7 para agentes, costo fijo)
Gemini CLI: $0 (prototipos rápidos)
Total: ~$35-40

Esto reemplaza a la subscription Max de $200 de Anthropic — y no dependes de su disponibilidad.

$100+/mes — Setup completo

OpenRouter: ~$20 (DeepSeek + Devstral para volumen)
MiniMax Agent: $19 (M2.7 para agentes 24/7)
NIM local: $0 (modelos open-source para privacidad)
Anthropic Max (opcional): $200 (Opus 4.7 solo para tareas críticas)

Nota: Anthropic Max lo uso solo para tareas críticas donde necesito Opus 4.7. Para todo lo demás, los modelos alternativos rinden igual o mejor por fracción del costo.

To put it in perspective: yo pago $200 al mes por Anthropic Max (la subscription más cara que existe) y me alcanza la mitad del tiempo. Cuando los servidores de Claude se saturan, las respuestas se vuelven más genéricas — lo notas. Con el setup que describo ($35-40) trabajo sin límites, con fallback automático y sin depender de una sola empresa. This isn't theory — es lo que uso todos los días.

El combo de abajo es como tener 300 modelos a tu disposición con una sola API key (OpenRouter). Si uno falla, usas otro. Si Anthropic se cae, rotas a Groq. Si DeepSeek está lento, usas MiMo. Tienes poder de negociación.

Lo que aprendí haciendo esto

Running 7,725 benchmarks con 68 modelos isn't free. Invertí:

~$350-400 USD en APIs (OpenAI, OpenRouter, MiniMax, Anthropic, Xiaomi)
~$45/mes en suscripciones activas
~190h de cómputo cloud
~50h de cómputo local (GPU en Mac M-series + DGX Spark)
~80-100h de trabajo humano (diseño de tests, debugging, análisis, documentación)

Todo eso está disponible gratis bajo MIT license en los dos repositorios. If this saves you an afternoon de debugging de Anthropic Base URL, give it a star — ayuda a que otros devs lo encuentren.

github.com/ctala/claude-code-providers — workspaces listos para 20+ provideres
github.com/ctala/ai-benchmarks-alternativos — 7,725 benchmarks, 68 modelos, 23 suites
benchmarks.cristiantala.com — dashboard interactivo para encontrar tu modelo en 30 segundos

The uncomfortable truth

No existe el «mejor modelo». Y quien te diga que sí, probablemente te está vendiendo uno.

Lo que existe es el mejor modelo para lo que necesitas, con el presupuesto que tienes, en el contexto que trabajas.

¿Coding rápido y barato? Devstral Small o DeepSeek V3.
¿Agentes 24/7 con costo predecible? MiniMax M2.7 a $19/mes fijo.
¿Contenido SEO en español? DeepSeek V3.2 es #1 en news_seo_writing.
¿Soporte al cliente donde la honestidad importa? Claude Sonnet — no inventa respuestas.
¿Privacidad total? Ollama local con los modelos que ya corren en tu hardware.
¿Flexibilidad absoluta? OpenRouter con una key para 300+ modelos.

The 2026 LLM ecosystem is a feast — y la mayoría sigue comiendo en el mismo restaurante caro. Hay alternativas mejores, más baratas, y en muchos casos, abiertas.

La pregunta no es «cuál es el mejor modelo». La pregunta es: ¿qué quieres construir hoy, y cuánto quieres pagar por las herramientas?

¿Tienes dudas sobre qué modelo usar para tu caso específico? Únete a mi comunidad de emprendedores en Cágala, Aprende, Repite — ahí podemos ayudarte entre todos. Y si quieres ver cómo armo los benchmarks con N8N y OpenClaw en la práctica, el workflow está documentado en el repo.

Publicado originalmente en cristiantala.com

Tu Primer Agente de IA Local con OpenClaw + Ollama: Guía para Principiantes

Cristian Tala — Wed, 29 Apr 2026 17:00:04 +0000

En 15 minutos vas a tener un asistente de IA que corre en tu computador — sin enviarle tus datos a nadie.

¿Por Qué Quieres Esto?

Seguro usas ChatGPT o Claude. Son buenos, pero tienen un problema: todo lo que escribes se va a un servidor que no controlas. Cada pregunta, cada documento que subes, cada dato de tu empresa — está en otro lado.

Esta guía te da una alternativa: un agente de IA que vive en tu computador. Tus datos no salen de tu máquina. Y lo mejor: es gratis.

¿La contra? Necesitas instalar 2 programas (te explico cómo, paso a paso). Si sabes copiar y pegar, puedes hacerlo.

¿Qué Es Cada Cosa?

Antes de empezar, para que no estés pegando cosas sin entender:

– Ollama = El programa que descarga y ejecuta «cerebros de IA» en tu computador. Es como instalar Spotify, pero en vez de música, descargas inteligencia artificial. – OpenClaw = El programa que conecta ese cerebro de IA con tus apps (WhatsApp, Telegram, etc.). Sin OpenClaw, el modelo solo funciona dentro de Ollama. Con OpenClaw, le puedes hablar desde donde sea.

¿Qué Necesitas?

– Un computador: Mac (de preferencia con chip M1, M2, M3 o M4) o un PC con al menos 16GB de memoria RAM (si tienes 8GB también funciona, solo va un poco más lento) – Internet: Solo para descargar los programas. Después funciona sin internet. – 15 minutos de tu tiempo.

Paso 1: Instalar Ollama (2 minutos)

Ollama es lo primero que necesitas.

Si usas Mac:

Abre Terminal (presiona Command + Espacio, escribe «Terminal» y presiona Enter) 2. Copia y pega esta línea completa:

Visita la página de descarga de Ollama y sigue las instrucciones para tu sistema operativo. El instalador se encarga de todo automáticamente.

Presiona Enter 4. Va a pedirte tu contraseña — escríbela aunque no veas los caracteres aparecer (es normal) y presiona Enter

Si usas Windows:

Abre tu navegador y ve a https://ollama.com/download 2. Haz clic en el botón de descarga 3. Abre el archivo que descargaste y sigue las instrucciones (como instalar cualquier programa)

Verifica que Se Instaló

En la Terminal (o la consola en Windows), escribe:

`ollama --version`

Si ves un número (como 0.x.x), funciona. Si te dice «command not found», vuelve a intentar la instalación.

¡Perfecto! Ollama está instalado.

Paso 2: Descargar el Modelo de IA (5 minutos)

Ahora descargamos el «cerebro» de tu agente.

Si tienes buena RAM (16GB o más)

En la Terminal, pega:

`ollama pull qwen3.5:27b`

Si tienes poca RAM (8GB)

En la Terminal, pega:

`ollama pull gemma4`

¿No sabes cuánta RAM tienes?

– Mac: Menú Apple → «Acerca de esta Mac» → mira donde dice «Memoria»

– Windows: Escribe «Información del sistema» en el buscador → busca «RAM instalada»

Esto descarga entre 4GB y 16GB de datos. Mientras espera, ve por un café

¿Qué modelo elegir? Mira los datos, no la hype. Armé una calculadora interactiva de modelos IA donde tú le dices tu presupuesto, cuántas requests al mes esperas, qué calidad mínima necesitas — y te recomienda el modelo ideal. Se basa en 91 tests reales contra decenas de modelos. Filtra por open-source, tool calling, velocidad, incluso alternativas a Claude o ChatGPT. Ve los datos y elige con información, no por lo que dice Twitter.

Cuando termine, vas a ver un mensaje que dice «success» o similar.

Paso 3: Instalar OpenClaw (3 minutos)

OpenClaw conecta tu modelo de IA con tus apps.

¿Tienes Node.js?

Node.js es un programa que OpenClaw necesita para funcionar.

En la Terminal, pega:

`node --version`

– Si ves algo como v22.x.x o v24.x.x → ya lo tienes, salta al siguiente paso. – Si te dice algo como «command not found» → Necesitas instalarlo: – Mac: Ve a https://nodejs.org, descarga la versión LTS e instálala. – Windows: Igual, https://nodejs.org, descarga la versión LTS.

Instala OpenClaw

`npm install -g openclaw@latest`

Va a tardar un minuto o dos. Cuando termine, tienes OpenClaw.

Paso 4: Conectar Todo (5 minutos)

Ahora vamos a conectar OpenClaw con Ollama. El asistente de OpenClaw hace casi todo por ti.

Ejecuta el Asistente

`openclaw onboard`

El asistente te va a hacer preguntas. Sigue estas instrucciones:

«Choose a provider» → Escribe Ollama y presiona Enter 2. «Choose mode» → Si quieres que funcione solo en tu computador sin internet, elige Local only. Si quieres tener la opción de usar modelos en la nube como respaldo, elige Cloud + Local (luego te explica qué significa) 3. El asistente va a detectar el modelo que descargaste en el Paso 2. Confírmalo con Enter.

Si te pide una API key para Ollama Cloud (solo en modo Cloud): Necesitas crear una cuenta gratis en ollama.com y copiar la API key de tu perfil.

Verifica que Todo Está Bien

`openclaw gateway status`

Si dice que está «running» o «listening», todo funciona.

Paso 5: Habla con Tu Agente (1 minuto)

En la Terminal, pega:

`openclaw dashboard`

Esto va a abrir una página en tu navegador con una pantalla de chat.

Escribe algo como »Hola, ¿quién eres?» y… debería responderte.

Si respondió: Felicidades Tienes tu primer agente de IA local funcionando.

Si no respondió: Mira la sección de problemas comunes abajo.

Paso 6: (Opcional) Habla con Tu Agente Desde el Celular

Esto es lo que hace que valga la pena. Hablarle a tu agente desde WhatsApp o Telegram.

La Forma Más Fácil: Telegram

Abre Telegram y busca @botfather 2. Escríbele /newbot 3. Te va a pedir un nombre para tu bot (ej: «Mi Asistente») 4. Luego te pide un username (debe terminar en «bot», ej: «mi_asistente_ia_bot») 5. BotFather te da un token — es una cadena larga de letras y números. Guárdalo. 6. En tu Terminal, pega estos dos comandos (reemplazando TU_TOKEN por lo que te dio BotFather):

openclaw config set channels.telegram.botToken "TU_TOKEN_AQUI"
openclaw config set channels.telegram.dmPolicy "open"

Y reinicia:

`openclaw gateway restart`

Ahora busca tu bot en Telegram y envíale un mensaje. Te va a responder

Problemas Comunes

«Model not found» → El modelo no se descargó bien. Ejecuta de nuevo: ollama pull qwen3.5:27b (o el modelo que hayas elegido).

No sé si tengo suficiente RAM → Si tu computador tiene 8GB o más, va a funcionar. Si tiene menos de 8GB, va a ser muy lento.

El agente no responde → Ejecuta openclaw logs y busca errores (palabras en rojo o que digan «error»). Si no puedes resolverlo, pregunta en el Discord de OpenClaw — la comunidad es buena onda.

Va muy lento → El modelo es muy grande para tu computador. Descarga uno más pequeño: – ollama pull qwen3.5:7b (solo 4GB) – Y cambia el modelo en config: openclaw config set agents.defaults.model.primary «ollama/qwen3.5:7b» – Antes de cambiar, revisa la calculadora de modelos — ahí ves la latencia real y velocidad de cada modelo

¿Y Ahora Qué?

Ahora tienes un agente de IA que:

– Responde preguntas sin enviar datos a ningún servidor – Puedes hablarle desde tu teléfono – Es gratis para siempre

Pero esto es solo el comienzo. Tu agente puede hacer mucho más:

– Buscar en internet en tiempo real – Trabajar con tus archivos — leer, escribir, editar – Entender imágenes (si descargas un modelo que soporte imágenes) – Ejecutar comandos en tu computador – Recordar cosas que le dices entre conversaciones

Si quieres automatizar flujos más complejos (como que revise tu email todos los días y te mande un resumen por WhatsApp), puedes conectar OpenClaw con n8n — una plataforma de automatización que te permite crear flujos visuales sin código.

Y si quieres aprender más y compartir configuraciones con otras personas, únete a mi comunidad Cágala, Aprende, Repite — ahí hablamos de IA, automatización y cómo hacer que la tecnología trabaje para ti.

Recursos y Herramientas

Calculadora de Modelos IA

Si no sabes qué modelo elegir para tu caso, usa la calculadora interactiva de modelos de inteligencia artificial que armé con 91 tests reales contra decenas de modelos. Le dices tu presupuesto mensual, cuántas requests esperas, qué calidad mínima necesitas, y te recomienda el modelo ideal — sea alternativa a Claude, ChatGPT, o para correr local con Ollama. Los datos vienen del benchmark v2.3 de abril 2026 y se actualizan con cada nuevo lote de tests.

Filtros disponibles: – Presupuesto mensual – Velocidad mínima (tokens por segundo) – Calidad mínima requerida – Solo open-source – Tool calling para agentes (N8N, OpenClaw) – Alternativas a Claude, ChatGPT o Gemini – Modelos económicos para emprendedores

Documentación

– Documentación completa de OpenClaw — instalación, configuración, canales, herramientas – Todos los modelos disponibles en Ollama — catálogo oficial – Repositorio de OpenClaw en GitHub – Metodología del benchmark de modelos IA — cómo se evalúan los 91 tests – Comunidad de OpenClaw en Discord — soporte y preguntas

The post Tu Primer Agente de IA Local con OpenClaw + Ollama: Guía para Principiantes 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

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

What's next

Why the source is private

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

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

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

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

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

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

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

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

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

Stack recomendado por presupuesto

$0/mes: 100% local con Ollama

$20-50/mes: Groq + Ollama Cloud

$100+/mes: API directa + Cursor Pro

El cierre que Anthropic no te dice

FAQ

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

¿Qué pasa si ya pago Claude Pro?

¿Groq es confiable para producción?

¿El costo es realmente tan diferente o es clickbait?

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

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

The problem: Skool has no public API

Skool API architecture: SSR for reads, REST for writes

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)