[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-openai-pricing-turns-token-math-into-budgets-en":3,"article-related-openai-pricing-turns-token-math-into-budgets-en":30,"series-tools-aad700b5-14b0-4350-83d9-33610b119087":82},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"aad700b5-14b0-4350-83d9-33610b119087","openai-pricing-turns-token-math-into-budgets-en","OpenAI pricing turns token math into budgets","\u003Cp data-speakable=\"summary\">This breaks \u003Ca href=\"\u002Ftag\u002Fopenai\">OpenAI\u003C\u002Fa> pricing into a budgeting template you can copy.\u003C\u002Fp>\u003Cp>I've been using OpenAI models long enough to know the pricing page is where optimism goes to die a little. The first time I wired a real product to the \u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa>, I thought I had the math under control. Then I hit cached input, batch pricing, flex pricing, priority pricing, and a bunch of model variants that all looked similar until the invoice showed up. That’s the annoying part: the docs are clear, but they’re clear in a way that makes you do spreadsheet work at 11 p.m.\u003C\u002Fp>\u003Cp>What I wanted was simple. Tell me what a \u003Ca href=\"\u002Ftag\u002Ftoken\">token\u003C\u002Fa> costs, tell me what changes when I move from standard to batch, and tell me which models are cheap enough for broad usage without me playing guessing games. The \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing\">OpenAI pricing page\u003C\u002Fa> does have that information, but it’s buried under a lot of product chrome and several pricing tables that need to be read like a contract, not a brochure. I dug through it because I wanted a clean way to budget prompts, outputs, and realtime usage before my team shipped something expensive by accident.\u003C\u002Fp>\u003Cp>So this is me decomposing the page the way I wish someone had done for me: not just what the numbers are, but how to think about them when you’re planning a feature, a model mix, or a monthly spend cap.\u003C\u002Fp>\u003Cp>The source I’m working from is OpenAI’s own pricing doc at \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing\">developers.openai.com\u002Fapi\u002Fdocs\u002Fpricing\u003C\u002Fa>. I’m also linking a few related docs as I go, because pricing only makes sense when you connect it to \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fprompt-caching\">prompt caching\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fbatch\">batch\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Frealtime\">realtime\u003C\u002Fa> behavior.\u003C\u002Fp>\u003Ch2>Stop reading the table like it’s one price\u003C\u002Fh2>\u003Cblockquote>Prices per 1M tokens.\u003C\u002Fblockquote>\u003Cp>What this actually means is that OpenAI is charging you per token bucket, not per request. If you only look at the headline model name, you miss the real cost drivers: input tokens, cached input tokens, output tokens, and then whatever execution mode you picked. That’s why a “cheap” model can still get expensive if your prompts are bloated or your outputs are rambling.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781436806476-wy8s.png\" alt=\"OpenAI pricing turns token math into budgets\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>I ran into this when I had a feature that looked harmless on paper. Short prompt, short response, tiny UI. But the prompt template had a giant system message plus repeated context, and the model was generating more than I expected. The invoice didn’t care that the UX felt small. It cared about token volume.\u003C\u002Fp>\u003Cp>How to apply it: price every feature as a function of three things, not one. I use this mental model:\u003C\u002Fp>\u003Cul>\u003Cli>input cost for what I send\u003C\u002Fli>\u003Cli>output cost for what the model writes back\u003C\u002Fli>\u003Cli>execution multiplier for batch, flex, priority, or realtime\u003C\u002Fli>\u003C\u002Ful>\u003Cp>That’s the only way the pricing page becomes useful. Otherwise you’re just staring at a menu.\u003C\u002Fp>\u003Ch2>GPT-5.5 is the expensive default, not the universal default\u003C\u002Fh2>\u003Cblockquote>\u003Cpre>\u003Ccode>gpt-5.5 $5.00 $0.50 $30.00\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fblockquote>\u003Cp>OpenAI lists \u003Ca href=\"https:\u002F\u002Fopenai.com\u002Findex\u002Fgpt-5-5\u002F\">gpt-5.5\u003C\u002Fa> as the flagship model in the pricing table, and the numbers tell you exactly why I wouldn’t make it my default for every request. Standard pricing shows $5.00 per 1M input tokens, $0.50 per 1M cached input tokens, and $30.00 per 1M output tokens. That output price is the one that bites when your app asks for long, polished answers.\u003C\u002Fp>\u003Cp>What this actually means is that GPT-5.5 is something I’d reserve for cases where quality matters enough to justify the spend. Think final answers, tricky reasoning, or user-facing responses where a weak model would create support debt. I would not use it as the first hop in every workflow just because it’s the top of the table.\u003C\u002Fp>\u003Cp>I’ve made that mistake before. I built systems where the “best” model handled everything, then spent days trying to explain why a feature with modest traffic was burning through budget. The fix was boring: route easy work to cheaper models, keep the flagship for the hard stuff, and stop pretending every task deserves the premium tier.\u003C\u002Fp>\u003Cp>How to apply it: define a model routing policy before you write prompts. A simple rule works better than vibes:\u003C\u002Fp>\u003Cul>\u003Cli>cheap model for extraction, classification, and drafts\u003C\u002Fli>\u003Cli>mid-tier model for user-facing general responses\u003C\u002Fli>\u003Cli>flagship model for final synthesis or difficult reasoning\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you want the direct model docs, keep \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fmodels\">OpenAI’s models page\u003C\u002Fa> open while you budget. Pricing only makes sense alongside model capability.\u003C\u002Fp>\u003Ch2>Cached input is the discount you earn by not being sloppy\u003C\u002Fh2>\u003Cblockquote>\u003Cpre>\u003Ccode>gpt-5.5 $0.50 cached input\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fblockquote>\u003Cp>Cached input is one of those things that sounds abstract until you realize it’s basically a reward for repeating yourself efficiently. In the standard GPT-5.5 row, cached input is $0.50 per 1M tokens instead of $5.00. That’s a 10x difference, and it matters if you keep sending the same long system prompt, policy block, or tool schema over and over.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781436796529-xln4.png\" alt=\"OpenAI pricing turns token math into budgets\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>What this actually means is that prompt structure is a pricing decision. If your app keeps resending giant static context, caching can soften the bill. If you keep changing the prompt shape every time, you’re leaving money on the table.\u003C\u002Fp>\u003Cp>I ran into this with a support assistant that had a huge base instruction set. At first I thought the only way to control cost was to shorten the prompt. That helped, but the bigger win was making the static portion stable enough to benefit from caching. Once the prompt stopped mutating every request, the pricing got a lot less ugly.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>separate static instructions from user-specific context\u003C\u002Fli>\u003Cli>keep reusable blocks byte-stable when possible\u003C\u002Fli>\u003Cli>measure cache hit rate before and after prompt edits\u003C\u002Fli>\u003C\u002Ful>\u003Cp>The relevant doc here is \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fprompt-caching\">prompt caching\u003C\u002Fa>. If you’re not using it, you’re probably paying for the same words more than once.\u003C\u002Fp>\u003Ch2>Batch and flex are where boring workloads get cheaper\u003C\u002Fh2>\u003Cblockquote>\u003Cpre>\u003Ccode>gpt-5.5 batch $2.50 input $15.00 output\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fblockquote>\u003Cp>The pricing page splits standard, batch, flex, and priority into separate tables. That’s not decoration. It’s OpenAI telling you that workload shape matters. Batch pricing for GPT-5.5 drops to $2.50 per 1M input tokens and $15.00 per 1M output tokens in the short-context table, which is meaningfully cheaper than standard.\u003C\u002Fp>\u003Cp>What this actually means is that if your job doesn’t need an immediate answer, you should stop paying interactive prices. Summaries, offline analysis, report generation, enrichment pipelines, and backfills are all obvious batch candidates. Flex is in the same family of thinking: if you can tolerate different scheduling behavior, you can usually cut cost.\u003C\u002Fp>\u003Cp>I’ve seen teams burn money because they treated every task like a chat message. That’s lazy architecture. A nightly classification job does not need the same billing mode as a live customer support reply. The pricing page is basically begging you to separate those cases.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>use batch for async jobs and large backfills\u003C\u002Fli>\u003Cli>use flex when latency can move around a bit\u003C\u002Fli>\u003Cli>reserve priority for user paths where delay is expensive\u003C\u002Fli>\u003C\u002Ful>\u003Cp>For the mechanics, I’d pair this with the \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fbatch\">batch guide\u003C\u002Fa> and the \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fproduction-best-practices\">production best practices\u003C\u002Fa> docs. Pricing without workload classification is just expensive guesswork.\u003C\u002Fp>\u003Ch2>Priority pricing is what you pay when waiting is the bug\u003C\u002Fh2>\u003Cblockquote>\u003Cpre>\u003Ccode>gpt-5.5 priority $12.50 input $75.00 output\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fblockquote>\u003Cp>Priority pricing is a blunt instrument. For GPT-5.5, the page shows $12.50 per 1M input tokens and $75.00 per 1M output tokens in the priority table. That is not the mode I’d use because it looks nice in a dashboard. I’d use it when latency is the product.\u003C\u002Fp>\u003Cp>What this actually means is that some requests have a business cost beyond token count. If a user is waiting on a live workflow, or if a delay blocks conversion, then the higher rate may be cheaper than the lost revenue or the support headache. But you should say that out loud. Don’t just switch to priority because the app feels slow and you’re tired of investigating it.\u003C\u002Fp>\u003Cp>I ran into this with a workflow that had a painful tail latency problem. The team wanted to throw priority at everything. We didn’t. We traced the slow path, fixed the bottleneck, and only used higher-priority processing for the requests that actually needed it. That saved money and kept us honest.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>define a latency budget per endpoint\u003C\u002Fli>\u003Cli>use priority only for paths with real user or revenue impact\u003C\u002Fli>\u003Cli>compare cost of delay against cost of tokens\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you’re building around realtime or interactive experiences, also read \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Frealtime\">realtime\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Flatency-optimization\">latency optimization\u003C\u002Fa>. Otherwise you’ll confuse “fast enough” with “expensive enough.”\u003C\u002Fp>\u003Ch2>Mini and nano are the parts of the table I trust the most\u003C\u002Fh2>\u003Cblockquote>\u003Cpre>\u003Ccode>gpt-5.4-mini $0.75 input $4.50 output\ngpt-5.4-nano $0.20 input $1.25 output\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fblockquote>\u003Cp>These lower-cost models are the ones I reach for when the task is narrow. The pricing page shows gpt-5.4-mini at $0.75 input and $4.50 output per 1M tokens in the standard table, while gpt-5.4-nano drops to $0.20 input and $1.25 output. That’s the part of the page that makes practical product work possible.\u003C\u002Fp>\u003Cp>What this actually means is that not every request needs a heavyweight model. If you’re extracting fields, tagging content, classifying intent, or generating first-pass drafts, smaller models are usually the sane move. They’re easier to budget, easier to scale, and less likely to turn a simple path into a finance problem.\u003C\u002Fp>\u003Cp>I’ve had success using smaller models as front-line workers. They handle the repetitive stuff, and only the messy edge cases get escalated. That pattern is boring, which is exactly why it works.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>start with mini or nano for structured tasks\u003C\u002Fli>\u003Cli>escalate only when confidence is low or the task is ambiguous\u003C\u002Fli>\u003Cli>track accuracy against spend, not just raw quality\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you need a reminder on output discipline, the \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fstructured-output\">structured output\u003C\u002Fa> guide is worth keeping nearby. Cheap models get a lot more useful when you constrain the shape of the answer.\u003C\u002Fp>\u003Ch2>Realtime pricing is a different animal, so budget by minute and modality\u003C\u002Fh2>\u003Cblockquote>\u003Cpre>\u003Ccode>gpt-realtime-2 Audio $32.00 input $64.00 output\nrealtime-translate $0.034 \u002F minute\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fblockquote>\u003Cp>The multimodal section shifts the pricing model again. For \u003Ca href=\"https:\u002F\u002Fopenai.com\u002Findex\u002Fintroducing-gpt-realtime\u002F\">gpt-realtime-2\u003C\u002Fa>, OpenAI lists Audio at $32.00 input and $64.00 output per 1M tokens, Text at $4.00 input and $24.00 output, and Image at $5.00 input and $0.50 cached input. There’s also \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Frealtime\">gpt-realtime-translate\u003C\u002Fa> at $0.034 per minute. That is not token math in the same way as chat completions. It’s usage math.\u003C\u002Fp>\u003Cp>What this actually means is that realtime systems need a separate budget model. If your app does live transcription, voice response, or translation, don’t force that usage into the same mental bucket as text generation. The unit economics are different, and the UX expectations are different too.\u003C\u002Fp>\u003Cp>I ran into this when I tried to compare a voice feature against a text feature using the same spreadsheet columns. Bad idea. Once I separated minutes, audio tokens, and text tokens, the picture got clearer. Realtime is often worth it, but only if you know what you’re paying for.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>budget realtime by session length and modality\u003C\u002Fli>\u003Cli>estimate peak and average minutes separately\u003C\u002Fli>\u003Cli>treat translation and speech generation as distinct cost centers\u003C\u002Fli>\u003C\u002Ful>\u003Cp>For implementation details, I’d keep the \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Frealtime-voice-agents\">voice agents\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Ftranscription\">transcription\u003C\u002Fa> docs open while you model cost. Realtime billing gets messy fast if you wing it.\u003C\u002Fp>\u003Ch2>Regional processing and Bedrock add two more wrinkles\u003C\u002Fh2>\u003Cblockquote>\u003Cpre>\u003Ccode>Regional processing ... charged a 10% uplift\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fblockquote>\u003Cp>OpenAI says regional processing endpoints are charged a 10% uplift for models released on or after March 5, 2026, that are eligible for data residency. The page also notes that OpenAI models in \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fbedrock\u002F\">Amazon Bedrock\u003C\u002Fa> are billed through \u003Ca href=\"\u002Ftag\u002Faws\">AWS\u003C\u002Fa> and may differ from direct OpenAI pricing.\u003C\u002Fp>\u003Cp>What this actually means is that compliance and procurement can change your math. If you need data residency, you may pay more. If you buy through a cloud marketplace or another platform, the bill may not match the direct API table exactly. That’s normal, but you need to account for it before someone asks why the forecast is off.\u003C\u002Fp>\u003Cp>I’ve seen teams assume the public pricing page was the final answer. It usually isn’t once enterprise constraints show up. Geography, procurement path, and platform choice all matter.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>separate direct API pricing from reseller pricing\u003C\u002Fli>\u003Cli>flag data residency requirements early\u003C\u002Fli>\u003Cli>add a compliance uplift line item in forecasts\u003C\u002Fli>\u003C\u002Ful>\u003Cp>For the policy side, OpenAI’s \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fyour-data\">Your data\u003C\u002Fa> guide is the place to start. It’s the part of the pricing story nobody wants to think about until procurement does.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># OpenAI cost planning template\n\n## 1) Pick the workload\n- Workload name:\n- User-facing or async:\n- Latency target:\n- Compliance \u002F data residency needed:\n- Direct API or reseller path:\n\n## 2) Choose the execution mode\n- Standard \u002F Batch \u002F Flex \u002F Priority \u002F Realtime:\n- Why this mode fits:\n- What would make me switch modes:\n\n## 3) Choose the model tier\n- Primary model:\n- Fallback model:\n- Escalation rule:\n- Reason the primary model is enough:\n\n## 4) Estimate usage\n- Requests per day:\n- Average input tokens per request:\n- Average cached input tokens per request:\n- Average output tokens per request:\n- Average session minutes if realtime:\n\n## 5) Fill in pricing inputs\n- Input price per 1M tokens:\n- Cached input price per 1M tokens:\n- Output price per 1M tokens:\n- Minute-based price if applicable:\n- Regional uplift if applicable:\n- Platform billing uplift if applicable:\n\n## 6) Calculate monthly cost\n- Monthly input tokens = requests\u002Fday × 30 × avg input tokens\n- Monthly cached input tokens = requests\u002Fday × 30 × avg cached input tokens\n- Monthly output tokens = requests\u002Fday × 30 × avg output tokens\n- Monthly realtime minutes = sessions\u002Fday × 30 × avg minutes\n\n## 7) Cost formula\n- Input cost = monthly input tokens ÷ 1,000,000 × input price\n- Cached input cost = monthly cached input tokens ÷ 1,000,000 × cached input price\n- Output cost = monthly output tokens ÷ 1,000,000 × output price\n- Realtime cost = monthly minutes × minute price\n- Subtotal = sum of the above\n- Uplift = subtotal × regional uplift if needed\n- Total = subtotal + uplift\n\n## 8) Routing policy\n- Use cheap model for:\n- Escalate to stronger model when:\n- Use batch for:\n- Use priority only for:\n- Use realtime only for:\n\n## 9) Guardrails\n- Monthly budget cap:\n- Alert threshold:\n- Max output tokens:\n- Max session length:\n- Review cadence:\n\n## 10) Notes\n- Link to pricing page:\n- Link to workload doc:\n- Link to prompt caching or batch docs:\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>This is the version I’d actually hand to a team before they ship. It forces the conversation away from model hype and toward spend, routing, and workload shape. If you want to make it more useful, add a column for observed vs estimated cost after the first week in production.\u003C\u002Fp>\u003Cp>Source: \u003Ca href=\"https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing\">https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing\u003C\u002Fa>. This breakdown is mine, but the pricing numbers and table structure come from OpenAI’s docs. If you’re using this in a real system, verify the live page before you lock budgets, because pricing changes and I would never trust a stale copy-paste for finance.\u003C\u002Fp>","A practical breakdown of OpenAI pricing, with a copy-ready cost template you can drop into your own planning sheet.","developers.openai.com","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781436806476-wy8s.png","tools","en","4e519cd3-4dcd-41b6-8ff1-66a58921acf7",[17,18,19,20,21],"OpenAI pricing","token costs","batch","prompt caching","realtime",[23,24,25],"Price by workload, not by model name alone.","Cached input and batch can cut costs fast.","Realtime and regional processing need separate budgets.",0,"2026-06-14T11:32:54.284793+00:00","2026-06-14T11:32:54.273+00:00","a7343b93-37cc-4634-a2bc-707f6275bdb6",{"tags":31,"relatedLang":41,"relatedPosts":45},[32,35,36,38,40],{"name":33,"slug":34},"Prompt Caching","prompt-caching",{"name":19,"slug":19},{"name":17,"slug":37},"openai-pricing",{"name":18,"slug":39},"token-costs",{"name":21,"slug":21},{"id":15,"slug":42,"title":43,"language":44},"openai-pricing-turns-token-math-into-budgets-zh","OpenAI 定價把 token 算成預算","zh",[46,52,58,64,70,76],{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"category":13},"6c73d853-b09f-4d14-ab64-549e19726135","cursors-latest-update-ide-workflow-tools-en","Cursor’s latest update proves IDEs must become workflow tools","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781491673281-ub6v.png","2026-06-15T02:47:20.88317+00:00",{"id":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"category":13},"33220b48-098e-4417-90f2-681787bbb128","cursor-bugbot-before-push-not-pr-en","Cursor’s Bugbot belongs before the push, not in the PR","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781490763751-pnh5.png","2026-06-15T02:32:16.801116+00:00",{"id":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"category":13},"6997fa46-16f8-48bd-80dc-fe20f08815a2","prompt-engineering-writing-skill-not-magic-trick-en","Prompt engineering is a writing skill, not a magic trick","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781470978720-rxo2.png","2026-06-14T21:02:28.362525+00:00",{"id":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"category":13},"50c2cc6b-fdf4-425a-aa80-05be0dee9815","open-notebook-turns-notebooklm-into-open-source-en","Open-Notebook turns NotebookLM into open source","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781450301942-cx4t.png","2026-06-14T15:17:50.526134+00:00",{"id":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"category":13},"1871beaf-fb67-4bc8-bffc-0b2cca267767","gpu-mag-list-turns-gpu-tests-into-workflow-en","GPU Mag’s list turns GPU tests into a workflow","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781440408229-5thl.png","2026-06-14T12:33:00.989747+00:00",{"id":77,"slug":78,"title":79,"cover_image":80,"image_url":80,"created_at":81,"category":13},"a5e7ea7e-7b48-4705-9e18-7f864a8e3c75","dockerd-docs-proxy-registry-bridge-flags-en","dockerd docs add proxy, registry, and bridge flags","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781434064814-z098.png","2026-06-14T10:47:22.306566+00:00",[83,88,93,98,103,108,113,118,123,128],{"id":84,"slug":85,"title":86,"created_at":87},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":129,"slug":130,"title":131,"created_at":132},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]