How to build an AI content studio with OpenAI Codex

Rule of thumb: if what you need is posts going out on a schedule to several accounts, with analytics afterwards and somebody else absorbing each platform’s API changes, rent, and Buffer’s free tier in particular is hard to argue with for one person and three channels. If what you need is a lot of generations in your own brand, kept in your own library, at the provider’s price rather than a credit bundle’s, that is the half worth owning. The comparison that decides it is arithmetic you can do in a minute: work out how many images you would actually generate in a month, price them at your provider’s rate, and hold that against $19 for about eighty-six. Below a few dozen, renting wins on effort alone. Well above it, the credit bundles are the expensive part, and the thing you have to build in exchange is the ceiling those bundles were quietly providing.

* On this template the free-tier line to watch is the 1 GB of file storage rather than the database. Generated images accumulate faster than anything else in this catalogue, and a few hundred of them will pass it. Pro, from $25/mo, takes file storage to 100 GB (then $0.0213 per GB) and egress to 250 GB (then $0.09 per GB), and keeps a daily backup for 7 days. It also ends the pause, which matters here for a dull reason: a free project sleeps after a quiet week, and a studio you open when inspiration strikes is exactly the sort that goes quiet.

A credit bundle is the pack of generations a rented studio sells you each month, and neither column above buys one, because your own provider key is billed at the provider’s list price instead. What that leaves is a difference in which line grows. Renting means a monthly floor and a credit allowance that runs out in a busy week, whichever way your usage goes. Owning means a small fixed bill and a provider charge that tracks exactly what you made, cheaper on a quiet month, and genuinely open-ended on a busy one unless you have set a limit. That trade suits somebody making a lot of content, which is the only reason to build this at all.

Prices and rates from supabase.com, developex.com and learn.chatgpt.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   AGENTS.md before there is a project to describe

   That file is re-read at the start of every task you hand over, which makes it the cheapest place for the two constraints this build depends on.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind and the Supabase JS client, and this project is an AI content studio. Fix the vocabulary (workspace, asset, generation, prompt, brand kit, caption variant, post, preview) and record two standing constraints. First: a model provider key never reaches the browser, so every model call happens in a server-side function, and whatever comes back is written into my own storage before anything links to it, never a provider URL that can expire. Second: every model call is logged and checked against a configurable limit before it is made, because each call is a charge on my card and a signed-in user is not a spending cap. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots.

   The second constraint is the one worth writing down rather than saying. It will not be re-derived from context three tasks later, and the natural implementation of "add image generation" has no limit in it at all.

2. 02

   One task for the schema, the accounts and the boundary

   Three things that are really one on this app: a workspace is what an account belongs to, and every access rule reduces to it. Read the policies as SQL rather than the summary of them.

   PromptModel it and draw the boundaryCopy

   One task, with a workspace reference on every table from the start. Supabase migrations for: workspaces. Profiles linking an account to exactly one workspace. Assets with a type, a source of generated, ai-edited or uploaded, a storage path, dimensions, a mime type and the prompt that produced it. Posts with a title, a caption, hashtags, asset ids and a preview configuration. Caption variants belonging to a post with a primary flag. A brand kit per workspace with colours, a logo path and a voice paragraph. A generations log with the account, model, prompt, size, quality, outcome and estimated cost. Then Supabase Auth for email and password with a trigger creating a workspace and profile per new account. Then row-level security on every table: reachable only from the person’s workspace, explicit WITH CHECK on every insert and update, and the profile update policy must forbid changing which workspace it points at, since that column is what every other policy resolves to. Show me every policy as SQL before it runs, then walk me through proving with two accounts that the second workspace cannot read the first’s assets or posts.

   Read the profile policy hardest in that diff. Which row you may edit and what that row may become are two different questions, and the second one is the whole workspace boundary. It is a single clause, and it is the clause a reasonable-looking policy leaves out.

3. 03

   Give the generation function its own task, and the ceiling with it

   The task that decides both whether this app works and what it costs. Ask for the function and the limit in one go, because a diff that adds the cap later is a diff you might not get to.

   PromptGenerate one image, with a ceilingCopy

   One task, image generation with its ceiling. A server-side function with my provider key in the function secrets and nowhere else. It takes a prompt, a size and a style, requires a signed-in user and returns 401 otherwise, and before calling the model it writes to the generations log and checks two configurable limits (per account over a rolling window, and a workspace total) returning a clear limit message rather than an error when either is hit. The limit and the cost estimate are computed on the server. Nothing about them is accepted from the client. When the model responds, handle both shapes (base64 in the body and a URL), write the bytes into my own storage under the workspace, and insert an asset row carrying the prompt. In the diff, mark every place you have assumed something about the provider’s response format, because those are the lines I want to read first. Then build the prompt-box screen, and prove the ceiling refuses an eleventh call with the limit set to ten.

   That instruction to mark the response-format assumptions is the review. A provider returning base64 where the code expected a URL fails in a way that looks like a broken image rather than an error, and it is much easier to read four marked lines than to find them later from a blank thumbnail.

