DEV Community: smakosh

Top 10 Cheapest Providers for DeepSeek V3.2 in 2026

smakosh — Thu, 02 Apr 2026 12:22:10 +0000

DeepSeek V3.2 has quickly become one of the most popular open-weight models in production. It replaced both V3 and R1 with a unified model that handles chat and reasoning at a single price point, ships a 163K context window, and scored gold on the 2025 IMO and IOI benchmarks — all for under $0.50 per million tokens.

But where you access V3.2 matters just as much as the model itself. Depending on the provider, you could pay anywhere from $0.18/M to $0.57/M for input tokens. Over millions of daily requests, that difference adds up fast.

We pulled pricing from every major provider and ranked them so you don't have to.

The Ranking

Rank	Provider	Input (per 1M)	Output (per 1M)	Cached Input	Notes
1	LLM Gateway	$0.182	$0.28	$0.036	Auto-routed via Canopywave, 30% discount applied
2	GMI	$0.20	$0.32	—	Lowest blended price on Artificial Analysis
3	LLM Gateway (Alibaba cn-beijing)	$0.23	$0.345	$0.046	20% Alibaba Cloud discount applied
4	OpenRouter	$0.26	$0.38	—	Multi-provider routing, free tier available
5	DeepInfra	$0.26	$0.38	—	Serverless, pay-per-token
6	Novita AI	$0.269	$0.40	$0.135	High-throughput serverless
7	SiliconFlow (FP8)	$0.27	$0.42	—	Budget FP8 quantized endpoint
8	DeepSeek (Official)	$0.28	$0.42	$0.028	Direct API, 90% cache discount
9	Volcengine (Bytedance)	$0.28	$0.42	$0.056	Asia-optimized, reasoning mode
10	Fireworks AI	$0.30+	$0.45+	—	Fastest output speed (211 t/s)

Pricing as of March 2026. "Cached Input" refers to prompt cache hit pricing where available.

Why LLM Gateway Tops the List

LLM Gateway doesn't host models — it routes your requests to the cheapest available provider for each model, automatically. For DeepSeek V3.2, that currently means Canopywave with an exclusive 30% discount negotiated on your behalf.

Here's what that looks like in practice:

Input tokens: $0.26/M base → $0.182/M after 30% discount
Output tokens: $0.40/M base → $0.28/M after 30% discount
Cached input: $0.052/M base → $0.036/M after 30% discount

That's 35% cheaper than the official DeepSeek API and 9% cheaper than GMI (the next lowest provider). If Canopywave ever goes down, your requests automatically fail over to the next cheapest provider — Novita, Alibaba, Bytedance, or DeepSeek direct — with zero configuration.

Real Cost at Scale

Cheap per-token pricing only matters if you can quantify the actual savings for your workload. That's why we built the Token Cost Calculator.

Here's a quick example. Say you're running a production chatbot doing 10M input tokens and 1M output tokens per day:

Provider	Daily Cost	Monthly Cost	Annual Cost
DeepSeek (Official)	$3.22	$96.60	$1,175.30
OpenRouter	$2.98	$89.40	$1,087.70
GMI	$2.32	$69.60	$846.80
LLM Gateway	$2.10	$63.00	$766.50

That's $408.80 saved per year compared to the official DeepSeek API — just on one model. If you're using multiple models across providers, the savings compound.

How to Calculate Your Exact Savings

The Token Cost Calculator lets you:

Select any model from 100+ options across all major providers
Set your token volumes — choose from presets (Light, Medium, Heavy, Intensive) or enter custom numbers
Compare side-by-side — see official provider pricing vs. LLM Gateway's cheapest route
Add multiple models — building with GPT-4o, Claude, and DeepSeek? Add all three and see your total savings
Share your results — export your cost breakdown to X, LinkedIn, or clipboard

The calculator pulls pricing directly from the live model registry, so it's always up to date. No sign-up required.

Try the Token Cost Calculator →

Factors Beyond Price

Price isn't everything. Here's what else to consider when choosing a DeepSeek V3.2 provider:

Speed: Fireworks leads at 211 tokens/second output. Google Vertex and Azure follow at ~207 t/s. If latency matters more than cost, pay the premium.
Reliability: The official DeepSeek API can have variable availability during peak hours. Third-party providers typically offer better uptime SLAs.
Cache discounts: DeepSeek's official API offers a 90% discount on cached input tokens ($0.028/M vs $0.28/M). If your workload has high prompt reuse, this can offset higher base pricing.
Context window: Most providers offer the full 163K context. Alibaba and Bytedance cap at 131K.
Feature support: Not all providers support tool calling or JSON output mode. LLM Gateway's smart routing only sends requests to providers that support the features you're using.

Getting Started

Switch to the cheapest DeepSeek V3.2 pricing in under a minute:

Sign up free — no credit card required
Use the OpenAI-compatible API — just change your base URL:

curl https://api.llmgateway.io/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek/deepseek-v3.2",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Calculate your savings with the Token Cost Calculator

No vendor lock-in. No platform fees. Just the cheapest path to every model.

Build an AI-Powered QA Agent with Agent Browser, Vercel AI SDK, and LLM Gateway

smakosh — Mon, 02 Mar 2026 14:20:07 +0000

What if you could test your web app by just describing what to test in plain English? No Selenium scripts, no Cypress configs — just tell an AI agent "test the signup flow" and watch it navigate, click, type, and verify results in a real browser.

That's exactly what we're building in this article: a QA testing agent that combines Agent Browser for headless browser control, the Vercel AI SDK for tool-calling orchestration, and LLM Gateway as the unified LLM provider.

The full source code is available at github.com/theopenco/llmgateway-templates/templates/qa-agent.

How It Works

The architecture is straightforward:

User describes a test in natural language (e.g., "Navigate to the login page, enter invalid credentials, and verify an error is shown")
Vercel AI SDK sends the prompt to an LLM via LLM Gateway with browser tools attached
The LLM decides which browser actions to take — navigate, snapshot, click, type, etc.
Agent Browser executes those actions on a real headless Chromium instance
Results stream back in real-time as NDJSON — each step, each screenshot, and a final test summary

The LLM acts as the brain, Agent Browser provides the hands, and LLM Gateway lets you swap between models (Claude, GPT-4o, Gemini) with a single string change.

The Tech Stack

Next.js 16 (App Router) — framework
Vercel AI SDK v6 — generateText with tool calling and stepCountIs for limiting agent loops
@llmgateway/ai-sdk-provider — LLM Gateway's native AI SDK provider
agent-browser — headless browser automation with accessibility snapshots
Zod — tool input schema validation

Setting Up

Install Dependencies

npm install @llmgateway/ai-sdk-provider ai agent-browser zod next react

Environment

# .env.local
LLMGATEWAY_API_KEY=your_api_key_here

Get your API key from llmgateway.io.

Building the Browser Tools

The key insight is that Agent Browser provides accessibility snapshots — a text-based tree of the page with element refs like @e1, @e3. The LLM reads these snapshots to understand the page, then uses refs to click and type. No CSS selectors, no XPaths — just semantic understanding.

Here's how we define the browser tools using the AI SDK's tool() helper:

import { tool } from "ai";
import { BrowserManager } from "agent-browser/dist/browser.js";
import { z } from "zod";

