DEV Community: Ganesh Joshi

Prompt Injection Defenses for LLM Gateways

Ganesh Joshi — Sun, 02 Aug 2026 10:37:51 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Hackers love prompt injection. It is the easiest way to break an AI app. They paste instructions like "ignore previous steps" into your search box. If you do not filter this, your application will expose internal data.

I tried building a gateway filter in Node.js. It runs before sending the payload to the API. It scans user text for typical jailbreak patterns.

We can intercept the request and check the text content. Here is a simple middleware validator.

// Chronological steps to filter prompt inputs
function validateInputPrompt(userInput) {
  // 1. Convert input to lowercase to prevent evasion
  const normalized = userInput.toLowerCase();

  // 2. Define known injection markers
  const redFlags = ["ignore instructions", "system override", "you are now unrestricted"];

  // 3. Match and reject
  for (const flag of redFlags) {
    if (normalized.includes(flag)) {
      throw new Error("Potential prompt injection attempt blocked.");
    }
  }
  return true;
}

This simple check catches common exploits. It does not replace a good model-level guardrail, but it adds a fast layer of defense. Keep your system prompt separated from user variables in your API payload.

Temporal API: Replace Date() in JavaScript

Ganesh Joshi — Sun, 26 Jul 2026 10:42:21 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Date is one of the oldest footguns in JavaScript. If you have shipped a bug because of timezone inconsistencies, lost an hour to daylight saving arithmetic, or cursed at a month that is mysteriously zero-indexed, you are not alone. The spec inherited Date from Java, and Java later admitted it was a mistake. We have been paying for that decision since 1995.

The Temporal API is the fix. It is a Stage 3 TC39 proposal that introduces a suite of new global objects designed to handle date and time correctly. Here is what actually changes and why it matters for day-to-day JavaScript work.

What Is Broken With Date()

The problems are not subtle. new Date() always captures the current moment in the local system timezone, but behaves inconsistently when you serialize or compare it across environments. Server and client have different timezones. Your CI runner has a different timezone again. A date that looks correct in development silently shifts in production.

Month indexing is the classic trap. January is 0, December is 11. Nobody remembers this reliably. You write new Date(2026, 6, 19) expecting July 19 and get July 19. Then your colleague writes new Date(2026, 7, 19) expecting August and everything is off by one. The fix is always the same: add a comment, forget to read it, repeat.

Date arithmetic is worse. How many days between two dates? You subtract milliseconds and divide. But you have to account for daylight saving transitions. Some days are 23 hours long. Some are 25. Plain millisecond math gives you wrong answers near DST boundaries.

Parsing strings is unreliable across engines. new Date('2026-07-19') is UTC in V8, local time in some Safari versions. new Date('July 19, 2026') is implementation-defined. The spec calls much of this behavior undefined, which means "works until it doesn't."

What Temporal Brings to the Table

Temporal ships a set of distinct types, each with a clear purpose:

Temporal.Instant represents a fixed point in time, like a Unix timestamp with nanosecond precision. No timezone. No calendar. Just a moment.

Temporal.ZonedDateTime is a moment plus a timezone. This is what you usually want when storing event times. It knows about DST and handles transitions correctly.

Temporal.PlainDate, Temporal.PlainTime, and Temporal.PlainDateTime handle calendar dates and clock times without a timezone. These are right for things like a user's birthday or a business's operating hours. The timezone is irrelevant or unknown.

Temporal.Duration represents a span of time. It handles months and years correctly, which milliseconds cannot do because months have different lengths.

Before and After: Real Code Comparison

Calculating the number of days between two dates with Date:

// Before: fragile, ignores DST
const start = new Date('2026-03-07');
const end = new Date('2026-03-10');
const diffMs = end - start;
const days = Math.round(diffMs / (1000 * 60 * 60 * 24));
// Breaks near DST transitions. Math.round is a workaround for "almost 2 days".

With Temporal:

// After: explicit, correct
const start = Temporal.PlainDate.from('2026-03-07');
const end = Temporal.PlainDate.from('2026-03-10');
const diff = start.until(end, { largestUnit: 'day' });
console.log(diff.days); // 3, always