4. 04

   The library and the edit path, as one task with a rule in it

   Contained work with one decision worth stating up front: an AI edit produces a new asset, never a replacement for the one you liked.

   PromptBuild the library and the editorCopy

   One task. The asset library over the assets table: a grid filtered by type and source, the prompt visible on generated assets, a detail view and delete. Uploading my own files into the same library and the same storage, differing from a generation only by the source field. Then the edit path: a function taking an existing asset and a description of a change, calling the image model in edit mode, and saving the result as a new asset recording both the original it derived from and the instruction given. The original is never overwritten, and this goes through the same log and ceiling as generation. Add a crop tool and simple adjustments done locally with no model call, and make an uploaded video preview rather than render a broken thumbnail. Show me the diff for the edit function before it runs, and afterwards show me an edit whose original is still in the library.

   Ask for that diff specifically. The edit function is the one place in this build where a plausible implementation destroys data (overwriting the asset row rather than inserting a new one) and it is a two-line difference that reads fine either way.

5. 05

   One task for the writing, and three variants rather than one

   The brand kit and the caption function. Tightly specified, self-contained, and fair to hand off, with one instruction that changes the output more than any other.

   PromptAdd captions, hashtags and the brand kitCopy

   One task. The brand kit screen first: colours, a logo upload into storage, and a paragraph describing the voice to write in, stored per workspace. Then caption generation as a server-side function taking a post and its selected assets, sending my brand voice paragraph verbatim with the title, and returning three distinct variants stored as rows against the post with one marked primary, not a single string overwritten on each call. Then hashtag suggestions running from the caption I kept rather than the title. Both go through the same log and ceiling as the image calls. In the interface, show the three variants together with the chosen one marked and let me edit any by hand. Nothing I have typed is rewritten by the model unless I ask for it.

   Read the diff for whether the three variants are three rows or one string with separators. The second version works on the day it ships and quietly loses your alternatives forever, which is the whole reason for asking for three.

6. 06
   Destination

   Send the previews to a cloud run, then make something real

   The five frames and the export are tightly specified and self-contained, which makes them fair to hand off and walk away from. The post you actually make at the end catches what a diff never will.

   PromptBuild the previews, the export, and rehearseCopy

   Two pieces, the first contained enough to run unsupervised. First, the post builder and the previews: a title, assets chosen from the library, the caption and hashtags from the previous task, and a preview switching between Instagram, X, Facebook, LinkedIn and TikTok with the aspect ratio and feed type stored on the post. Each frame exactly right rather than approximately: correct aspect ratios, the caption truncation each network applies, and a visible warning when the image does not match the selected platform’s ratio. Then a per-platform download of the rendered post, and a dashboard with recent assets, recent posts, and this period’s generation count and estimated spend. Second, and I want this one reviewed rather than delegated: check the estimated-cost arithmetic in the generations log against my provider’s published prices and tell me where the estimate could drift. Then make one real post with me end to end (generate, edit once, three captions, hashtags, preview, download) and compare the dashboard’s spend against my provider’s own usage page.

   Keep the cost arithmetic out of the cloud run. It is the one piece here whose output is a number you will trust later without re-checking, and a plausible-looking estimate that is wrong by a factor is worse than showing nothing at all.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks the rest here: the database service key and the model provider key belong on the server only: never in the app your team downloads, and never in a repository. Either one that gets out is burned, and the provider key is the one somebody will actually spend: replace it the same day and check your usage dashboard for what was done with it.

All eight serve the app well enough that speed is not the deciding question. Three others are: whether the plan permits commercial use, since Vercel’s Hobby tier does not. Whether it publishes from a private repository, given the key sitting next to this code. And whether a deep link resolves for a browser that has never seen your site, because a link to one asset is what you will paste to somebody asking which picture you meant.

Add a generations table that records every model call (who made it, which workspace, which model, the prompt, the size and quality asked for, whether it succeeded, and a cost estimate) and write to it from all four AI functions, images included. Then add a ceiling: a limit per person per rolling window and a workspace total, both settings I can change, checked inside each function before it calls the provider and returning a clear "you have reached your limit for today" rather than an error. Add a small usage panel showing calls and estimated spend for the current period, by person. Do not let the client send the limit or the cost. Both are read on the server.

Add a "make a set from this" action on an asset. Take the stored prompt, generate the same subject at each aspect ratio I have platforms for, and show them as a group I accept or discard together, with the cost estimate for the whole set shown before I confirm. Reuse the ceiling from the generations table so a set counts as its number of images and not as one. Keep the group linked to the original asset so the library shows them together rather than as five unrelated pictures.

When drafting a caption, send the selected image to the model alongside my brand kit and any title I have written, and ask for three variants that refer to what is actually in the picture. Keep all three against the post and mark the one I choose. Send the brand voice paragraph verbatim and nothing else about my other posts. Where the image is ambiguous, have it say so in a short note beside the variants rather than inventing a detail. A caption confidently describing something that is not in the photograph is the failure worth designing against.

Add a pre-export check on a post. Compute what you can (caption length against each platform’s limit, hashtag count, whether the image matches the aspect ratio for the chosen feed type) and show those as plain pass or fail with the actual numbers. Then send only the caption and the platform to my ai function for one line on anything that reads badly for that audience. Never rewrite my caption automatically, never call the model for the arithmetic, and show which checks are computed and which are an opinion.

Add a panel that answers questions about my own library and posts. Compute the figures with queries (assets by type and month, generations that never made it into a post, which caption variant position I choose most often, the prompts I have reused) and use the model only to describe what the numbers suggest. Show the query and the counts under every answer, state the period, and where the sample is too small to mean anything, say so instead of finding a pattern in nine posts.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.