function createBrowserTools(browser: BrowserManager) {
  return {
    browser_navigate: tool({
      description: "Navigate the browser to a URL",
      inputSchema: z.object({
        url: z.string().describe("The URL to navigate to"),
      }),
      execute: async ({ url }) => {
        const page = browser.getPage();
        await page.goto(url, { waitUntil: "domcontentloaded" });
        return { url, title: await page.title() };
      },
    }),

    browser_snapshot: tool({
      description:
        "Get an accessibility snapshot of the current page. Returns a text tree with element refs (e.g. [ref=e1]) that you can use with browser_click and browser_type.",
      inputSchema: z.object({}),
      execute: async () => {
        const snapshot = await browser.getSnapshot({ interactive: true });
        const tree =
          typeof snapshot.tree === "string"
            ? snapshot.tree
            : JSON.stringify(snapshot.tree);
        // Truncate to avoid blowing up context
        const maxChars = 30_000;
        if (tree.length > maxChars) {
          return { snapshot: tree.slice(0, maxChars) + "\n... (truncated)" };
        }
        return { snapshot: tree };
      },
    }),

    browser_click: tool({
      description: "Click an element using its ref from a snapshot (e.g. @e1)",
      inputSchema: z.object({
        ref: z.string().describe("The ref of the element to click"),
      }),
      execute: async ({ ref }) => {
        const locator = browser.getLocator(ref);
        await locator.click();
        return { clicked: ref };
      },
    }),

    browser_type: tool({
      description: "Type text into an input field using its ref",
      inputSchema: z.object({
        ref: z.string().describe("The ref of the input element"),
        text: z.string().describe("The text to type"),
        clear: z.boolean().optional().describe("Clear first (default: true)"),
      }),
      execute: async ({ ref, text, clear = true }) => {
        const locator = browser.getLocator(ref);
        if (clear) {
          await locator.fill(text);
        } else {
          await locator.pressSequentially(text);
        }
        return { typed: text, into: ref };
      },
    }),

    browser_press_key: tool({
      description: "Press a keyboard key (e.g. Enter, Tab, Escape)",
      inputSchema: z.object({
        key: z.string().describe("The key to press"),
      }),
      execute: async ({ key }) => {
        const page = browser.getPage();
        await page.keyboard.press(key);
        return { pressed: key };
      },
    }),

    browser_scroll: tool({
      description: "Scroll the page in a direction",
      inputSchema: z.object({
        direction: z.enum(["up", "down", "left", "right"]),
        amount: z.number().optional().describe("Pixels (default: 500)"),
      }),
      execute: async ({ direction, amount = 500 }) => {
        const page = browser.getPage();
        const deltaX =
          direction === "left" ? -amount : direction === "right" ? amount : 0;
        const deltaY =
          direction === "up" ? -amount : direction === "down" ? amount : 0;
        await page.mouse.wheel(deltaX, deltaY);
        return { scrolled: direction, amount };
      },
    }),

    browser_hover: tool({
      description: "Hover over an element using its ref",
      inputSchema: z.object({
        ref: z.string().describe("The ref of the element to hover"),
      }),
      execute: async ({ ref }) => {
        const locator = browser.getLocator(ref);
        await locator.hover();
        return { hovered: ref };
      },
    }),

    browser_go_back: tool({
      description: "Go back to the previous page",
      inputSchema: z.object({}),
      execute: async () => {
        const page = browser.getPage();
        await page.goBack();
        return { url: page.url() };
      },
    }),
  };
}

Each tool has a clear description (the LLM reads this to decide when to use it), a Zod inputSchema (for validated structured input), and an execute function (the actual browser action).

The API Route: Orchestrating Everything

The core is a Next.js API route that launches the browser, wires up tools, and streams results back:

import { createLLMGateway } from "@llmgateway/ai-sdk-provider";
import { generateText, stepCountIs } from "ai";
import { BrowserManager } from "agent-browser/dist/browser.js";

export const maxDuration = 120;

export async function POST(request: Request) {
  const { instruction, model, targetUrl } = await request.json();

  const llmgateway = createLLMGateway({
    apiKey: process.env.LLMGATEWAY_API_KEY,
  });

  const browser = new BrowserManager();
  const encoder = new TextEncoder();
  let stepCount = 0;

  const stream = new ReadableStream({
    async start(controller) {
      const emit = (data: Record<string, unknown>) =>
        controller.enqueue(encoder.encode(JSON.stringify(data) + "\n"));

      try {
        emit({ type: "status", message: "Launching headless browser..." });

        await browser.launch({
          id: "qa",
          action: "launch",
          headless: true,
        });

        // Stream live screenshots to the frontend
        await browser.startScreencast(
          (frame) => {
            emit({ type: "screenshot", imageData: frame.data });
          },
          {
            format: "jpeg",
            quality: 50,
            maxWidth: 1280,
            maxHeight: 720,
            everyNthFrame: 2,
          }
        );

        emit({ type: "status", message: "Browser ready. Running test..." });

        const tools = createBrowserTools(browser);

        const result = await generateText({
          model: llmgateway(model || "anthropic/claude-sonnet-4-5"),
          tools,
          stopWhen: stepCountIs(25),
          system: `You are a QA testing agent. Your task is to test a web application by interacting with it through a browser.

INSTRUCTIONS:
1. First, navigate to: ${targetUrl}
2. Use browser_snapshot to read the current page state before interacting
3. Execute the test described by the user step by step
4. Use browser_click to click elements (use the ref attribute from snapshots, e.g. @e1)
5. Use browser_type to type text into input fields
6. After completing the test, provide a clear summary of results — what passed, what failed, and why

Be methodical: always snapshot the page before acting so you know what elements are available.`,
          prompt: instruction,
          onStepFinish({ toolCalls, text }) {
            if (toolCalls?.length) {
              for (const call of toolCalls) {
                stepCount++;
                emit({
                  type: "action",
                  step: stepCount,
                  tool: call.toolName,
                  args: call.input,
                  status: "done",
                });
              }
            }
            if (text) {
              emit({ type: "text", content: text });
            }
          },
        });

        emit({ type: "result", summary: result.text });
      } catch (err) {
        const message =
          err instanceof Error ? err.message : String(err);
        emit({ type: "error", message });
      } finally {
        await browser.stopScreencast();
        await browser.close();
        controller.close();
      }
    },
  });

  return new Response(stream, {
    headers: {
      "Content-Type": "application/x-ndjson",
      "Transfer-Encoding": "chunked",
    },
  });
}

Key Details

stopWhen: stepCountIs(25) — This is a safety guardrail from the AI SDK. It prevents the agent from running indefinitely by capping it at 25 tool-calling steps.

onStepFinish — This callback fires after each agent step, letting us stream actions to the frontend in real-time. Users see each click, each navigation as it happens.

Live screencast — Agent Browser streams JPEG frames of the browser viewport via startScreencast. These are forwarded to the frontend as NDJSON events, giving users a live preview of what the agent sees.

NDJSON streaming — Each event is a newline-delimited JSON object. The frontend reads them incrementally to build a real-time action timeline.

Switching Models

Because we're using LLM Gateway, switching the underlying LLM is trivial:

// Anthropic Claude
model: llmgateway("anthropic/claude-sonnet-4-5")

// OpenAI GPT-4o
model: llmgateway("openai/gpt-4o")

// Google Gemini
model: llmgateway("google/gemini-2.5-pro")

Same code, same tools, same agent — different brain. This is great for comparing which model performs best at QA tasks for your specific app.

The Response Stream

The frontend receives NDJSON events like:

{"type":"status","message":"Launching headless browser..."}
{"type":"status","message":"Browser ready. Running test..."}
{"type":"action","step":1,"tool":"browser_navigate","args":{"url":"http://localhost:3000"},"status":"done"}
{"type":"action","step":2,"tool":"browser_snapshot","args":{},"status":"done"}
{"type":"action","step":3,"tool":"browser_click","args":{"ref":"@e5"},"status":"done"}
{"type":"screenshot","imageData":"base64..."}
{"type":"text","content":"I can see the signup form with email and password fields."}
{"type":"result","summary":"Test passed: signup flow works correctly."}

You can render this as a step-by-step timeline — each action shows what tool was called, what arguments were used, and what happened.

Example Test Instructions

Here are some test prompts that work well:

"Test the signup flow and verify a confirmation message appears"
"Navigate to the login page, enter invalid credentials, and verify an error is shown"
"Add an item to the cart and verify the cart count updates"
"Go to the settings page, change the display name, save, and verify it persists after a page refresh"
"Test keyboard navigation on the main form — tab through all fields and submit with Enter"

The agent handles all the details: finding the right elements, filling in forms, waiting for page transitions, and verifying outcomes.

Why This Architecture Works

Accessibility snapshots > screenshots for tool calling. Instead of sending expensive screenshots to the LLM and hoping it understands pixel coordinates, Agent Browser provides a semantic text tree. The LLM reads element labels, roles, and refs — much cheaper and more reliable.

Streaming > polling. NDJSON gives you real-time visibility into every agent step. No waiting for the entire test to finish before seeing results.

Provider-agnostic. LLM Gateway means you're not locked into one provider. Claude is great at following complex multi-step instructions, but GPT-4o might be faster for simple tests. Try both without changing code.

Guardrails built in. stepCountIs(25) prevents runaway agents. The 120-second maxDuration on the API route adds a hard timeout. Both are essential for production use.