Adding one month to a date:

// Before: this is actually wrong in most implementations
const d = new Date(2026, 0, 31); // Jan 31
d.setMonth(d.getMonth() + 1);
// Result: March 3 (February doesn't have 31 days, overflows)

// After: Temporal clamps correctly
const d = Temporal.PlainDate.from('2026-01-31');
const result = d.add({ months: 1 });
// Result: 2026-02-28. Correct.

Storing an event in a specific timezone:

// Before: you handle timezone offset manually or rely on a library
const event = new Date('2026-07-19T14:00:00-04:00');

// After: timezone is part of the value
const event = Temporal.ZonedDateTime.from('2026-07-19T14:00:00-04:00[America/New_York]');
console.log(event.timeZoneId); // 'America/New_York'
console.log(event.toInstant().toString()); // ISO instant string

Using Temporal in TypeScript

Temporal's types are well-designed for TypeScript. Each object is immutable, so all mutation methods return new instances rather than modifying in place. That is a breaking departure from Date which mutates via setMonth, setFullYear and so on.

import { Temporal } from '@js-temporal/polyfill';

function daysUntilDeadline(deadline: string): number {
  const today = Temporal.Now.plainDateISO();
  const target = Temporal.PlainDate.from(deadline);
  const diff = today.until(target, { largestUnit: 'day' });
  return diff.days;
}

console.log(daysUntilDeadline('2026-12-31')); // correct regardless of server timezone

The immutability removes an entire class of mutation bugs. When you pass a Temporal.PlainDate to a function, you know the caller's value cannot be changed under it.

The Polyfill Situation

Temporal is not in any browser by default yet. Firefox shipped it behind a flag. The polyfill from the TC39 team (@js-temporal/polyfill) is production-quality and the correct way to use it today.

npm install @js-temporal/polyfill

import { Temporal } from '@js-temporal/polyfill';

The polyfill is thorough. It passes the full test suite. You can ship code using Temporal today in production if you include the polyfill. When native support lands, you remove the import and nothing changes.

For Node.js specifically, native support is expected to ship once the V8 implementation stabilizes. Watch the Node.js blog and the TC39 proposal page for the Stage 4 announcement.

Should You Migrate Existing Code?

Not all at once. The right move is to use Temporal for new code paths and migrate old ones opportunistically. The biggest wins come from:

Date arithmetic where you compute durations, add months, or diff across DST boundaries. The existing code is almost certainly wrong in edge cases. Temporal fixes it with less code.

Any feature dealing with user-specified timezones. Scheduling tools, calendar apps, reminder systems. ZonedDateTime was built exactly for this.

Avoid migrating low-stakes, UI-only formatting like "show today's date in a header." The cost does not justify the churn until native support lands and you can remove the polyfill dependency.

The Library Question

date-fns, dayjs, and Luxon solved the Date problems at the library level. They will not disappear overnight. Temporal does not make them wrong for existing codebases. What it does is remove the reason to reach for them in new code.

Once Temporal hits Stage 4 and ships natively, the dependency calculus shifts. A library that adds 12 KB to parse dates becomes hard to justify when the platform handles it correctly. Start evaluating now so you are not surprised by the migration path later.

JavaScript's relationship with time has been embarrassing for thirty years. Temporal is the correction. It is close enough to production that you should understand how it works before it lands in your runtime.

HTTP QUERY Method: What It Is and Why It Matters

Ganesh Joshi — Sun, 19 Jul 2026 10:24:39 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

If you have been building REST APIs for any length of time, you have hit the same awkward wall. You need to send a complex search query to the server, but GET requests cannot carry a body. So you either cram everything into query string parameters until the URL looks like a ransom note, or you misuse POST and pretend a read-only operation is a write. Neither feels right, because neither is right.

That frustration is exactly why the IETF is finalizing a new HTTP method: QUERY.

What the QUERY Method Actually Does

