DEV Community: Joan Comadran

Supabase "new row violates row-level security policy": every cause and the fix

Joan Comadran — Wed, 14 Oct 2026 13:48:04 +0000

If Supabase is throwing new row violates row-level security policy for table "your_table" (code 42501, HTTP 403), Row Level Security is on and the row you're writing didn't pass any policy's WITH CHECK. Nine times out of ten the fix is one of these two:

-- 1. The table has no INSERT policy. Add one:
create policy "insert own rows" on public.notes
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

-- 2. The row doesn't carry the user's id. Let the database fill it:
alter table public.notes
  alter column user_id set default auth.uid();

If that didn't do it, one of the other four causes below is yours. I'll show how to tell which, with the SQL for each. The examples come from the RLS I've written for two production Supabase apps: Claient, a multi-tenant WhatsApp lead agent where every row belongs to an account, and pollitics.es, a public polling site.

What the error actually means

RLS is default-deny per command. Enabling it on a table without policies blocks everything for anon and authenticated. A SELECT policy lets people read, but it says nothing about INSERT, UPDATE or DELETE. Each of those needs its own policy, or a for all policy.

Two clauses matter:

USING: which existing rows you can see, update or delete.
WITH CHECK: which new row values you're allowed to write (inserts, and the after-image of updates).

"new row violates…" always means a WITH CHECK evaluated to false or null for your row. It never means "the table doesn't exist" or "your key is wrong".

Cause 1: there is no INSERT policy

The classic one. You enabled RLS, added "Enable read access for authenticated users", and reads work, so you assume writes will too. They won't.

Check what you have:

select policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public' and tablename = 'notes';

If no row has cmd = INSERT or ALL, add the policy from the top of this post. If you want one policy per table, for all with both clauses is fine. This is how every tenant table in Claient is written:

create policy leads_all on public.leads
  for all using (public.is_account_member(account_id))
  with check (public.is_account_member(account_id));

Cause 2: user_id is null or not the caller

Your policy says with check (auth.uid() = user_id), but the client inserted { title } without user_id. Then auth.uid() = null is null, not true, and the row is rejected.

Don't make the client responsible for sending its own id. Set a default so it can omit the column:

alter table public.notes alter column user_id set default auth.uid();

Keep the WITH CHECK anyway. A default only applies when the column is omitted, so the policy is what stops a client sending someone else's id.

Cause 3: the request isn't authenticated (auth.uid() is null)

The policy and the column are right, and it still fails. The usual culprit is that the request reached Postgres as anon, so auth.uid() is null and every auth.uid() = … check fails. That happens when:

a Server Action or Route Handler uses a client created with createClient(url, anonKey) and no session;
in Next.js with @supabase/ssr, the server client isn't reading the request cookies, or the session cookie expired and was never refreshed by middleware;
the insert runs before the session exists, e.g. right after signUp() with email confirmation still pending.

Quick test: run select auth.uid(), auth.role(); through the same client (as an RPC), or log await supabase.auth.getUser() right before the insert. If it's null or anon, fix the client, not the policy. On the server, build the client with createServerClient from @supabase/ssr and pass it the request cookies. That's how the dashboard in Claient does it.

If you're creating a profile row right after sign-up, don't insert from the client at all. Use a trigger on auth.users with a security definer function, which runs regardless of the session.

Cause 4: insert().select() without a SELECT policy

const { data, error } = await supabase.from('notes').insert({ title }).select();

.select() turns the statement into INSERT … RETURNING *. Postgres must let you read the row you just wrote, so a table with an INSERT policy but no matching SELECT policy fails with the same "new row violates" message. It's confusing because the insert is the part that's allowed.

Fix: add a SELECT policy that covers the new row, or drop .select() if you don't need the row back.

The same thing explains the famous Storage version of the error. Uploads do an INSERT … RETURNING on storage.objects, so you need a SELECT policy on storage.objects for that bucket and path, not just an INSERT one. Supabase's troubleshooting note confirms it.

Cause 5: an UPDATE whose new row fails WITH CHECK

Updates are checked twice: USING on the old row, and WITH CHECK on the new one. If the UPDATE policy has no WITH CHECK, Postgres reuses the USING expression for it. So an update that changes a column your policy depends on, like moving a row to another account or user, is rejected with "new row violates…".

Usually that's exactly what you want: it stops users from writing a row into someone else's tenant. If it's blocking a legitimate update, look at which column in your SET the policy reads, and write an explicit WITH CHECK for the state the row is allowed to end up in. Don't reach for with check (true) unless you've thought through what it lets through.

Cause 6: a policy that can't see what it needs

Multi-tenant policies often check membership in another table:

using (exists (select 1 from account_members m
               where m.account_id = leads.account_id and m.user_id = auth.uid()))

If account_members has RLS too, that subquery runs under the caller's policies. It can come back empty, making the check false, or recurse into itself if account_members' own policy does the same lookup. The fix I use in Claient is one security definer function that every policy calls:

create or replace function public.is_account_member(target_account uuid)
returns boolean
language sql
stable
security definer
set search_path = public
as $$
  select exists (
    select 1 from public.account_members m
    where m.account_id = target_account
      and m.user_id = auth.uid()
  );
$$;

security definer makes the lookup run as the function's owner, so it doesn't depend on account_members' own policies and can't recurse. set search_path stops anyone from shadowing the table with their own. I go deeper into this pattern, including wrapping calls as (select fn()) so they run once per query instead of once per row, in the pre-launch security checklist for Next.js + Supabase.

Not this error: "permission denied for table"

Same 42501 code, different problem. permission denied for table notes (or for column status) means the role lacks a GRANT, which Postgres checks before RLS. No policy will fix it.

I hit this deliberately in Claient. Users could update their own feature request, and the RLS policy limited that to their own row. But RLS can't limit which columns you change, so someone could call PostgREST directly and mark their own request as "done". The fix was column-level grants:

revoke update on public.feature_requests from authenticated;
grant update (title, description) on public.feature_requests to authenticated;

Now updating status as a user returns "permission denied for column", while the admin path still works.