Running the Template

git clone https://github.com/theopenco/llmgateway-templates.git
cd llmgateway-templates/templates/qa-agent
pnpm install
cp .env.example .env.local
# Add your LLMGATEWAY_API_KEY to .env.local
pnpm dev

Open http://localhost:3001, enter your app's URL, describe a test, and hit Run.

What's Next

This template is a starting point. You could extend it with:

Test suites — run multiple test instructions sequentially and aggregate results
Visual regression — capture screenshots at key points and compare against baselines
CI integration — run QA agents as part of your GitHub Actions pipeline
Custom assertions — add tools that check specific DOM states or API responses

The combination of AI tool calling + browser automation opens up a lot of possibilities beyond traditional test frameworks.

Resources:

How to Generate Images Using LLM Gateway and the Vercel AI SDK

smakosh — Sat, 28 Feb 2026 22:14:45 +0000

Image generation has become a core feature of modern AI applications. But integrating with multiple image providers — each with different APIs, pricing, and capabilities — can be a pain.

LLM Gateway simplifies this by giving you a single, OpenAI-compatible API for image generation across providers like Google Gemini, Alibaba Qwen, ByteDance Seedream, and more. In this guide, we'll walk through generating images using both the OpenAI SDK and the Vercel AI SDK.

Prerequisites

Sign up at llmgateway.io and create a project
Copy your API key
Export it in your environment:

export LLM_GATEWAY_API_KEY="llmgtwy_XXXXXXXXXXXXXXXX"

Option 1: The Images API (`/v1/images/generations`)

This is the simplest approach — a drop-in replacement for OpenAI's image generation endpoint.

Using curl

curl -X POST "https://api.llmgateway.io/v1/images/generations" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3-pro-image-preview",
    "prompt": "A cute cat wearing a tiny top hat",
    "n": 1,
    "size": "1024x1024"
  }'

Using the OpenAI SDK (Node.js)

import OpenAI from "openai";
import { writeFileSync } from "fs";

const client = new OpenAI({
  baseURL: "https://api.llmgateway.io/v1",
  apiKey: process.env.LLM_GATEWAY_API_KEY,
});

const response = await client.images.generate({
  model: "gemini-3-pro-image-preview",
  prompt: "A futuristic city skyline at sunset with flying cars",
  n: 1,
  size: "1024x1024",
});

response.data.forEach((image, i) => {
  if (image.b64_json) {
    const buf = Buffer.from(image.b64_json, "base64");
    writeFileSync(`image-${i}.png`, buf);
  }
});

That's it — point baseURL to LLM Gateway and use the standard OpenAI SDK. No new libraries needed.

Option 2: The Vercel AI SDK (`generateImage`)

If you're already using the Vercel AI SDK, LLM Gateway has a native provider package: @llmgateway/ai-sdk-provider.

npm install @llmgateway/ai-sdk-provider ai

Simple Image Generation

import { createLLMGateway } from "@llmgateway/ai-sdk-provider";
import { generateImage } from "ai";
import { writeFileSync } from "fs";

const llmgateway = createLLMGateway({
  apiKey: process.env.LLM_GATEWAY_API_KEY,
});

const result = await generateImage({
  model: llmgateway.image("gemini-3-pro-image-preview"),
  prompt: "A cozy cabin in a snowy mountain landscape at night with aurora borealis",
  size: "1024x1024",
  n: 1,
});

result.images.forEach((image, i) => {
  const buf = Buffer.from(image.base64, "base64");
  writeFileSync(`image-${i}.png`, buf);
});

Conversational Image Generation with `streamText`

The real power comes when you combine image generation with chat. Using the chat completions approach, you can build conversational image generation — ask the model to create an image, then refine it through follow-up messages.

Here's a Next.js API route:

import { streamText, type UIMessage, convertToModelMessages } from "ai";
import { createLLMGateway } from "@llmgateway/ai-sdk-provider";

interface ChatRequestBody {
  messages: UIMessage[];
}

export async function POST(req: Request) {
  const body = await req.json();
  const { messages }: ChatRequestBody = body;

  const llmgateway = createLLMGateway({
    apiKey: process.env.LLM_GATEWAY_API_KEY,
    baseUrl: "https://api.llmgateway.io/v1",
  });

  try {
    const result = streamText({
      model: llmgateway.chat("gemini-3-pro-image-preview"),
      messages: convertToModelMessages(messages),
    });

    return result.toUIMessageStreamResponse();
  } catch {
    return new Response(
      JSON.stringify({ error: "LLM Gateway Chat request failed" }),
      { status: 500 },
    );
  }
}

On the frontend, use the useChat hook from @ai-sdk/react and render images from the assistant's response parts:

import { useChat } from "@ai-sdk/react";

export const ImageChat = () => {
  const { messages, status, sendMessage } = useChat();

  return (
    <div>
      {messages.map((m) => {
        if (m.role === "assistant") {
          const textContent = m.parts
            .filter((p) => p.type === "text")
            .map((p) => p.text)
            .join("");

          const imageParts = m.parts.filter(
            (p) => p.type === "file" && p.mediaType?.startsWith("image/"),
          );

          return (
            <div key={m.id}>
              {textContent && <p>{textContent}</p>}
              {imageParts.map((part, idx) => (
                <img
                  key={idx}
                  src={`data:${part.mediaType};base64,${part.url}`}
                  alt="Generated image"
                />
              ))}
            </div>
          );
        }

        return (
          <div key={m.id}>
            {m.parts.map((p, i) =>
              p.type === "text" ? <p key={i}>{p.text}</p> : null
            )}
          </div>
        );
      })}
    </div>
  );
};

You can also use the pre-built <Image /> component from ai-elements for a polished rendering experience.

Option 3: Image Editing

LLM Gateway also supports editing existing images via /v1/images/edits. Pass an image URL (HTTPS or base64 data URL) along with your edit prompt:

curl -X POST "https://api.llmgateway.io/v1/images/edits" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "images": [
      {
        "image_url": "https://example.com/source-image.png"
      }
    ],
    "prompt": "Add a watercolor effect to this image",
    "model": "gemini-3-pro-image-preview",
    "quality": "high",
    "size": "1024x1024"
  }'

Switching Providers

The best part: switching image providers is a one-line change. Just swap the model string:

// Google Gemini
model: "gemini-3-pro-image-preview"

// Alibaba Qwen (from $0.03/image)
model: "alibaba/qwen-image-plus"

// ByteDance Seedream (up to 4K output)
model: "bytedance/seedream-4-5"

// Z.AI CogView (great for text in images)
model: "zai/cogview-4"

Each provider has different strengths:

Provider	Model	Price	Best For
Google	`gemini-3-pro-image-preview`	Varies	General purpose, high quality
Alibaba	`alibaba/qwen-image-max`	$0.075/image	Highest quality
Alibaba	`alibaba/qwen-image-plus`	$0.03/image	Best value
ByteDance	`bytedance/seedream-4-5`	$0.045/image	Up to 4K, multi-image fusion
Z.AI	`zai/cogview-4`	$0.01/image	Cheapest, bilingual text rendering

Customizing Output

Use the image_config parameter (chat completions) or standard size/quality params (images API) to control output:

# Google: aspect ratio + resolution
"image_config": {
  "aspect_ratio": "16:9",
  "image_size": "4K"
}

# Alibaba: pixel dimensions + seed for reproducibility
"image_config": {
  "image_size": "1024x1536",
  "seed": 42
}

Wrapping Up

With LLM Gateway, image generation becomes provider-agnostic. Whether you're using the OpenAI SDK, Vercel AI SDK, or raw HTTP — you get one API, multiple providers, and the flexibility to switch models without changing your code.

Resources:

Get started →

How to Build an Agent Skill: A Practical Guide

smakosh — Fri, 27 Feb 2026 11:12:40 +0000

AI agents are becoming the backbone of modern automation. But an agent is only as useful as its skills — the modular capabilities that let it interact with the world, solve problems, and take action on behalf of users.

In this guide, we'll walk through how to build an agent skill from scratch: what it is, how to structure it, and how to make it reusable and reliable.

What Is an Agent Skill?

A skill is a self-contained unit of capability that an agent can invoke. Think of it like a plugin. Instead of hardcoding every behavior into the agent itself, you package specific functionality into skills that the agent can discover, understand, and use.