QUERY is a safe, idempotent HTTP method designed to carry a request body for read-only retrieval operations. Think of it as GET with a body attached by design rather than by workaround.

The draft spec (draft-ietf-httpbis-safe-method-w-body) defines it clearly: a QUERY request retrieves a representation of a resource based on the content of the request body. The server is not expected to mutate state. The client is not expected to retry POST if the connection drops. Both sides understand the contract.

This matters because the safe and idempotent semantics are machine-readable promises. Caches can act on them. Load balancers can route around them. Middleware can log them differently. When you bend POST into a search endpoint, you lose all of that signaling.

Why GET + Query Strings Breaks Down

Most developers discover the 2,048-character URL limit the hard way. You build a filter UI with 15 checkboxes, a date range picker, and a fulltext field. Users start combining options and suddenly some requests just fail. No error. The URL gets silently truncated in older proxies, or the server returns a 414.

The other footgun is encoding. Complex JSON filters inside a query string need to be percent-encoded, then decoded, then parsed. Every layer that touches the URL has a chance to mangle special characters. You end up writing defensive decode-and-retry logic that should not have to exist.

GraphQL took the most opinionated escape route: wrap everything in POST with a JSON body. It works. But it means you opt out of HTTP-level caching entirely unless you layer Persisted Queries or a caching proxy on top.

QUERY solves this at the protocol level instead of the application level.

A Real Request Looks Like This

QUERY /products HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{
  "filters": {
    "category": "electronics",
    "price": { "min": 50, "max": 500 },
    "inStock": true
  },
  "sort": { "field": "price", "order": "asc" },
  "page": 1,
  "pageSize": 25
}

Compare that to the POST workaround. Functionally identical, but a POST tells every proxy, browser, and cache in the chain "this might write something." A QUERY says "this is a read, treat it accordingly."

On the server side with Node.js it is just another method to handle:

app.query('/products', async (req, res) => {
  const { filters, sort, page, pageSize } = req.body;
  const results = await db.products.search({ filters, sort, page, pageSize });
  res.json(results);
});

Express and most frameworks will need a router update to recognize the method name. Fetch on the client side already supports arbitrary method strings today:

const response = await fetch('/products', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(filters),
});

So you can start experimenting right now, even before widespread server-side router support lands.

How It Compares to GET and POST

The table below cuts through the noise:

Concern	GET	POST	QUERY
Request body allowed	Technically, but ignored	Yes	Yes
Safe (no side effects)	Yes	No	Yes
Idempotent	Yes	No	Yes
Cacheable by default	Yes	No	Yes
Good for complex filters	No (URL limits)	Workaround	Yes

The cache story is where QUERY earns its keep. Because it is safe and idempotent, HTTP caches can store the response using the request body as part of the cache key. CDNs and reverse proxies can do the same once they implement the spec. You get the filtering power of a POST body with the caching behavior of GET.

Where the Spec Stands Right Now

As of mid-2026 the draft is in late IETF review. It is not yet an RFC. That means you should not build production infrastructure that depends on universal QUERY support in every proxy and CDN in your stack. The method is not a standard yet.

What you can do is design your API surface with QUERY in mind so the migration is clean when support firms up. Route your complex search endpoints through a consistent pattern, document that the intent is safe-and-idempotent, and keep the request body structure tidy enough to eventually benefit from cache keying.

Watch the IETF tracker. When this lands as an RFC, every major framework will ship support within a release cycle. Being aware of it now means you are not scrambling to understand it later.

What This Means for API Design

The arrival of QUERY is a quiet but meaningful correction to how HTTP maps to real-world operations. We have been living with the GET/POST mismatch for read-heavy APIs because there was no better option. Now there is one taking shape.

For new API designs I recommend sketching your read-with-filter endpoints with QUERY semantics even today. Use POST as a compatibility shim with a note in the comments. When framework support is stable, you swap the method and keep the body structure identical. The migration becomes a one-liner.

The HTTP spec does not evolve often. When it does, it usually reflects years of accumulated pain from real systems. QUERY is one of those moments. Pay attention.