When the service_role key is the right answer (and when it isn't)

The fastest way to make the error go away is the service_role (secret) key, which bypasses RLS completely. That's correct for server code that legitimately acts across users. In Claient, the WhatsApp webhook writes messages and leads for whichever tenant the message belongs to, and the Stripe webhook writes subscriptions. Those tables deliberately have no write policy for users, so only the server can write them. Some internal tables have RLS on with zero policies, which is deny-all for everyone but service_role.

It's the wrong answer in user-facing code. The key must stay server-only (never NEXT_PUBLIC_), and swapping it in to silence an error means that request no longer has any data isolation.

A 60-second checklist

select * from pg_policies where tablename = 'x': is there an INSERT/UPDATE/ALL policy for the right role?
Does it have a WITH CHECK, and does your row satisfy it? Is user_id actually set?
Is auth.uid() non-null for this request? Check the client and session first.
Are you calling .select() after the insert, or uploading to Storage? Then you need a SELECT policy too.
Is it an UPDATE changing a column the policy depends on?
Does the policy query another RLS table? Move the lookup into a security definer function.
Does the message say "permission denied"? That's a GRANT, not RLS.

I build Supabase and AI products end to end, and RLS for multi-tenant apps is a recurring part of that. If you'd rather have someone get it right the first time, here's how I work.

FAQ

What does "new row violates row-level security policy" mean in Supabase?

It is Postgres error 42501, returned by Supabase as HTTP 403. Row Level Security is enabled on the table and the row you are writing did not pass any policy's WITH CHECK expression for that operation. Because RLS is default-deny per command, the most common reason is simply that the table has no INSERT (or UPDATE) policy for the role making the request.

How do I fix new row violates row-level security policy on insert?

Add an INSERT policy for the authenticated role with a WITH CHECK clause, for example: create policy "insert own rows" on public.notes for insert to authenticated with check ((select auth.uid()) = user_id). Then make sure the row actually carries the signed-in user's id, ideally with a column default of auth.uid(), and that the request is made with the user's session rather than only the anon key.

Why do I get the RLS error when I call insert().select()?

insert().select() runs INSERT ... RETURNING, and returning the row requires that the caller can also SELECT it. If the table has an INSERT policy but no SELECT policy that covers the new row, the whole statement fails with the same RLS error. Add a matching SELECT policy or drop the .select().

Should I use the service_role key to get around RLS errors?

Only on the server, and only for code that legitimately acts across users, such as webhooks or background workers. The service_role key bypasses RLS entirely, so it must never reach the browser. Using it to silence an RLS error in user-facing code removes your data isolation instead of fixing the policy.

Is "permission denied for table" the same as the RLS error?

No. Both use SQLSTATE 42501, but "permission denied for table" (or "for column") comes from missing GRANT privileges, which Postgres checks before RLS. "new row violates row-level security policy" means the grant was fine and a policy rejected the row. Fix the first with GRANT, the second with a policy.

Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.

Shipping shareable poll results with Next.js ImageResponse

Joan Comadran — Wed, 14 Oct 2026 13:42:41 +0000

I've been building pollitics.es: a Spanish citizen thermometer for vote intention, wellbeing, and political mapping. The product lives or dies on whether people actually spread the aggregate. Screenshots of a responsive layout crop wrong, leak UI chrome, and — worse — sometimes include someone's personal ballot if they voted before sharing. So last week I shipped a dedicated shareable results image: one PNG, same for everyone, generated with next/og, handed to the native share sheet on mobile.

This is the version that survived the quirks. Not the happy-path demo.

Why a route beats "just screenshot it"

Open Graph meta tags (og:image) are for link previews when someone pastes a URL. That is not the same product as "tap Share and attach a chart to WhatsApp / Instagram Stories / X". Meta cards are landscape-ish, often cached for days, and you don't control the crop once the client app decides to be clever. Instagram and WhatsApp Stories want a tall frame. Voters want a button that feels like sharing a result, not sharing a browser tab.

So the shape is two pieces:

A GET route that returns a PNG built with ImageResponse from next/og.
A client button that fetches that PNG as a File, then either navigator.share({ files }) or falls back to a download.

The URL on pollitics is /intencion-de-voto/imagen. Revalidate every 15 minutes — same cadence as the public results ISR — so the image and the page don't disagree for long.

The image: public aggregate only

The hard product rule: the image never carries the viewer's vote. It is the latest public snapshot, identical for every downloader. No "you voted X" badge, no personalised colour flash, no N in the corner that would let someone reverse-engineer a tiny sample. We even strip the "Basado en N respuestas" line and the snapshot date from the PNG (decided 2026-10-04) so a viral share doesn't become a forensic artefact.

Dimensions are 1080 × 1350 — the vertical that Instagram, X, and WhatsApp leave alone without cropping the bars. Monochrome chrome, party colours only on the bars, Inter subset for Latin glyphs. If there aren't enough votes yet, or Spain's electoral blackout is on, the route still returns an image: it just shows a freeze message instead of percentages. Diffusing polls during the LOREG blackout is illegal; the share UI is hidden on the page in that window, and the image route refuses to paint numbers even if someone hits the URL directly.

Rough shape of the route:

// app/intencion-de-voto/imagen/route.tsx
import { ImageResponse } from "next/og";
import { readFile } from "node:fs/promises";
import { join } from "node:path";

export const revalidate = 900;

const WIDTH = 1080;
const HEIGHT = 1350;

export async function GET() {
  const results = await getPublicResults(/* supabase public client */);
  const blackout = results?.blackoutActive;
  const ready = /* snapshot exists && votesToPublish(results) === 0 */;

  return new ImageResponse(
    (
      <div
        style={{
          width: "100%",
          height: "100%",
          display: "flex",
          flexDirection: "column",
          justifyContent: "space-between",
          background: "#ffffff",
          padding: 72,
          fontFamily: "Inter",
        }}
      >
        <div style={{ display: "flex", flexDirection: "column" }}>
          <div style={{ fontSize: 28, color: "#595959" }}>
            Intención de voto · Elecciones generales
          </div>
          <div style={{ fontSize: 64, lineHeight: 1.08, marginTop: 16 }}>
            Si mañana hubiera elecciones
          </div>
        </div>

        {ready && !blackout ? (
          /* bar rows from snapshot.decided — acronym, colour, pct */
          <Bars rows={toRows(results.snapshot.decided)} />
        ) : (
          <div style={{ display: "flex", fontSize: 44, lineHeight: 1.2 }}>
            {blackout
              ? "Periodo electoral: resultados congelados."
              : "Todavía no hay votos suficientes para publicar resultados."}
          </div>
        )}

        <div
          style={{
            display: "flex",
            justifyContent: "space-between",
            fontSize: 30,
            borderTop: "2px solid #000",
            paddingTop: 24,
          }}
        >
          <span>¿Y tú qué votarías?</span>
          <span>pollitics.es</span>
        </div>
      </div>
    ),
    {
      width: WIDTH,
      height: HEIGHT,
      fonts: [
        {
          name: "Inter",
          data: await readFile(join(process.cwd(), "assets/fonts/Inter-Regular.ttf")),
          weight: 400,
        },
      ],
    },
  );
}

Two details that matter in production:

Load the font from disk, not from a CDN fetch inside the handler. Cold starts and font CDNs love to race each other; bundling Inter under assets/fonts made the route boringly reliable.
Cap the rows. Spanish ballots are long. We show at most 12 bars and fold the rest into "Otros", otherwise the type collapses and Stories crop the bottom parties.

The button: Safari will punish you

navigator.share({ files: [png] }) is the right API on mobile. Desktop browsers often don't support file shares, so you need a download path. The nasty part is Safari's user-gesture requirement: if you await fetch(image) inside the click handler before calling share(), Safari decides the gesture expired and throws NotAllowedError.

The fix is to start the fetch on pointerdown / focus, stash the Promise<File>, and resolve it on click:

"use client";

const IMAGE_URL = "/intencion-de-voto/imagen";

export function ShareImage() {
  const pending = useRef<Promise<File> | null>(null);
  const fileName = `pollitics-intencion-de-voto-${new Date()
    .toISOString()
    .slice(0, 10)}.png`;

  function prepare() {
    pending.current ??= fetch(IMAGE_URL)
      .then(async (res) => {
        if (!res.ok) throw new Error(String(res.status));
        return new File([await res.blob()], fileName, { type: "image/png" });
      })
      .catch((e) => {
        pending.current = null;
        throw e;
      });
    return pending.current;
  }

  function download(file: File) {
    const url = URL.createObjectURL(file);
    Object.assign(document.createElement("a"), {
      href: url,
      download: fileName,
    }).click();
    URL.revokeObjectURL(url);
  }

  async function share() {
    let file: File | null = null;
    try {
      file = await prepare();
      if (!navigator.canShare?.({ files: [file] })) return download(file);
      await navigator.share({
        files: [file],
        text: "Intención de voto en pollitics.es. ¿Y tú qué votarías?",
      });
    } catch (e) {
      const name = e instanceof DOMException ? e.name : "";
      if (name === "NotAllowedError" && file) download(file);
      // AbortError = user cancelled the sheet. Leave it alone.
    }
  }

  return (
    <button
      type="button"
      onPointerDown={() => prepare().catch(() => {})}
      onFocus={() => prepare().catch(() => {})}
      onClick={share}
    >
      Compartir imagen
    </button>
  );
}

canShare({ files }) is the gate. Don't call share with files if it returns false — some browsers claim navigator.share exists but reject file payloads. And always treat AbortError as success-shaped: the user closed the sheet on purpose.

On the page, the component is gated with {!results.blackoutActive && }. Legal constraint first, UX second.

Don't publish noise: the 50-vote floor

The first version of pollitics showed percentages from vote one. That looked clever in staging and looked broken in production: a 100% bar for whoever voted first is not a result, it's a bug wearing a chart. On 2026-10-06 we raised the public floor to 50 votes in the rolling 90-day count (MIN_PUBLIC_SAMPLE). Below that, the UI says how many votes are still missing; the image route shows the same "not enough yet" copy instead of bars.

export const MIN_PUBLIC_SAMPLE = 50;

export function votesToPublish(results: PublicResults | null) {
  return Math.max(
    0,
    MIN_PUBLIC_SAMPLE - (results?.snapshot?.meta.sample_total ?? 0),
  );
}

After 50, we still label anything under 1.000 as "Datos preliminares". We never invent a margin of error — this is open participation, not a representative poll, and the image footer says so in plain Spanish.

What I'd steal for any product, not just polls

If you're shipping a shareable artefact from a Next.js app, the checklist that actually moved the needle for me:

Concern	Choice	Why
Render	`ImageResponse` / `next/og`	Same deploy as the app; no Puppeteer farm
Size	1080×1350 (or your Stories frame)	Platforms stop fighting you
Cache	`revalidate` aligned with page ISR	Image and page stay honest together
Privacy	One public payload, zero personalisation	Screenshots of authenticated UI will betray you
Mobile share	Prefetch file on pointerdown, then `canShare`	Safari's gesture clock is not optional
Fallback	Object-URL download	Desktop and stubborn WebViews
Legal / policy	Hide the button and blank the numbers	Deep links exist

The whole feature is maybe two hundred lines. The product decisions around it — blackout, minimum sample, never stamp N on the PNG — took longer than the code, which is usually the tell that you built the right thing.

If you want the live version, vote (or just look) on pollitics.es/intencion-de-voto once the sample clears fifty. The share button is under the results. Your vote stays off the image. That was the entire point. And if you're about to ship something similar, the security pass I did before launch covers the rest of the site.

Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.

A pre-launch security checklist for Next.js + Supabase (from a real launch)

Joan Comadran — Wed, 14 Oct 2026 13:41:39 +0000

Before opening pollitics.es, my Spanish vote-intention thermometer, to the public, it had to go from "works on my machine" to "strangers will poke at this". Political polls attract exactly the kind of visitor you don't want: people who'd love to stuff the ballot, scrape someone's vote, or embed your results page somewhere it doesn't belong. So before the public launch I did one boring, very large commit called pre-launch security enhancements. A 461-line migration, a 537-line SQL test file, security headers and a handful of small fixes.

None of it is clever, and that's sort of the point. Here's the checklist, with the code, in the order I'd do it again.

1. Close Supabase's default grants

This is the one that surprised me most, so it goes first. Out of the box, Supabase grants privileges on everything in the public schema to anon and authenticated. RLS is what usually saves you, but "a new table is reachable unless I remember to protect it" is a bad default for a project where the next migration will be written at midnight.

So I flipped it. Anything the migration role (postgres) creates from now on starts with zero client access:

alter default privileges for role postgres in schema public
  revoke all on tables from anon, authenticated;
alter default privileges for role postgres in schema public
  revoke all on sequences from anon, authenticated;
alter default privileges for role postgres in schema public
  revoke all on functions from anon, authenticated;

-- EXECUTE to PUBLIC is a global Postgres default: it can only be
-- revoked without a schema (this also covers the private schema).
alter default privileges for role postgres
  revoke execute on functions from public;

-- Existing identity sequences: clients never insert, they don't need them.
revoke all on all sequences in schema public from anon, authenticated;

Two gotchas. Default privileges only apply to objects created afterwards, so existing explicit grants stay exactly as they were (which is what you want, and what the tests check). And a function used inside an RLS policy now needs its own grant execute, otherwise the policy fails for that role instead of quietly passing.

2. RLS policies that call one function, once

The product rule on pollitics is that only people who have voted see the full evolution of the results. Everyone else, anonymous visitors included, sees just the latest published snapshots. On top of that there's Spanish electoral law: during the pre-election blackout nobody can see new polls, so nothing published from the blackout's start date onwards is readable.

That rule touches eight aggregate tables. Instead of copy-pasting the logic into eight policies, there's one security definer function that returns the readable time range for whoever is asking:

create or replace function public.readable_snapshots()
returns tstzrange
language plpgsql
stable
security definer
set search_path = ''
as $$
declare
  v_until timestamptz;   -- exclusive upper bound; null = no limit
  v_from  timestamptz;
begin
  if public.electoral_blackout_active(now()) then
    select (s.value ->> 'from')::timestamptz into v_until
    from public.app_settings s
    where s.key = 'electoral_blackout';
  end if;

  if public.has_voted() then
    return pg_catalog.tstzrange(null, v_until, '[)');
  end if;

  -- Non-voters: only the last two publishable snapshots.
  select min(l.snapshot_at) into v_from
  from (
    select m.snapshot_at
    from public.snapshot_meta m
    where v_until is null or m.snapshot_at < v_until
    order by m.snapshot_at desc
    limit 2
  ) l;

  if v_from is null then
    return 'empty'::tstzrange;
  end if;
  return pg_catalog.tstzrange(v_from, v_until, '[)');
end;
$$;

And every policy is a one-liner:

alter policy "results_snapshots_read" on public.results_snapshots
  using (snapshot_at <@ (select public.readable_snapshots()));

The details that matter:

Wrap the call in (select ...). Postgres then evaluates it once per query as a scalar subquery instead of once per row. Same result, very different bill on a big table.
security definer plus set search_path = ''. The function reads snapshot_meta, which has its own policy that calls the same function. Running as the owner avoids that recursion, and the empty search path (with fully qualified names) stops anyone from shadowing public.has_voted with their own object.
Why two snapshots and not one. Some pages read the latest snapshot_at in one query (or from a 15-minute cache) and the rows in another. If the cron job writes a new snapshot in between, a "last one only" rule would make the page go blank. The second-to-last snapshot is the margin.

3. A CSP that doesn't kill ISR

The textbook answer is a nonce-based Content Security Policy. The catch in Next.js is that nonces are per request, so they force every page to render dynamically. The pollitics home page is ISR, and I'd rather keep it served from cache. So the CSP has no nonces and accepts 'unsafe-inline' for scripts, and everything else is locked down hard:

// next.config.ts
const supabase = process.env.NEXT_PUBLIC_SUPABASE_URL ?? "";
const turnstile = "https://challenges.cloudflare.com";
const isDev = process.env.NODE_ENV === "development";
const vercelLive = process.env.VERCEL_ENV === "preview" ? " https://vercel.live" : "";

const csp = [
  "default-src 'self'",
  `script-src 'self' 'unsafe-inline'${isDev ? " 'unsafe-eval'" : ""} ${turnstile}${vercelLive}`,
  "style-src 'self' 'unsafe-inline'",
  "img-src 'self' blob: data:",
  "font-src 'self'",
  `connect-src 'self' ${supabase}${vercelLive}`,
  `frame-src ${turnstile}${vercelLive}`,
  "object-src 'none'",
  "base-uri 'self'",
  "form-action 'self'",
  "frame-ancestors 'none'",
  ...(isDev ? [] : ["upgrade-insecure-requests"]),
].join("; ");

const securityHeaders = [
  { key: "Content-Security-Policy", value: csp },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=(), browsing-topics=()" },
];

const nextConfig = {
  poweredByHeader: false,
  async headers() {
    return [{ source: "/:path*", headers: securityHeaders }];
  },
};

A few notes from getting it to actually work:

The only external origins are Supabase (auth and RPC calls from the browser) and Cloudflare Turnstile (script plus iframe for the captcha). If you can't list your third parties on one hand, the CSP will tell you.
Vercel's preview comment toolbar needs vercel.live, so it's allowed only when VERCEL_ENV is preview.
frame-ancestors 'none' and X-Frame-Options: DENY say the same thing for new and old browsers: nobody gets to frame the voting page inside something that looks official.
The CSP is built at build time from NEXT_PUBLIC_SUPABASE_URL. Change the Supabase URL and you have to redeploy. I wrote that in the README because future me will forget.
No HSTS header in the config, because Vercel already sends it on every HTTPS domain.

4. An open-redirect-proof `?next=`

Login flows love ?next=/somewhere. They also love becoming open redirects: ?next=//evil.com is the classic, but the fun ones abuse the fact that browsers strip tabs and newlines and treat \ like /. So /\t/evil.com can end up on evil.com. The fix is small and paranoid:

const BASE = "https://pollitics.invalid";

export function safeNext(next: string | string[] | undefined, fallback = "/intencion-de-voto#votar") {
  const value = Array.isArray(next) ? next[0] : next;
  if (!value || !value.startsWith("/") || /[\u0000-\u001f\u007f\\]/.test(value)) return fallback;
  try {
    const url = new URL(value, BASE);
    if (url.origin !== BASE) return fallback;
    return url.pathname + url.search + url.hash;
  } catch {
    return fallback;
  }
}

Reject control characters and backslashes outright, then let the URL parser have the last word: resolve against a fake origin and make sure the origin didn't move. Use .invalid as the TLD so the base can never be a real site.

5. GDPR export and delete that go through the same doors

If you collect political opinions in the EU, "email us to delete your data" doesn't cut it. Both rights are self-service now.

Export (GDPR article 20, portability) is a plain route handler, /cuenta/exportar. It reads the user's data through the same get_my_* RPC functions the account page uses, so it can't see anything the user couldn't already see, and it returns a JSON attachment with Cache-Control: private, no-store so no CDN ever keeps a copy.

Delete is a Supabase Edge Function. Deleting the auth.users row cascades through an identity map and a trigger that removes the respondent, their vote and its history. One detail worth stealing: with Supabase's new API keys, the keys aren't JWTs, so the function runs with verify_jwt = false and validates the user's token itself:

Deno.serve(async (req) => {
  if (req.method !== "POST") return json({ error: "method_not_allowed" }, 405);

  const jwt = req.headers.get("Authorization")?.replace(/^Bearer\s+/i, "");
  if (!jwt) return json({ error: "not_authenticated" }, 401);

  const { data, error } = await admin.auth.getUser(jwt);
  if (error || !data.user) return json({ error: "not_authenticated" }, 401);

  const { error: deleteError } = await admin.auth.admin.deleteUser(data.user.id);
  if (deleteError) return json({ error: "delete_failed" }, 500);

  return json({ ok: true }, 200);
});

The function deletes whoever owns the token, and only them. There's no user id in the request body to tamper with.

6. Alert when the cron job quietly stops

Not exactly security, but the failure mode is the same: something breaks and nobody notices. Public results come from a pg_cron job that writes a snapshot every 15 minutes. If it stops, the site keeps serving old numbers with a straight face.

The existing anomaly check (vote spikes per party, signup spikes) got one more rule: if the latest snapshot is more than an hour old and the electoral blackout wasn't active in that window (during the blackout, not writing is the whole point), insert a stale_snapshot alert. Alerts go out by email through Resend, called from Postgres with pg_net, with the API key read from Supabase Vault. One alert per episode, so a dead job doesn't turn into an inbox flood.

7. Test it all in a transaction that always rolls back

This is the part that made the rest safe to ship. A small Node script opens one connection to the remote project, runs begin, applies any pending migrations (the ones not yet in supabase_migrations.schema_migrations), runs every file in supabase/tests/, and always ends with rollback:

try {
  await client.query("begin");
  for (const f of files) {
    console.log(`▸ ${f.name}`);
    await client.query(f.sql);
  }
} catch (e) {
  failed = true;
  console.error(`✗ ${e.message}`);
} finally {
  await client.query("rollback").catch(() => {});
  await client.end();
}
process.exit(failed ? 1 : 0);

Tests are plain SQL that raise exception on failure. The default-privileges test is my favourite because it checks the thing I actually care about, the next table, not the current ones:

create table public.t_prelaunch_new (id bigint generated always as identity primary key);
create function public.f_prelaunch_new() returns integer language sql as 'select 1';

do $$
begin
  if has_table_privilege('anon', 'public.t_prelaunch_new', 'select')
  or has_table_privilege('authenticated', 'public.t_prelaunch_new', 'insert')
  or has_sequence_privilege('anon', 'public.t_prelaunch_new_id_seq', 'usage')
  or has_function_privilege('anon', 'public.f_prelaunch_new()', 'execute') then
    raise exception 'FAIL: a new object is exposed to clients by default';
  end if;
  if not has_table_privilege('service_role', 'public.t_prelaunch_new', 'select') then
    raise exception 'FAIL: service_role lost its default access';
  end if;
end $$;

The same file seeds 400 random respondents with a fixed seed (setseed(0.42)) and checks that the refactored snapshot function produces exactly the same aggregates as the original queries, table by table. That refactor computed each eligible population once into temp tables instead of up to three times per run, which is a performance change I'd never have dared to ship without a row-for-row diff.

The checklist, short version

Area	What I did	Why
Default grants	Revoke default privileges for `anon` / `authenticated`, revoke `EXECUTE` from `PUBLIC`	The next table is safe even if I forget
RLS	One `security definer` function, called as `(select fn())` in each policy	One rule, evaluated once per query
Headers	CSP without nonces, frame-ancestors none, nosniff, strict referrer, no `x-powered-by`	Keeps ISR, still locks down third parties
Redirects	`safeNext()` with a control-char check and an origin check	`?next=` is an open redirect by default
Privacy	Self-service JSON export and an Edge Function delete keyed on the caller's token	GDPR, without a support inbox
Ops	Stale-snapshot alert via `pg_net` + Vault	Silent failures are the worst kind
Tests	Migrations + SQL tests in one transaction, always rolled back	Validate against the real project without touching it

Seven items, one commit, zero clever tricks. If you're about to launch something on Next.js and Supabase, number 1 alone is worth the ten minutes. If you want someone to do this kind of pass on your product, that's the kind of work I take on. And if you want to see the result, go and vote on pollitics; the shareable results image still won't show anyone what you picked.

FAQ

Does Supabase expose new tables to anon and authenticated by default?

Yes. Supabase grants privileges on objects in the public schema to the anon and authenticated roles by default, so a new table, sequence or function is reachable through the API unless RLS or a revoke stops it. On pollitics.es I removed that default with ALTER DEFAULT PRIVILEGES for the postgres role (tables, sequences and functions), plus a global revoke of EXECUTE on functions from PUBLIC, so every new object needs an explicit grant.

Can I use a strict nonce-based CSP with Next.js ISR?

Not without giving up static rendering. Nonces have to be generated per request, which makes every page dynamic and breaks ISR. On pollitics.es I kept ISR and shipped a CSP without nonces: 'unsafe-inline' for scripts (Next needs it), and an explicit allowlist for Supabase and Cloudflare Turnstile, plus frame-ancestors 'none', object-src 'none', base-uri and form-action locked to 'self'.

How do I prevent open redirects with a ?next= parameter in Next.js?

Only accept values that start with a single slash, reject any control character or backslash (browsers strip tabs and newlines and treat a backslash as a slash, so '/\t/evil.com' can end up on evil.com), then resolve the value against a fixed fake origin with new URL() and check the origin didn't change. Return pathname, search and hash, or a safe fallback.

How do I test Supabase migrations without touching the database?

Run the pending migrations and your SQL test files inside a single transaction that always ends in ROLLBACK. Each test raises an exception on failure, so the script exits non-zero and nothing persists either way. On pollitics.es a small Node script with the pg client does this against the remote project.

Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.

AI agent development cost: what actually moves the number (2026)

Joan Comadran — Wed, 14 Oct 2026 13:35:36 +0000

Here's the short answer people actually want: AI agent development cost is mostly scope, not model fees. The model bill is real and easy to measure. The number that surprises founders is the engineering around the model — the channel, the tools that write to real systems, multi-tenant isolation, evals, and the week you spend hardening the webhook so Meta doesn't double-send every reply.

I don't publish a rate card here, and I'm not going to invent a "market average" with fake precision. What I can do is show what moves the quote, what it costs to run an agent on Claude as of October 2026, and what I learned shipping Claient (WhatsApp lead agent), Adorea.ai, and Dairector. If you're comparing agency cost guides that all land on $30k–$180k, treat those as their sales bands — useful as a sanity check, not as a standard.

The three costs people mix up

Cost	What it is	Who pays
Build	Engineering to ship the agent: product, tools, auth, channel, evals	You, once (or in slices)
Run	Model tokens, hosting, channel fees, observability	You, every month
Own	Maintenance when models deprecate, prompts drift, APIs change	You, forever

Most "AI agent development cost" pages only talk about the first row, then bury run cost in a footnote. In production the second row is where a good architecture either stays cheap or quietly burns the margin — I wrote the token side up in keeping Claude's token bill from ruining your month.

What actually moves the build number

These are the drivers I budget against, in the order that usually bites.

1. How many systems the agent can write to. A read-only FAQ bot over your docs is one shape. An agent that books appointments, creates CRM rows, or sends WhatsApp templates is another. Every write-action needs schemas, retries, idempotency, and a human-approval path when the stakes are high. Tool count is a weak proxy; write count is the real one.

2. The channel. WhatsApp via Meta Cloud API is not "add a chat widget." You need webhook verification, signature checks, idempotency on wamid, and a plan for Meta's retries when your serverless function times out. That alone ate more engineering time than the Claude loop on Claient. Email or an in-app chat is usually cheaper. Voice is its own project.

3. Single-tenant vs multi-tenant. Solving the agent for one business is a focused build. Solving it so any tenant self-serves, with RLS on account_id, encrypted BYOK keys, and one webhook routing by phone_number_id, is a product. Claient only becomes interesting as a business once the second version exists.

4. Evals and observability. Cheap agents skip them. Expensive incidents come from skipping them. Budget time for a golden set of real conversations, cost logging per account, and traces you can read when a lead gets the wrong answer at 23:00.

5. Who owns the model key. Flat product price with your key absorbed (Claient defaults to Haiku) is a different quote from BYOK, where the tenant pays Anthropic directly. BYOK lowers your variable cost and raises onboarding and vault work.

Rough shape from builds I've done: a single-task agent with a couple of tools and one channel is a few weeks of senior work to something clickable; hardening + multi-tenant + billing stretches that into months. I won't turn that into a fake dollar table — hours × whoever you hire is the only honest formula.

Running cost: model rates you can verify (as of Oct 2026)

List prices from Anthropic's pricing page, per million tokens (input / output). They change; check before you budget.

Model	Input	Output	Notes
Claude Haiku 5.5 (≤100K prompt)	$0.10	$0.50	Cheap high-volume tier
Claude Haiku 4.5	$1	$5	What Claient still defaults to in production
Claude Sonnet 5.5	$2	$10	Workhorse for harder reasoning
Claude Opus 5.5	$4	$20	Heavy tasks, drafting, research
Claude Fable 5.1	$10	$50	Top tier

Prompt cache reads are a fraction of input (0.05×–0.1× depending on model; Fable goes lower). Batch is 50% off when you can wait. Client-side tool use is just tokens; Anthropic web search is $10 per 1,000 searches on top.

What that means in practice for a WhatsApp lead agent:

Default to a cheap model for the conversation loop. Claient runs Haiku by default; tenants who want Sonnet/Opus bring their own key.
Cache the static system prompt and tool schemas. Don't resend the full history every turn — use a short verbatim window plus a rolling summary (details here).
Log real USD per account. If you can't see cost per conversation, you can't price the product.

Hosting for a Next.js + Supabase agent is usually noise next to a bad model choice: tens to low hundreds of dollars a month until you have serious traffic. Channel fees matter more — Meta service conversations within 24h on Cloud API direct are free, which is why Claient can sit at €49/month with ~0 € platform cost per customer. A BSP in the middle would have broken that price.

Build vs buy vs hire

Buy a SaaS when your use case is generic (FAQ, basic lead capture, appointment booking templates) and you're fine renting their qualification rules. Fastest path; you pay forever and bend to their product.

Build in-house when you already have a senior engineer who has shipped LLM tool-use, and the agent is core IP. Still budget for the channel and for the month after launch, not just the demo week.

Hire when you need production reliability and don't have that person on payroll. Fit for custom tools, multi-tenant SaaS, WhatsApp/CRM write-paths, or a first LLM product where a wrong architecture is expensive to unwind. Not fit for a slide-deck prototype.

I ship the hire path from Barcelona, remote-friendly: TypeScript, Next.js, Supabase, @anthropic-ai/sdk directly — no LangChain tax unless the project truly needs multi-provider orchestration. Details and process on hire an AI engineer.

When it's worth it / when it's not

Worth building or hiring for when:

Leads or revenue depend on speed (out-of-hours WhatsApp, inbound that dies in an inbox).
The agent must call your tools with real side effects, not just chat.
You need multi-tenant isolation, BYOK, or channel economics a template can't give you.
You're launching a product (not a one-off script) and need cost controls from day one.

Not worth it when:

A Zapier/Make/no-code bot already covers the happy path.
You only need an internal demo for a stakeholder meeting.
Nobody will own evals and model updates after the first deploy.
The "agent" is really a single LLM call with no tools — that's a feature, not a project.

Verdict

If someone quotes you AI agent development cost as one number with no breakdown of channel, write-tools, tenancy and run model, they're selling a vibe. Ask for: scope of write-actions, who pays for tokens, how evals work, and what the monthly run cost looks like at your expected volume on a named model and caching strategy.

My default for a production lead or support agent in 2026: Claude via the official SDK, cheapest model that passes your eval, prompt caching on, conversation memory bounded, channel owned directly. That's the shape behind Claient. The build cost is the engineering to make that boring and safe; the run cost is then a line item you can actually forecast.

Want that built end-to-end — agent, product shell, tracking — talk to me on the AI engineering page. Related reading: Claude vs GPT for AI agents, WhatsApp bot with Claude, ship an AI product in a weekend.

FAQ

How much does it cost to build an AI agent in 2026?

There is no single market price. What moves the number is scope: one channel vs many, how many write-actions the agent can take, multi-tenant isolation, evals, and who owns the channel (WhatsApp, CRM, calendar). A focused single-task agent with a few tools is weeks of senior engineering; a multi-tenant product with billing, dashboards and hardened webhooks is months. Vendor cost guides often quote $30k–$180k+ for production agents — treat those as rough bands from their sales pages, not a standard. Running cost is separate and usually dominated by model tokens.

What does it cost to run an AI agent after you build it?

Mostly model tokens plus hosting. As of October 2026 on Anthropic's list prices, Claude Haiku 5.5 starts at $0.10 / $0.50 per million input/output tokens (prompts up to 100K), Haiku 4.5 is $1 / $5, Sonnet 5.5 is $2 / $10, and Opus 5.5 is $4 / $20. Prompt cache reads are a fraction of input. A WhatsApp lead agent on Haiku with caching and a rolling conversation window stays in the cents-per-conversation range for typical volumes; the same agent on a frontier model without caching does not. Add hosting (often tens to low hundreds of dollars a month on Vercel + a managed Postgres) and whatever the channel charges.

Is it cheaper to buy a SaaS chatbot than to build a custom AI agent?

Usually yes for generic FAQ or lead capture. Buy when a template covers your channel and qualification rules. Build (or hire) when you need custom tools, multi-tenant isolation, a channel you must own (for example Meta Cloud API direct), BYOK, or product economics that SaaS pricing breaks. Claient only made sense as a product because Meta service conversations within 24h are free on Cloud API direct — a BSP fee would have eaten the $49/month price.

When is it worth hiring an AI engineer to build an agent?

When the agent has to touch real systems (WhatsApp, CRM, calendar, payments), when wrong answers cost you leads or trust, or when you need multi-tenant security and cost controls from day one. Not worth it for a one-off internal demo or a FAQ bot a no-code tool already covers. If you want someone who has shipped production agents end-to-end, see the AI engineering page.

Do I need LangChain or an agent framework in the budget?

No. Production agents I ship call @anthropic-ai/sdk directly: a tool-use loop is a few dozen lines. Frameworks help with multi-provider routing or complex graphs; they also hide the provider features (prompt caching breakpoints, server tools) that usually save the most money. Budget for evals, observability and cost logging before you budget for a framework.

Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.

Claude vs GPT for AI agents: what I actually ship with (2026)

Joan Comadran — Wed, 14 Oct 2026 13:34:31 +0000

Here's the verdict, so you can leave early if that's all you came for: I build my AI agents on Claude, and I'd still tell most people that the honest answer to "Claude vs GPT for agents" in late 2026 is "it matters less than you think." As of October 2026 the two price ladders mirror each other almost to the cent, both have 1M-token context windows, both enforce tool schemas strictly, and both host web search for you. What's left to choose on is API shape, how much control you get over caching, which hosted tools you need, and which one your evals prefer on your tool schemas.

If you want a default: pick Claude if your agent lives on long, growing context and you care about controlling exactly what gets cached. Pick GPT if you're building a voice agent, want hosted file search over your documents, or your company already runs on OpenAI or Azure contracts.

One disclosure before the table, because comparison posts rarely make it: every agent I run in production is on Claude. I've used OpenAI's API, but I don't have a shipped GPT agent to compare like-for-like, so the GPT column below comes from OpenAI's docs and pricing pages, not from war stories. The Claude column comes from code I can show you.

Claude vs GPT at a glance (as of October 2026)

All prices are list prices per million tokens (input / output), taken from the Anthropic and OpenAI pricing pages in October 2026. These change often; check before you budget.

	Claude (Anthropic)	GPT (OpenAI)
Current lineup	Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5	GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna
Top tier	Fable 5.1: $10 / $50	GPT-6 Astra: $10 / $50
Between top and mid	Opus 5.5: $4 / $20	—
Workhorse tier	Sonnet 5.5: $2 / $10	GPT-6.1 Sol: $2 / $10
Cheap, high-volume tier	Haiku 5.5: from $0.10 / $0.50 (prompts up to 100K tokens)	GPT-6 Luna: from $0.10 / $0.50 (short context)
Context window	1M tokens on all current models	1.05M tokens on the flagship three
Long-context billing	Full 1M at the standard rate (except Haiku 5.5 above 100K)	Separate, higher long-context rate
Max output	128K tokens	128K tokens
API you build agents on	Messages API (`tool_use` / `tool_result` blocks)	Responses API (required for tool calling on Astra and Sol)
Schema-enforced tool calls	`strict: true` on tool definitions	`strict: true`; Responses tries to make tools strict by default
Prompt caching	Explicit `cache_control` breakpoints or automatic; cache reads at 10% of input or less	Discounted cached input (5–10% of input on the flagship three)
Batch discount	50%	50%
Hosted tools	Web search ($10 / 1K searches), web fetch, code execution, tool search, MCP connector, computer and browser use	Web search ($10 / 1K calls), file search, hosted shell / code interpreter, computer use, MCP, tool search
Voice / realtime	Text and image in, text out	Dedicated realtime and voice models

Look at the price rows for a second. Not long ago, a "Claude vs GPT" post was half about cost. Now the cheap tiers start at the same price, the workhorse tiers are identical, and the top tiers are identical. Rate cards aren't where the difference is anymore.

Where they actually differ for agent builders

The API shape

On Claude, an agent turn is a Messages API call. If the model wants a tool, the response has stop_reason: "tool_use" and one or more tool_use blocks; you run them and send back a user turn full of tool_result blocks. On GPT, the newest models require the Responses API for tool calling: the output is a list of items, tool calls come back as function_call items, and you return function_call_output items, optionally chaining with previous_response_id.

Neither is better in the abstract. They are different enough that "we'll just swap the model later" is a week of work, not a config change, once you've built retries, caching, cost logging and error handling around one of them.

Caching control

This is the one that decided it for me. Claude lets you mark exactly where the cacheable prefix ends with cache_control breakpoints (or let the API place them automatically). In a conversational agent, where the system prompt is static and the history grows every turn, being able to say "cache everything up to here" is the difference between cost that grows with the square of the conversation and cost that grows roughly linearly. I wrote up the full story in keeping Claude's token bill from ruining your month.

OpenAI discounts cached input heavily too, so this isn't "Claude caches, GPT doesn't." It's about how much you get to steer it.

Long context billing

Both vendors offer roughly a million tokens of context. The difference is the bill: Anthropic charges the full 1M window at the standard rate on its current models (Haiku 5.5 aside), while OpenAI lists a separate, higher long-context price on Astra, Sol and Luna. If your agent stuffs whole codebases, contracts or long transcripts into context, model that difference before you pick. If your prompts are a few thousand tokens, it doesn't matter.

Hosted tools

Both now run web search on their side and support MCP. OpenAI has hosted file search with managed storage and a full line of realtime voice models; if you're building a phone or voice agent, that alone probably decides it. Anthropic has server-side web search and web fetch, code execution, a tool-search tool for large tool sets, and an MCP connector that talks to remote MCP servers straight from the Messages API.

What I actually run in production (and why)

None of my agents use LangChain or the Vercel AI SDK. Every one calls @anthropic-ai/sdk directly, because the provider-specific features are exactly the ones I'm relying on. Here are two, straight from the repos.

Claient: a multi-tenant WhatsApp agent on Haiku

Claient answers and qualifies WhatsApp leads for small businesses (the build story is here). The model choice is gated by who pays:

// With the platform key (we pay), only Haiku is served.
// Tenants who bring their own key (BYOK) can pick Sonnet or Opus.
export const MODELO_BASE = "claude-haiku-4-5-20251001";

export function modeloEfectivo(opts: { apiKey?: string | null; model?: string | null }) {
  if (!opts.apiKey) return MODELO_BASE;
  return opts.model || getClaudeConfig().model;
}

The reply runs in a tool-use loop with three booking tools (check availability, book, reschedule). Two guards matter more than the model: a hard cap of five loop iterations, and a time budget, because a serverless function killed mid-loop means the lead got a message but the webhook didn't finish, and Meta's retry sends it twice:

const MAX_ITER_TOOLS = 5;
const MARGEN_VUELTA_MS = 20_000; // SDK timeout 15 s + 1 retry must fit

for (let i = 0; i < MAX_ITER_TOOLS; i++) {
  if (i > 0 && !hayMargen(opts.deadline)) break; // fall back instead of dying mid-turn
  const respuesta = await claude.messages.create({ model, max_tokens, system, messages, tools });
  if (respuesta.stop_reason === "tool_use") {
    // run each tool_use block, push the tool_result blocks, loop again
    continue;
  }
  return textOf(respuesta);
}

Lead qualification is a separate call that forces a tool, tool_choice: { type: "tool", name: "registrar_lead" }, with nullable fields and an enum for lead temperature (cold, warm, hot). Forcing a tool is the most reliable way I know to get structured data out of a conversation, and GPT can do the same thing with tool_choice plus strict mode. The cache breakpoints sit on the system prompt and the latest turn, and the history sent is a window of the last 16 messages plus a rolling summary. Every call logs input, output, cache-read and cache-write tokens and their USD cost per tenant, with a monthly spend cap.

An honest footnote: Claient still pins Haiku 4.5, which is now a legacy model. Haiku 5.5 lists at a tenth of the price. That's the obvious thing to test next, and it's also a good example of why you want evals: "cheaper and newer" is a hypothesis until your own conversations say otherwise.

Pollitics: two models, two jobs

For pollitics.es, a weekly job drafts candidate questions about the week's news for a human to review. It's split into two Claude calls on purpose:

Research on Sonnet 5.5 with Anthropic's server-side web search (max_uses: 10, effort medium). Most of the cost here is input tokens from the pages it reads, so the cheaper model does the reading.
Drafting on Opus 5.5 with JSON-schema structured output (effort high), where editorial nuance matters and the input is small.

It's two calls, not one, because structured output doesn't carry the search citations, so the research comes back as text with URLs and the drafter works from that. The code also handles pause_turn (the server-side search loop paused, send it back to continue) and refusal stop reasons, and the whole thing has to fit inside a 150-second Edge Function. A deterministic review step then flags anything that breaks the editorial rules before a person approves it.

So why Claude?

Not because GPT couldn't run either of these. The reasons are concrete and a little boring:

Cache breakpoints matched the architecture. Static script plus growing history is exactly the shape explicit cache_control is good at.
Tiering within one vendor. Haiku for every message, Sonnet for reading the web, Opus for the writing that matters. One SDK, one usage format, one cost table. Dairector's script doctor runs on Claude too.
BYOK stays simple. Tenants paste one kind of key. Supporting two providers' keys, models and error classes would double the surface for very little customer value.
Compounding. Timeouts, retries, error classification (AuthenticationError vs transient 429/5xx), cost logging: all written once, against one SDK. That's the real lock-in, and it's mine, not the vendor's.

When to use which

Choose Claude when:

Your agent is conversational or long-running and context grows every turn, so caching control pays for itself.
You need very long context and don't want a long-context surcharge on the mid and top tiers.
You want one vendor with a clear cheap / workhorse / heavy ladder to route tasks across.

Choose GPT when:

You're building a voice or phone agent and want first-party realtime models.
You want hosted file search over your documents without running your own vector store.
Your organisation already has OpenAI or Azure OpenAI contracts, data agreements and monitoring in place. That's a perfectly good reason; procurement is engineering too.

Either way:

Build a small eval set from real conversations (twenty is enough to start) and run both on your actual tool schemas before you commit.
Put the model call behind one module of your own so a future switch touches one file.
Cap loop iterations and spend from day one. Neither vendor will do that for you.

If you're weighing this for a real product and want someone who has shipped agents end-to-end to make the call with you, that's what I do. For the rest of the stack around the model, see how I ship an AI product in a weekend.

FAQ

Is Claude or GPT better for building AI agents in 2026?

Neither wins across the board. As of October 2026 the price tiers mirror each other (Sonnet 5.5 and GPT-6.1 Sol are both $2/$10 per million tokens; Haiku 5.5 and GPT-6 Luna both start at $0.10/$0.50), both offer 1M-token context, 128K max output, strict schema-enforced tool calls and hosted web search. Claude is the better default if you want explicit control over prompt caching and long context billed at the standard rate; GPT is the better default for voice agents, hosted file search, or teams already on OpenAI or Azure. Run your own eval on your own tool schemas before committing.

Is Claude more expensive than GPT for agents?

Not anymore at list price. As of October 2026 the mid tiers (Claude Sonnet 5.5 and GPT-6.1 Sol) are both $2 input / $10 output per million tokens, the cheap tiers (Claude Haiku 5.5 and GPT-6 Luna) both start at $0.10 / $0.50, and the top tiers (Claude Fable 5.1 and GPT-6 Astra) are both $10 / $50. Claude Opus 5.5 sits in between at $4 / $20. Both offer 50% off for batch work and discounted cached input. Real cost differences come from how much context you resend and how well you cache it, not the rate card.

Can I switch an agent from Claude to GPT later?

Yes, but it is not a one-line change. The Claude Messages API uses tool_use and tool_result content blocks; OpenAI's Responses API, which GPT-6 Astra and GPT-6.1 Sol require for tool calling, uses function_call and function_call_output items. Caching, usage fields, error classes and hosted tools also differ. Keep the model call behind one small module of your own so a switch touches one file, and keep an eval set so you can tell whether the switch was an improvement.

Which model does Joan Comadran use for production AI agents?

Claude, called directly through the Anthropic TypeScript SDK with no agent framework. Claient, the WhatsApp lead agent, runs Claude Haiku 4.5 by default with tool use for appointment booking and forced tool calls for lead extraction, and lets tenants bring their own key to use Sonnet or Opus. The weekly-question pipeline for pollitics.es uses Claude Sonnet 5.5 with server-side web search for research and Claude Opus 5.5 with JSON-schema structured output for drafting.

Do I need LangChain or another framework to build an agent with Claude or GPT?

No. A tool-use agent is a loop: call the model with tool definitions, execute any tool calls it returns, send the results back, and stop when it answers in text. Both official SDKs make that a few dozen lines, and both vendors now offer optional helpers (Anthropic's Tool Runner, OpenAI's Agents SDK). A framework can help with many providers or complex orchestration, but it also hides the provider-specific features, like cache breakpoints and server tools, that most of the cost and reliability wins come from.

Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.

DEV Community: Joan Comadran

Supabase "new row violates row-level security policy": every cause and the fix

What the error actually means

Cause 1: there is no INSERT policy

Cause 2: user_id is null or not the caller

Cause 3: the request isn't authenticated (auth.uid() is null)

Cause 4: insert().select() without a SELECT policy

Cause 5: an UPDATE whose new row fails WITH CHECK

Cause 6: a policy that can't see what it needs

Not this error: "permission denied for table"

When the service_role key is the right answer (and when it isn't)

A 60-second checklist

FAQ

What does "new row violates row-level security policy" mean in Supabase?

How do I fix new row violates row-level security policy on insert?

Why do I get the RLS error when I call insert().select()?

Should I use the service_role key to get around RLS errors?

Is "permission denied for table" the same as the RLS error?

Shipping shareable poll results with Next.js ImageResponse

Why a route beats "just screenshot it"

The image: public aggregate only

The button: Safari will punish you

Don't publish noise: the 50-vote floor

What I'd steal for any product, not just polls

A pre-launch security checklist for Next.js + Supabase (from a real launch)

1. Close Supabase's default grants

2. RLS policies that call one function, once

3. A CSP that doesn't kill ISR

4. An open-redirect-proof ?next=

5. GDPR export and delete that go through the same doors

6. Alert when the cron job quietly stops

7. Test it all in a transaction that always rolls back

The checklist, short version

FAQ

Does Supabase expose new tables to anon and authenticated by default?

Can I use a strict nonce-based CSP with Next.js ISR?

How do I prevent open redirects with a ?next= parameter in Next.js?

How do I test Supabase migrations without touching the database?

AI agent development cost: what actually moves the number (2026)

The three costs people mix up

What actually moves the build number

Running cost: model rates you can verify (as of Oct 2026)

Build vs buy vs hire

When it's worth it / when it's not

Verdict

FAQ

How much does it cost to build an AI agent in 2026?

What does it cost to run an AI agent after you build it?

Is it cheaper to buy a SaaS chatbot than to build a custom AI agent?

When is it worth hiring an AI engineer to build an agent?

Do I need LangChain or an agent framework in the budget?

Claude vs GPT for AI agents: what I actually ship with (2026)

Claude vs GPT at a glance (as of October 2026)

Where they actually differ for agent builders

The API shape

Caching control

Long context billing

Hosted tools

What I actually run in production (and why)

Claient: a multi-tenant WhatsApp agent on Haiku

Pollitics: two models, two jobs

So why Claude?

When to use which

FAQ

Is Claude or GPT better for building AI agents in 2026?

Is Claude more expensive than GPT for agents?

Can I switch an agent from Claude to GPT later?

Which model does Joan Comadran use for production AI agents?

Do I need LangChain or another framework to build an agent with Claude or GPT?

4. An open-redirect-proof `?next=`