Examples of skills:

Weather lookup — fetch current weather for a given location
Web search — query a search engine and return results
Database query — run SQL against a connected database
Email sender — compose and send emails on behalf of the user
Code executor — run code snippets in a sandboxed environment

Each skill has a clear purpose, defined inputs and outputs, and works independently of other skills.

Anatomy of a Skill

A well-structured skill typically includes:

my-skill/
├── SKILL.md          # Description, instructions, and usage guide
├── index.js          # Main skill logic
├── schema.json       # Input/output schema
└── README.md         # Documentation for developers

Let's break down each piece.

1. The Skill Manifest (SKILL.md)

This is the most important file. It tells the agent what the skill does, when to use it, and how to use it. Write it in plain language — the agent reads this to decide whether to invoke your skill.

# Weather Skill

Get current weather and forecasts for any location worldwide.

## When to Use
- User asks about weather, temperature, or forecasts
- User wants to know if they need an umbrella or jacket

## When NOT to Use
- Historical weather data requests
- Severe weather alerts or emergency info

## Usage
Call the `getWeather` function with a location string.
Returns temperature, conditions, humidity, and wind speed.

Be specific about boundaries. Telling the agent when not to use a skill is just as important as telling it when to use one.

2. Input/Output Schema

Define a clear contract for what your skill expects and returns. JSON Schema works well for this:

{
  "name": "getWeather",
  "description": "Get current weather for a location",
  "input": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or coordinates (e.g., 'London' or '51.5,-0.1')"
      },
      "units": {
        "type": "string",
        "enum": ["metric", "imperial"],
        "default": "metric"
      }
    },
    "required": ["location"]
  },
  "output": {
    "type": "object",
    "properties": {
      "temperature": { "type": "number" },
      "conditions": { "type": "string" },
      "humidity": { "type": "number" },
      "windSpeed": { "type": "number" }
    }
  }
}

Strict schemas prevent ambiguity. The agent knows exactly what to pass in and what to expect back.

3. The Skill Logic

Keep the implementation focused and defensive. Handle errors gracefully — the agent needs useful error messages to recover or inform the user.

async function getWeather({ location, units = "metric" }) {
  if (!location || location.trim() === "") {
    return { error: "Location is required" };
  }

  try {
    const response = await fetch(
      `https://api.weatherservice.com/v1/current?q=${encodeURIComponent(location)}&units=${units}`
    );

    if (!response.ok) {
      return { error: `Weather API returned ${response.status}` };
    }

    const data = await response.json();

    return {
      temperature: data.main.temp,
      conditions: data.weather[0].description,
      humidity: data.main.humidity,
      windSpeed: data.wind.speed,
      location: data.name,
    };
  } catch (err) {
    return { error: `Failed to fetch weather: ${err.message}` };
  }
}

module.exports = { getWeather };

Key principles:

Validate inputs before doing anything
Return structured errors instead of throwing exceptions
Keep responses concise — agents work better with focused data
Don't include unnecessary information — return what the user needs

Design Principles for Great Skills

Single Responsibility

One skill, one job. A weather skill shouldn't also handle calendar events. If you're tempted to add unrelated functionality, make a separate skill.

Idempotency Where Possible

Skills that read data should be safe to call multiple times. For skills that write data (sending emails, creating records), make this clear in the manifest so the agent doesn't accidentally duplicate actions.

Meaningful Error Messages

// Bad
return { error: "Something went wrong" };

// Good
return { error: "Location 'Xyzzy' not found. Try a city name like 'New York' or coordinates like '40.7,-74.0'" };

The agent uses error messages to decide what to do next. Vague errors lead to vague recovery attempts.

Rate Limiting and Caching

If your skill calls external APIs, build in rate limiting and caching:

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function getWeatherCached({ location, units }) {
  const key = `${location}:${units}`;
  const cached = cache.get(key);

  if (cached && Date.now() - cached.timestamp < CACHE_TTL) {
    return cached.data;
  }

  const result = await getWeather({ location, units });
  cache.set(key, { data: result, timestamp: Date.now() });
  return result;
}

This protects both the external API and your costs.

Security

Never expose raw API keys in skill responses
Sanitize inputs to prevent injection attacks
Limit scope — a skill should only access what it needs
Log sensitive operations for audit trails

Testing Your Skill

Test skills independently before plugging them into an agent:

// test.js
const { getWeather } = require("./index");

async function runTests() {
  // Happy path
  const result = await getWeather({ location: "London" });
  console.assert(result.temperature !== undefined, "Should return temperature");

  // Missing input
  const error = await getWeather({});
  console.assert(error.error !== undefined, "Should return error for missing location");

  // Invalid location
  const notFound = await getWeather({ location: "NotARealPlace12345" });
  console.assert(notFound.error !== undefined, "Should handle unknown locations");

  console.log("All tests passed");
}

runTests();

Test edge cases: empty strings, very long inputs, special characters, network failures, and API rate limits.

Registering the Skill with Your Agent

How you register a skill depends on your agent framework. The general pattern is:

Discovery — the agent scans available skills and reads their manifests
Selection — when a user request comes in, the agent matches it against skill descriptions
Invocation — the agent calls the skill with structured inputs
Response — the agent incorporates the skill's output into its reply

Most frameworks support a simple registration pattern:

agent.registerSkill({
  name: "weather",
  description: "Get current weather and forecasts for any location",
  manifest: "./skills/weather/SKILL.md",
  handler: require("./skills/weather"),
});

Common Pitfalls

Over-engineering the first version. Start simple. A skill that does one thing well beats a complex skill that does many things poorly.

Vague descriptions. If the agent can't tell when to use your skill, it won't use it correctly. Be precise in your SKILL.md.

Ignoring failure modes. External APIs go down. Networks fail. Always handle errors and give the agent enough context to recover gracefully.

Returning too much data. Agents have context limits. Return only what's needed for the user's request, not entire API responses.

No timeout handling. Always set timeouts on external calls. An agent waiting 30 seconds for a response creates a terrible user experience.

Wrapping Up

Building agent skills is about creating focused, reliable, well-documented modules that an agent can confidently use. The best skills are:

Clear — the agent knows exactly when and how to use them
Robust — they handle errors gracefully and fail safely
Focused — they do one thing and do it well
Documented — both the agent and human developers can understand them

Start with a simple skill, get it working end-to-end, then iterate. The modular nature of skills means you can always improve or replace them without touching the rest of your system.

Happy building! 🛠️

What is an LLM Gateway?

smakosh — Sat, 21 Feb 2026 18:39:00 +0000

Large language models power modern AI applications—from chatbots and code assistants to document analysis and automated customer support. But deploying LLMs at scale introduces challenges that most teams aren't prepared for.

Different providers have different APIs. Models have different capabilities and pricing. Requests need routing, caching, and monitoring. Security and compliance requirements add another layer of complexity.

An LLM Gateway solves these problems by acting as a centralized orchestration layer between your applications and the AI models they use.

Why LLMs Need a Gateway

Building production AI applications without a gateway means dealing with:

Fragmented APIs: OpenAI, Anthropic, Google, and other providers all have different request formats, authentication methods, and response structures
Model Selection Complexity: Choosing the right model for each use case requires understanding trade-offs between cost, latency, and capability
Resource Management: Token limits, rate limiting, and concurrent request handling all need coordination
Performance Monitoring: Understanding latency, error rates, and costs across providers requires custom instrumentation
Security Concerns: API keys scattered across services, no audit trail, and no control over what data reaches external providers
Scaling Demands: Handling traffic spikes, failovers, and load balancing across multiple providers

Each of these challenges is solvable individually—but solving them together, reliably, is where most teams struggle.

What an LLM Gateway Does

An LLM Gateway functions as middleware between your applications and AI providers. It intercepts every request, applies your policies, routes to the appropriate provider, and returns a standardized response.

Core Capabilities

Unified API Interface
Instead of integrating with each provider separately, your applications talk to one API. The gateway handles translation, authentication, and provider-specific quirks behind the scenes.

Intelligent Request Routing
Route requests based on model availability, cost, latency, or custom rules. Send complex reasoning tasks to Claude, simple queries to GPT-4o-mini, and embeddings to the cheapest available provider.

Automatic Failover
When a provider experiences downtime or latency spikes, the gateway automatically routes to a backup. Your applications stay online even when individual providers don't.