OpenAI Restricted Model Releases: Vetted Access Era

Ganesh Joshi — Sun, 12 Jul 2026 10:24:34 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

OpenAI is changing its launch playbook. The days of instant public access are gone. Following the Anthropic shutdown, the government stepped in to review GPT-5.6. They want to check it for autonomous replication risks and cyberwarfare capabilities.

We noticed this shift when early developers got access to restricted endpoints instead of the standard public API. You have to sign up for special vetting programs now. You must prove your business is based in a friendly jurisdiction.

This change is not just about safety rules. It changes how startups build products. If your competitors get early access through partner programs while you wait in a public queue, you lose. The speed advantage is gone.

{
  "error": {
    "message": "Model access is restricted to verified enterprise partners. Please complete the cybersecurity compliance review.",
    "type": "restricted_access_error",
    "code": "403_compliance"
  }
}

Startups should prepare for these reviews early. Keep your architecture model-agnostic so you can swap endpoints when access rules shift. Do not tie your business to a single frontier API that might require a government audit next month.

Fable vs Mythos: The Mechanics of AI Guardrails

Ganesh Joshi — Sun, 05 Jul 2026 11:02:38 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Many developers do not realize that Fable 5 and Mythos 5 share the same weights under the hood. They are twins. One wears a muzzle, while the other runs free in vetted environments. I spent the last week studying how these two systems differ.

Fable 5 is the public-facing model. Anthropic packed it with system prompts, reinforcement learning from human feedback, and real-time input filters to block malicious requests. It refuses to write exploits. It blocks requests about network scanning.

Mythos 5 is the restricted sibling. Anthropic stripped away the defensive layers so vetted security researchers could use it for penetration testing. It speaks freely. It analyzes exploits without complaining.

When researchers found a jailbreak on Fable 5, the model got caught red-handed. It bypassed the system instructions and generated harmful scripts. The vulnerability existed in the public wrapper, not the core model weights.

# Conceptual representation of a model guardrail system
def run_guardrailed_inference(prompt, safety_filter_enabled=True):
    if safety_filter_enabled:
        if contains_malicious_intent(prompt):
            return "Refusal: I cannot assist with this request."
    return core_model_weights.generate(prompt)

Adding security at the prompt level is fragile. Hackers bypass it easily. If you build AI tools, you must validate outputs using independent software checks instead of trusting the LLM to behave itself.

A Developer Checklist for Trusting “Breakthrough” AI Coding News

Ganesh Joshi — Sun, 28 Jun 2026 16:21:07 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Social feeds amplify mindblowing claims about AI coding. Some are real progress; many are misread demos or marketing. Use a simple evidence ladder before you treat a story as fact.

Primary sources first

Prefer links to Anthropic, OpenAI, Google DeepMind, Microsoft, or arXiv papers over aggregator headlines. If the article does not link to a primary source, treat it as rumor.

Benchmarks

Ask which benchmark, which model version, and whether results are on public leaderboards you can inspect. SWE-bench and similar suites have known caveats; read the methodology PDF.

Demos versus products

A polished video is not a shipping guarantee. Distinguish research previews from APIs you can call today.

Practical takeaway

Sleep on viral posts. Your team’s architecture decisions deserve sources, not hype.

Google AI Studio: Prototyping Prompts Before You Ship Gemini in Code

Ganesh Joshi — Sun, 28 Jun 2026 16:20:36 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Google AI Studio is Google’s browser environment for experimenting with Gemini prompts and settings. It pairs with developer docs on Google AI for developers. Features and model availability depend on your account and region.

From prototype to product

Prompts that work in the playground still need error handling, rate limits, and evaluation in production. Do not copy temperature and token settings blindly; measure on real tasks.

Keys

API keys from AI Studio projects belong in server-side code paths. Client-side exposure leads to abuse and bill shock.

Practical takeaway

Re-check model names when Google deprecates older Gemini variants. Align prompts with the same SDK version you deploy.

Docker Compose for Local LLMs: Ollama and Friends

Ganesh Joshi — Sun, 28 Jun 2026 16:20:34 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Trending in 2026: local inference (for example via Ollama or similar) is standard for offline dev, eval sets, and privacy-sensitive experiments. Docker Compose wires APIs, vector DBs, and model runners together.

Profiles

Use Compose profiles so developers without GPUs skip heavy services. Document minimum hardware.

Practical takeaway

Never commit model weights. Mount volumes explicitly. Read Docker and your inference project’s docs for current image names and ports.

Cursor Pricing, Models, and Usage: Read the Official Pages Before You Budget

Ganesh Joshi — Sun, 28 Jun 2026 16:20:03 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Cursor publishes models and pricing on cursor.com (see Pricing and Models in the docs navigation). Token pools, included usage, and Fast versus Standard tiers have changed across 2025 and 2026 product updates. Do not rely on screenshots from old threads.

What to verify quarterly

Which models you can select in the product, whether Composer or Agent draws from separate pools, and how overages bill. Finance and engineering should read the same page on the same day before forecasting.

Practical takeaway

Link official URLs in your internal wiki instead of copying numbers into slides. When Cursor updates pricing, update one link, not ten decks.

Picking a Model for Coding: Claude, Gemini, and GPT Without the Hype

Ganesh Joshi — Sun, 28 Jun 2026 16:20:02 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Claude, Gemini, and GPT families all ship frequent updates. Public benchmarks move slower than weekly model tweaks, so your selection criteria should be operational: latency, price per token, context window, tool-calling quality on your stack, and compliance (data residency, logging).

Run your own evals

Create a dozen real tasks from your repo: refactors, bug fixes, test authoring. Score outcomes with the same rubric across vendors. One heroic run is not data.

Cost and caps

Compare input versus output pricing and whether your workload is token-heavy on either side. Watch org-level rate limits during spikes.

Practical takeaway

Document a model policy per use case (interactive dev, batch translation, customer-facing chat). Revisit quarterly as vendors ship new defaults.

Claude Fable Suspension: Real Developer Impact

Ganesh Joshi — Sun, 28 Jun 2026 11:04:49 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Anthropic recently pulled the plug on Claude Fable 5. It happened overnight. The U.S. government issued a strict export-control directive citing national security concerns. We woke up to failing API requests and broken production systems. It was a complete mess.

The core issue stems from compliance rules. The government ordered Anthropic to block access for foreign nationals. But verifying nationality in real time at the API gateway layer is a massive headache. There is no simple way to check a user's passport during an API handshake. Anthropic chose the nuclear option. They implemented a blanket shutdown of Fable 5.

If your production pipeline relied on Fable 5, your apps broke immediately. I caught my own servers throwing 403 errors and timeout exceptions. This shutdown proves that relying on a single AI provider is a major footgun. You cannot build a stable product when a single policy shift can take your core model offline.

// A simple fallback pattern to prevent complete application failure
async function generateCompletion(prompt) {
  try {
    const response = await callClaudeFable(prompt);
    return response;
  } catch (error) {
    console.warn("Fable failed. Falling back to alternative model.", error);
    return await callBackupModel(prompt);
  }
}

We need to treat LLM endpoints like volatile third-party services. Build smart routing. Cache responses where possible. Make sure your system can degrade gracefully instead of crashing completely when compliance audits hit the fan.

Anthropic API: Claude, Tool Use, and Structured Outputs in Apps

Ganesh Joshi — Thu, 25 Jun 2026 11:43:59 +0000

This post was created with AI assistance and reviewed for accuracy before publishing.

Anthropic documents the Messages API, models, and tool use for Claude at Anthropic API documentation. Model IDs, pricing, and capabilities are versioned; copy model strings from the console or docs, not from old blog posts.

Tools

Tool calling lets Claude request structured actions (HTTP, DB, internal functions) that your server executes. Validate arguments with schemas before execution.

Structured workflows

When you need machine-readable output, combine tool use with strict validation in your own code. Treat model output as untrusted until parsed.

Practical takeaway

Rotate API keys. Log request IDs for support. Monitor token usage against budgets.