Caching and Optimization
Identical requests don't need to hit the provider twice. Semantic caching can serve similar requests from cache, reducing costs and latency by 80% or more for repeated queries.

Security and Access Control
Centralized API key management means provider credentials never touch your application code. Role-based access control ensures teams only access approved models with appropriate spending limits.

Observability and Analytics
Every request is logged with metadata: which user, which model, how many tokens, what latency, what cost. Debug issues, track spending, and optimize performance from a single dashboard.

How an LLM Gateway Works

A typical request flow looks like this:

Request Handling: Your application sends a request to the gateway using a standard format (typically OpenAI-compatible)
Validation: The gateway validates authentication, checks rate limits, and verifies the user has permission for the requested model
Routing: Based on your configuration, the gateway selects the optimal provider and model for this request
Transformation: The gateway translates the request into the provider's native format
Execution: The request is sent to the AI provider, with automatic retry and failover if needed
Response Processing: The response is normalized to a standard format and returned to your application
Logging: Request metadata, tokens used, latency, and cost are recorded for analytics

Self-Hosting vs. Managed Gateways

LLM Gateways come in two flavors:

Managed gateways handle infrastructure for you. You get started in minutes with no servers to maintain. This works well for startups and teams that prioritize speed over control.

Self-hosted gateways run in your own infrastructure. Prompts containing sensitive data never leave your network. You control data retention, security policies, and compliance documentation. This matters for enterprises handling customer PII, financial data, or regulated industries.

LLM Gateway supports both approaches. Start with the managed service to move fast, then self-host when compliance or data residency requirements demand it.

The Cost of Not Having a Gateway

Teams without a gateway typically experience:

Higher costs: No visibility into which teams or use cases drive spending, no caching, no cost-based routing
Outages: Single provider dependencies mean their downtime is your downtime
Security gaps: API keys in environment variables across services, no audit trail, no access control
Slower iteration: Every new provider or model requires code changes across applications

A gateway doesn't just add features—it removes friction that slows down your AI development.

Getting Started

If you're building production AI applications, you need a gateway. The question is whether you build one yourself or use an existing solution.

Building your own seems straightforward at first: a simple proxy that forwards requests. But the edge cases multiply quickly. Rate limiting, streaming responses, function calling, image inputs, provider-specific errors—each adds complexity.

Most teams find that adopting an existing gateway pays for itself within weeks through reduced engineering time, lower AI costs, and fewer production incidents.

An LLM Gateway isn't just infrastructure—it's the foundation for scaling AI across your organization safely and efficiently.

Ready to simplify your LLM infrastructure? Get started with LLM Gateway

Deploying Next.js on GCP

smakosh — Sat, 21 Feb 2026 18:36:17 +0000

We recently moved our Next.js deployments to Google Cloud Platform. Here's why and how it went.

Why GCP?

LLM Gateway is a full-stack application with multiple APIs and frontends. Deploying everything through Vercel meant adding another tool to our stack—one more dashboard, one more set of credentials, one more thing to manage.

By running on GCP directly, we consolidate our infrastructure. Our APIs, databases, and frontends all live in the same place.

The Setup

All our services run on a Kubernetes cluster on GCP. Each service—API, Gateway, UI, Playground, Docs, Admin, and Worker—is deployed as a separate container. Kubernetes handles autoscaling based on resource usage, so we scale up during traffic spikes and scale down when things are quiet.

The build and deployment pipeline is fully automated via GitHub Actions. On every push to main, we build Docker images for each service and push them to GitHub Container Registry. You can see the workflow here: .github/workflows/images.yml.

For Next.js specifically, we build in standalone mode and package each app into its own container.

Performance

The results surprised us. Performance is excellent—response times are consistently fast, and the infrastructure handles our traffic without issues.

The common concern with self-hosted Next.js is SSR latency from running in a single region. In practice, this hasn't been a problem. The slight increase in latency for users far from our region is negligible compared to the operational simplicity we gained.

How to Self-Host Next.js

Here's how to do it yourself.

Step 1: Enable Standalone Mode

In your next.config.js:

module.exports = {
  output: "standalone",
};

This bundles your app into a self-contained folder with all dependencies.

Step 2: Dockerfile

FROM node:20-slim AS builder
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN npm install -g pnpm && pnpm install --frozen-lockfile
COPY . .
RUN pnpm build

FROM node:20-slim AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV HOSTNAME="0.0.0.0"
ENV PORT=80

COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public

EXPOSE 80
CMD ["node", "server.js"]

Build and push:

docker build -t gcr.io/your-project/your-app:latest .
docker push gcr.io/your-project/your-app:latest

Step 3a: Deploy to Cloud Run

gcloud run deploy your-app \
  --image gcr.io/your-project/your-app:latest \
  --platform managed \
  --region us-central1 \
  --allow-unauthenticated

Step 3b: Deploy to Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: your-app
  template:
    metadata:
      labels:
        app: your-app
    spec:
      containers:
        - name: your-app
          image: gcr.io/your-project/your-app:latest
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"

Apply with kubectl apply -f deployment.yaml.

Bonus: Autoscaling

For automatic scaling based on CPU usage, add a HorizontalPodAutoscaler:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: your-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: your-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

This scales your deployment between 2 and 10 replicas based on CPU utilization.

Bonus: CI/CD with GitHub Actions

Automate builds with GitHub Actions. This workflow builds and pushes to GitHub Container Registry on every push to main:

name: Build and Push

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4

      - uses: docker/setup-buildx-action@v3

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

Save as .github/workflows/build.yml.

Takeaway

If you're already on GCP and considering whether to add Vercel to your stack, you might not need to. Kubernetes and Cloud Run handle Next.js well, and keeping everything in one place makes operations simpler.

Getting Started with LLM Gateway in 5 Minutes

smakosh — Sat, 21 Feb 2026 18:31:02 +0000

This guide walks you through making your first LLM request through LLM Gateway. By the end, you'll have a working API key and a completed request visible in your dashboard.

Step 1: Get an API Key

Sign in to the LLM Gateway dashboard.
Create a new Project.
Copy the API key.
Export it in your shell or add it to a .env file:

export LLM_GATEWAY_API_KEY="llmgtwy_XXXXXXXXXXXXXXXX"

Step 2: Make Your First Request

LLM Gateway uses an OpenAI-compatible API. Point your requests to https://api.llmgateway.io/v1 and you're done.

Using curl

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "messages": [
      {"role": "user", "content": "What is an LLM gateway?"}
    ]
  }'

Using Node.js (OpenAI SDK)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.llmgateway.io/v1",
  apiKey: process.env.LLM_GATEWAY_API_KEY,
});

const response = await client.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "What is an LLM gateway?" }],
});

console.log(response.choices[0].message.content);

Using Python

import requests
import os

response = requests.post(
    "https://api.llmgateway.io/v1/chat/completions",
    headers={
        "Content-Type": "application/json",
        "Authorization": f"Bearer {os.getenv('LLM_GATEWAY_API_KEY')}",
    },
    json={
        "model": "gpt-4o",
        "messages": [
            {"role": "user", "content": "What is an LLM gateway?"}
        ],
    },
)

response.raise_for_status()
print(response.json()["choices"][0]["message"]["content"])

Using the AI SDK

If you're using the Vercel AI SDK, you can use the native provider:

import { llmgateway } from "@llmgateway/ai-sdk-provider";
import { generateText } from "ai";

const { text } = await generateText({
  model: llmgateway("openai/gpt-4o"),
  prompt: "What is an LLM gateway?",
});

Or use the OpenAI-compatible adapter:

import { createOpenAI } from "@ai-sdk/openai";

const llmgateway = createOpenAI({
  baseURL: "https://api.llmgateway.io/v1",
  apiKey: process.env.LLM_GATEWAY_API_KEY!,
});

Step 3: Enable Streaming

Pass stream: true to any request and the gateway will proxy the event stream unchanged:

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "stream": true,
    "messages": [
      {"role": "user", "content": "Write a short poem about APIs"}
    ]
  }'

Step 4: Monitor in the Dashboard

Every call appears in the dashboard with latency, cost, and provider breakdown. Go back to your project to see your request logged with the model used, token counts, cost, and response time.

Step 5: Try a Different Provider

The best part of using a gateway: switching providers is a one-line change. Try the same request with a different model:

# Anthropic
"model": "anthropic/claude-haiku-4-5"

# Google
"model": "google-ai-studio/gemini-2.5-flash"

Same API, same code. Just a different model string.

What's Next

Try models in the Playground — test any model with a chat interface before integrating
Browse all models — compare pricing, context windows, and capabilities
Read the full docs — streaming, tool calling, structured output, and more
Join the Discord — get help and share what you're building

Get started now

How to upload files to Imagekit using Next.js server actions

smakosh — Mon, 19 Feb 2024 21:37:00 +0000

As we're using Imagekit in this tutorial, setup an account there and grab the following keys:

IMAGEKIT_PUBLIC_KEY=
IMAGEKIT_PRIVATE_KEY=
IMAGEKIT_URL_ENDPOINT=

Add them to your .env.local file in your Next.js project, then install the imagekit package, finally let's create our FileUpload.tsx component

import ImageKit from "imagekit"

const imageKit = new ImageKit({
  publicKey: process.env.IMAGEKIT_PUBLIC_KEY!,
  privateKey: process.env.IMAGEKIT_PRIVATE_KEY!,
  urlEndpoint: process.env.IMAGEKIT_URL_ENDPOINT!,
})


const FileUpload = () => {
  // Server action
  const handleCreateListing = async (formData: FormData) => {
    "use server"

    const image = formData.get("image") as unknown as File

    // You could throw an error if image is null here

    const arrayBuffer = await image.arrayBuffer()
    const buffer = Buffer.from(arrayBuffer)

    const response = await imageKit.upload({
      file: buffer,
      fileName: image.name,
    })

    // Do something with response
  }

  return (
    <form action={handleCreateListing}>
     <input name="image" type="file" />
     <button type="submit">Submit</button>
    </form>
  )
}

That's all. You could use useFormState to handle the pending state and show a loading state and disable the button. You could also add more validation server side in the server action etc...

2021 year in review

smakosh — Sun, 17 Jul 2022 00:10:01 +0000

Photo by Kelly Sikkema on Unsplash

2021 was an immersive year for me, After quitting my full time job at 4D in early November 2020, I was actually in a tough spot, I had only a few bucks on my bank account and as I was living alone, I had to find a new job to get food on the table but at the same time I didn’t want to commit the same mistake and quitting once again quickly.

So I started working on a few open source projects like ontwik-ui which is this headless UI library like Tailwind’s headless UI but doesn’t require the usage of TailwindCSS and uses a different architecture. I also made a Next js version of my Gatsby portfolio template, upgraded most of my boilerplates/starters.

On the side, I consistently worked on Ontwik and used to be active on Ben Awad’s Discord server where I spotted a job post from Florian (who’s now one of my best business partners that I enjoy working with) who was looking for a React Native developer and decided to give it a try, we had a short call and I started working with him, few weeks later, I started exchanging technical emails with Greg who found my profile on YC’s work at a startup website. At the beginning of December 2020, he decided to hire me part-time to help the team maintain and rebuild The Landing which later on turned into a full time job.

During the same month, Greg introduced me to his friends at Parafin who decided to hire me part-time to help build an early prototype web SDK in React. It was stressful but I really loved it and it was fun to work on lots of different projects at the same time.

At The Landing, I had to implement sign in with Google, but to my surprise the app depended on Shopify a lot including saving users as customers on Shopify, which made it hard to implement Google sign in, after a long discussion with the team, we decided to bring in my good friend Jeffery who’s my co-founder at Ontwik as well, he’s the one who built all the micro services, dockerized them and automated their deployments. After Jeffery joined us, we picked the hype beast stack (TypeScript, GraphQL, Next js, typeORM, type-graphql, postgres, redis, Apollo server/client) and started rebuilding The Landing from scratch, it took us ~40 business days to complete the scalable MVP to launch it to the public and The Landing managed to raise $2.5M in a seed round. The public launch was super cool and it was really fun at that time to be working at The Landing.

After the launch, Greg moved on to his next adventure in life and we were left without a technical manager, Greg was so friendly & had a great experience from various companies including AirBnb. On top of being a good manager, he used to write code too and all of us enjoyed working with him. After Greg left, there was a missing piece in the board, as a result, some bad decisions were taken by the board members which affected us negatively and impacted the platform. And started hiring profiles based on specific criterias like their geolocation and gender rather than targeting skilled and passionate developers no matter what their race or gender is. All of this contributed to my decision of quitting after spending 11 months working on the platform.

At Parafin, things were cool until the team decided to bring in a junior developer who was arguing more than working, I decided to quit though I really enjoyed building the SDK web prototype, my dad helped with some maths too, it was fun nonetheless. I’ll never forget that useSlider hook & all the integration tests I wrote.

With Florian, we worked on a mobile app using React native and TypeScript, then a Gatsby js website, we completed the work on those projects and eventually had to take a break.

I also kept working on Ontwik with my co-founder and managed to launch the public beta, Greg was actually our first customer as he hired a good frontend developer to help us at The Landing, though we didn’t charge Greg anything, we got his testimonial and word of mouth did help to attract another customer which I’ll talk more about later on.

I also joined Cosmic for a month, I fixed some bugs on the documentation website, setup the codebase of the new Cosmic dashboard, implemented authentication though I was against storing JWT on localStorage, but the backend didn’t want to go with a secure http only cookie even tough this has some security vulnerabilities, after implementing few features I decided to move on but recommended a friend of mine who took over my work.

Also a quick reminder that all these events were happening at the same time on parallel.

I then joined Rare things which needed help on their Next js app that fetches products from certain Shopify stores and used Stripe checkout, their app was targetting indie artisans and showcased their work and products in a good UX. Emily was also our second customer on Ontwik and the first one to process the first successful transaction. She hired two developers from Ontwik and we worked on the auction feature which unfortunately never went live even though it was all built up and ready for launch. Few weeks later, the project shut down and each of us moved on.

After I left The Landing, I got some good offers offering relocation to Europe, I decided to go with Burda and passed lots of interviews, it turns out both Burda and its company Jameda wanted to hire me, I decided to go with Jameda because of a previous experience with digital health products. They did their best and took care of my relocation to Germany, it did take more than 3 months but everything worked out and I’m expected to be in Munich on 1st March 2022.

During that period (the 3 months), I worked few part time jobs like Dopewars and LinksDAO and most of them were in the crypto space, I’ve been following the space since 2017 but nowadays there are lots of cool products to build on like Hardhat, ethers js and tons more, some are open source, others are backed by their tokenomocis while others are profitable businesses backed by VCs and their revenue.

I also joined Formspree to work part time with them, I initially worked on their Vercel integration, then moved on to work on their dashboard and later on started working on implementing Stripe on their core library, to then adding support to that as well on their React library with a fork of Vercel’s conference starter kit but tickets have to be purchased.

Here’s a summary of things I learned, created, earned and shared.

Learning

Dev

More TypeScript
Type-graphql
GraphQL Codegen
typeORM
Switched to TailwindCSS in few projects
Ethers js
Hardhat
Web3-react
React-query
Redux toolkit
Core web vitals

Life

Real estate
Stocks
Crypto
Personal finance
More about taxes

Design

Started the switch to Figma from Adobe XD

Creating

Contributed in building 2 platforms and a mobile app at my previous job which I’m not allowed to disclose as they are still not public.
Co-built Ontwik
Recruited folks either directly or by a recommendation
Started working on Ontwik-ui
Updated my Gatsby starters and theme
Made a CRA boilerplate
Contributed in building The Landing
Built an early web SDK for Parafin
Worked on Rare things
Worked on Cosmic docs and the new CMS codebase
Few other products I’m not allowed to disclose
Worked on Dopewars, my contributions are visible since it’s an open sourced project
Built LinksDAO SXSW event registration
Continued work on Ontwik Beta
Built Mintify, it’s open source too.
Built React hot pagination
Started work on Ontwik UI
Started work on my new portfolio
Next js boilerplates

Earning

Bought another apartment which is rented right now
Replaced my Google Pixel 2 with an Iphone 13 Pro

Sharing

Gave 4 talks, 1 public, rest were private

Data about this blog during 2021

67,045 page views 👀
27,499 users 📈
27,119 new users 📈
10,936 are based in 🇨🇳
3,326 🇺🇲
2,977 🇨🇳
1,306 🇮🇳
1,167 🇪🇪
15,629 use Chrome
3,033 use Safari
6,616 use Windows
3,775 use Macintosh
2,018 use Linux
11,081 use Android
3,429 use iOS

Apologies for being late publishing this article, both 2021/2022 have been busy years so far.

How to make an NFT

smakosh — Tue, 23 Nov 2021 15:10:01 +0000

You can collect this article as an NFT Here

As there is a new trend these days and as I’ve been working on this area recently, I thought of writing this article to explain what an NFT is and how can you make one.

NFT stands for Non fungible token which basically means that this kind of token is unique and cannot be split unlike a fungible token. You can think of this as an Art piece like the Monalisa that is unique and loses its value once it gets split. While money for example can be split and exchanged as it’s not something unique.

Photo by Atahan Guc on Unsplash

This trend started earlier in 2017 when a project known as Crypto kitties launched, which lets you connect your Crypto wallet and create an NFT in the form of a cute kitten which has some associated attributes like what the kitten is wearing, color etc…

And correct me if I’m wrong, but I think the folks behind that project are the ones who pioneered the ERC-721 smart contract which lets you mint NFTs, as it acts like an API or a link between the owner of the NFT and the NFT itself.

So with this out of the way, let us explore how to make one, what do you need to do that and how?

Before you get to this point, you do need to have a basic understanding of the blockchain, especially Ethereum’s blockchain and smart contracts, I’m not going to explain that here but you can let me know if you’re interested in a deep dive explanation.

An NFT can be any digital asset, whether it’s an image, audio or 3D model file, as long it carries with it an object with the right attributes which we call “metadata”.

Once your digital asset has been created, you need an ERC-721 (or ERC-1155) smart contract’s address to use it to mint that NFT.

pragma solidity ^0.8.4;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

import "hardhat/console.sol";

contract NFTFactory is ERC721URIStorage {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIds;
    address contractAddress;

    // Note that you don't have to do this, only if you want to pass the name and symbol of the ERC-721 token when you'd like to deploy
    constructor(string memory name, string memory symbol)
        ERC721(name, symbol)
    {}

    function createToken(string memory tokenURI) public returns (uint256) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(msg.sender, newItemId);
        _setTokenURI(newItemId, tokenURI);
        setApprovalForAll(contractAddress, true);
        return newItemId;
    }
}

Once your contract is ready, you have to compile and deploy it, there are tools that help with that like Hardhat which I do recommend.

You can compile your contract running npx hardhat compile, you can deploy it using Hardhat or build the frontend and deploy from there like I did on my Minting app:

import { ethers } from 'ethers';

// We're importing the contract's artifacts here
import NFTFactory from '../../../artifacts/contracts/NFTFactory.sol/NFTFactory.json';

// Get the user signature
const provider = new ethers.providers.Web3Provider(window.ethereum);
const signer = provider.getSigner();

// Prepare contract facotry
const factory = new ethers.ContractFactory(NFTFactory.abi, NFTFactory.bytecode, user.data.signature || signer);

// Deploy the smart contract (ERC 721)
const deployedContract = await factory.deploy('Much wow', 'WOW');

await deployedContract.deployed();

Once the contract is deployed, you can take its address, use the mint function to create a non fungible token.

You may be wondering where the digital asset and the metadata object will be hosted at? That’s indeed a good question, the answer might be different, as each of us has their own opinion, but that gets hosted off-chain or on-chain.

Off-chain, meaning on a centralized database or service like AWS S3, while on-chain means directly on the blockchain using decentralized file system services like IPFS or other alternatives, keep in mind files on IPFS are not permanent and might be deleted if not needed later on automatically.

In this article, I will go with the on-chain approach and use Infura (a premium service) to host the files using IPFS but never loose them. You get up to 5Gb for free.

import { create as ipfsHttpClient } from 'ipfs-http-client';

// You can grab those keys from Infura.io
const auth = 'Basic ' + Buffer.from(`${INFURA_IPFS_PROJECT_ID}:${INFURA_IPFS_PROJECT_SECRET}`).toString('base64');

const client = ipfsHttpClient({
  host: 'ipfs.infura.io',
  port: 5001,
  protocol: 'https',
  headers: {
    authorization: auth,
  },
});

// Upload image to IPFS (getting blob from url, might not needed if you already have the blob)
const blob = await fetch(values.image).then((r) => r.blob());

const image = await client.add(blob);


const data = JSON.stringify({
  attributes: [],
  description: 'description'
  external_url: 'external_url'
  name: 'name'
  image: `https://ipfs.infura.io/ipfs/${image.path}`,
});

// Upload the rest to IPFS
const added = await client.add(data);
const metadataUrl = `https://ipfs.infura.io/ipfs/${added.path}`;

Once the files are uploaded, you get an url as response from IPFS and that’s the url we will pass when creating an NFT.

import { ethers } from 'ethers';
import NFTFactory from '../../../artifacts/contracts/NFTFactory.sol/NFTFactory.json';

const provider = new ethers.providers.Web3Provider(window.ethereum);

// Ask for user signature
const signer = provider.getSigner();

// Mint the NFT using the deployed smart contract
const contract = new ethers.Contract(<YOUR ERC-721 deployed contract address>, NFTFactory.abi, signer);

// Token gets created
// metadataUrl is the url returend by IPFS above
const transaction = await contract.createToken(metadataUrl);
await transaction.wait();

Now that your NFT has be minted, you can list it for sale on different marketplaces like OpenSea or Foundation or directly trade via your wallet which is not recommended.

That’s all. Comment down below if you have any questions!

Forgot to plug an open source minting platform I’m currently working on called Mintify

Credits

Thanks a lot to Nader Dabit’s videos and articles that helped me a lot to quickly grasp and understand this and of course dozen of other online content from amazing creators.

Also thanks for Greg for minting an NFT for me to join Developer DAO where I’m more active these days.

2020 year in review

smakosh — Wed, 30 Dec 2020 00:10:01 +0000

I haven’t published any article during this year which is unfortunate as it’s been an overwhelming one for me but not exactly due to the pandemic, it was mainly due to the amount of client work I had to deliver during this year.

Though, this doesn’t mean I won’t be writing this one as I’m traveling back to visit my parents & get to walk a bit as I have been spending most of my time sitting on my desk.

So as usual, I’ll cover things that I have managed to learn, create & earn but I’ve decided to add a new category this year of things I shared as well.

This year started for me in late December when I was working a normal well paying job in a city known as Casablanca here in Morocco, though the workload wasn’t heavy, my skills weren’t been used the right way and as a result I wasn’t learning anything new on that job except few soft skills like mentoring new members, talking face to face with clients & I got to know few stuff related to business.

So I decided to accept an offer as a remote JAM Stack developer for a NYC startup as a part time job from which I learned a lot actually, though I understood the JAM stack well but I was heavily using Gatsby js rather than alternatives which weren’t that many nor as good as Gatsby when it comes to statically generate pages at that time, so I had to pick up & learn Next js the canary version at that time which added support to SSG & provided a new API for SSR as well, along with ISR.

My task was to build a statically generated Ecommerce website with i18n and multi currency support and does include the checkout step as well while the content is managed from a headless CMS.

Though there were some obstacles & performance issues with the GraphQL API I was using to fetch data & other security flaws I can elaborate more on, I managed to get it done in March which was open sourced, it was a good experience nevertheless as I got to work with good developers from all the parts of the world & I learned a lot from them & from the Next js core team which were really helpful & didn’t get bothered with my questions on both Next & Vercel.

I was also handling some client work to the point that I started outsourcing the work to fellow developers and designers I know and trust.

That was the moment I come up with the idea of building Ontwik which is a platform that connects developers directly with founders anywhere in the world without taking a % cut from the developers hourly rates but by charging the founder a small fee to get the contact details of the developers they decided to hire.

The small fee covers the work we do to filter good developers based on our previous work experience with them and a personal & technical interview which doesn’t include leetcode along with the servers cost and our design and engineering work.

And this is why I couldn’t publish any articles thus far. But I did give more talks this year than the previous one & one of the best ones was done remotely for the first edition of an amazing conference, though it was in my locale language, I would recommend checking out the slides. as they are in English.

Early in March, the startup decided to invite me to NYC to meet the whole team including investors & the board as I got an offer to work for them full time, as I passed through the airport checking, I checked my phone to notice that everything was canceled & I was asked not to come though I wasn’t able to retrieve my luggages nor cancel my flight. As a result I had to spend 1 night in a hotel nearby the airport & come back the next day. I’m grateful that everything was covered by the startup.

Few months later, the company collapsed for reasons I cannot disclose.

The Moroccan company got impacted by the pandemic as more clients weren’t used to remote work hence we (employees) were asked to let go of a specific percentage of our salary which was fine with me as it will be paid back later on, as I was in my parents house I decided to let go of 80% but in a condition to raise the precentage for other employees who are living independently and have a family to take care of, not sure if the CEO did as I requested but I trust his words.

A month later, we were asked again to let go of half of our salary but this time it won’t be paid back and any new employee shall be laid off until the company gets more work on the table, so I decided to mark myself as open for the market.

I got a numerous amount of offers which I’m grateful and thankful for, along with the support from anyone who reached out with an offer, help or a recommendation. I passed few interviews and decided to go with a Moroccan company based in Rabat by a recommendation from a friend of mine who runs a recruiting company. Though I decided to quit after being summoned to the office later in November.

Throughout 2020 I got to meet Jeffrey who’s my co-founder of Ontwik and has been doing amazing work powering up the micro services of Ontwik and I registered Smakosh as an LLC in the US as well which made it easier for me to work with amazing founders in the states.

Here’s a summary of things I learned, created, earned and shared.

Learning

Dev

Next js
React native navigation v5
ISR
TypeScript
BitPay
Stripe API
I tried Prisma v2
I tried Tailwindcss
Sequelize
Postgres
FaunaDB
Docusaurus

Life

More cooking
Selling an idea
Living independently
Taxes
The majority of people still cares about status

Design

Started playing with Glassmorphism recently
Redesigned this website, will be live anytime soon
more about Design systems

Creating

Contributed in building 2 platforms and a mobile app at my previous job which I’m not allowed to disclose as they are still not public.
Co-built Ontwik
Recruited folks either directly or by a recommendation
Started working on Ontwik-ui
Updated my Gatsby starters and theme
Made a CRA boilerplate

Sharing

Gave 5 talks
Have been a guest in 3 podcasts episodes

Data about my blog during 2020

63,036 page views 👀
20,268 users 📈
20,032 new users 📈
3,833 are based in 🇲🇦
3,203 🇺🇲
1,836 🇮🇳
1,378 🇨🇳
1,178 🇪🇪
14,131 use Chrome
1,974 use Safari
6,310 use Windows
4,683 use Macintosh
2,180 use Linux
4,610 use Android
2,022 use iOS

Will keep editing this article until January ends I usually do.

2019 year in review

smakosh — Fri, 03 Jan 2020 00:10:01 +0000

I managed to achieve in 2019 much more of what I’ve done in 2018, here’s an overview of what I have learned, created & some random facts.

Learning

Dev

React hooks
React native navigation
React native config
Fastlane
SSR, static SSR, CSR, Pre-rendering
Styled-system
Theme UI
ZEIT now
Semantic commits
Removed redux & recompose, switched to Hooks & Context API.
Tried React VR (360)
Tried Ruby and Ruby on rails
Configuring Nginx, redirecting http to https after generating and adding the SSL cert
Circle & Travis CI
Detox and cypress for e2e testing
testing-library (for React and React native)
Apollo client
Airtable
Contentful
GraphQL
Tried Docker
Pagination with mongoose-paginate
tried Redis
Mixpanel
tried Sinatra

Life

Decisions are made based on:
- The environment
- Experience
- Bias & intuition
Team & project management
Laundry & cooking
Negotiating
Saying “No”
Expenses/Income management
Being rich isn’t being wealthy
Giving a good feedback

Design

UX can be improved based on analytics & user behavior using tracking events
Wireframing is an important milestone
Design systems
Little experiment I did, CSS in GraphQL

Creating

Contributed in building 3 platforms at my previous job, Barmej, Pawp & a foundation’s website that support up to 6 languages using Gatsby & Contentful as a headless CMS while working for Obytes.
Continued adding features, fixing bugs & improving Beaf until I decided to shut it down and open source the code bases.
Built & shipped Ai Hashtags, an Android & iOS app to generate precise hashtags from your pictures & Instagram posts.Contributed more to Gatsby & few other JavaScript libraries, got some free swag in return.
Decided & managed to write an article a month, that’s a total of 12 articles!
Gave 3 talks about Gatsby js, in Casablanca & Penang island.
Mentored few folks on Twitter who managed to get their first jobs.
Created react-flex-ready
Created a Gatsby theme gatsby-theme-portfolio
Bunch of Gatsby starters

Random facts

Resigned from my first job, after 2.3 years working as a remote front-end developer
Replaced my Nexus 6p phone with Google Pixel 2
Traveled to Southeast Asia for 2.5 months, visiting Kuala Lumpur, Penang in Malaysia and Bali in Indonesia.
Visited grandma
Joined a new company as a full stack developer.
Fell in love
Got the opportunity to talk with ZEIT’s CEO who’s also the creator of mongoose & socket.io along with his team, to try out ZEIT now & share my honest feedback, then they decided to sponsor one of their community meetups here in Morocco.
Moved from my parents’ basement to a new place, got a new monitor, desk (adjustable height), chair & macBook pro.
Got many offers which I declined in a respectful way but recommended my friends who I trust could do a great job.
First time invited to speak at a Moroccan podcast about the JAM stack
Started working part time for Elliot as a JavaScript developer
Made 2515 contributions on GitHub

Data about my blog during 2019

57 312 page views 👀
20 508 users 📈
5032 are based in 🇺🇲
2536 🇫🇷
1630 🇩🇪
15 501 use Chrome
2460 use Safari
5992 use Windows
4882 use Macintosh
3721 use Linux
3483 use Android
2276 use iOS

Will keep editing this article until January ends I usually do.

DEV Community: smakosh

Top 10 Cheapest Providers for DeepSeek V3.2 in 2026

The Ranking

Why LLM Gateway Tops the List

Real Cost at Scale

How to Calculate Your Exact Savings

Factors Beyond Price

Getting Started

Build an AI-Powered QA Agent with Agent Browser, Vercel AI SDK, and LLM Gateway

How It Works

The Tech Stack

Setting Up

Install Dependencies

Environment

Building the Browser Tools

The API Route: Orchestrating Everything

Key Details

Switching Models

The Response Stream

Example Test Instructions

Why This Architecture Works

Running the Template

What's Next

How to Generate Images Using LLM Gateway and the Vercel AI SDK

Prerequisites

Option 1: The Images API (/v1/images/generations)

Using curl

Using the OpenAI SDK (Node.js)

Option 2: The Vercel AI SDK (generateImage)

Simple Image Generation

Conversational Image Generation with streamText

Option 3: Image Editing

Switching Providers

Customizing Output

Wrapping Up

How to Build an Agent Skill: A Practical Guide

What Is an Agent Skill?

Anatomy of a Skill

1. The Skill Manifest (SKILL.md)

2. Input/Output Schema

3. The Skill Logic

Design Principles for Great Skills

Single Responsibility

Idempotency Where Possible

Meaningful Error Messages

Rate Limiting and Caching

Security

Testing Your Skill

Registering the Skill with Your Agent

Common Pitfalls

Wrapping Up

What is an LLM Gateway?

Why LLMs Need a Gateway

What an LLM Gateway Does

Core Capabilities

How an LLM Gateway Works

Self-Hosting vs. Managed Gateways

The Cost of Not Having a Gateway

Getting Started

Deploying Next.js on GCP

Why GCP?

The Setup

Performance

How to Self-Host Next.js

Step 1: Enable Standalone Mode

Step 2: Dockerfile

Step 3a: Deploy to Cloud Run

Step 3b: Deploy to Kubernetes

Bonus: Autoscaling

Bonus: CI/CD with GitHub Actions

Takeaway

Getting Started with LLM Gateway in 5 Minutes

Step 1: Get an API Key

Step 2: Make Your First Request

Using curl

Using Node.js (OpenAI SDK)

Using Python

Using the AI SDK

Step 3: Enable Streaming

Step 4: Monitor in the Dashboard

Option 1: The Images API (`/v1/images/generations`)

Option 2: The Vercel AI SDK (`generateImage`)

Conversational Image Generation with `streamText`