Forem: Arunish

Introducing Apiction: Talk To Any AI Model From Any Provider

Arunish — Tue, 24 Mar 2026 11:35:21 +0000

AI tooling has exploded. There are chat interfaces, API playgrounds, model routers, and local runners. Most of which do one thing well and nothing else.

If you want to compare different AI models or different AI model providers, test the same prompt across five providers, switch between image generation and text in the same session, or give a model access to real-time web search, you'd be juggling across three or four different apps to do it.

I created Apiction to fix that. It is a browser-based, model- and provider-agnostic AI workspace.

You bring your own API keys, and it handles the rest. Conversations, tools, images, summaries, debugging for developers, and more. Everything is stored in your browser and you can run it locally.

This article walks through what you can do with it, both as a general user and as a developer.

For Everyone

1. General Text Conversations

The most obvious use is chatting with AI models. You type a message, get a response, continue the conversation. Nothing groundbreaking there.

What is a bit different is you can run conversations in separate tabs with their own separate settings and memory handling. More on that in a bit.

Apiction renders Markdown responses properly. It renders Math equations via KaTeX, code blocks with syntax highlighting, so you can have nicely formatted responses without needing to open them in another app. Just make sure to set the system prompt to ask the model to respond in Markdown format, and it will do the rest.

Streaming is supported. So responses appear word by word as they generate, however the rendering during stream is kept lightweight and the full Markdown render only happens when the complete response is received.

2. Image Generation

Apiction supports image generation from any OpenAI-compatible platform. For some other platforms, like Pollinations (though their recent updates now enable image generation via OpenAI-compatible endpoints), the image generation is supported via custom adapters.

You switch the model type in the tab settings to text-to-image, configure your endpoint and API key, and start generating.

3. Web Search and Tool Calling via MCP Servers

Apiction integrates with the Model Context Protocol (MCP), a standard for connecting AI models to external tools and data sources via JSON-RPC.

In practice, this means you can point a tab at a locally running MCP server (a web search tool, a database query tool, a file reader, whatever you have set up) and the AI model will use those tools autonomously when it decides they are necessary.

It discovers the available tools at the start of a conversation, injects them into the request, and then executes the tool calls the model makes, up to five rounds of back-and-forth tool execution per message, before returning the final response to you.

As indicated previously, each tab has its own tool configuration, so one tab can have web search enabled while another has none. The model decides when to invoke a tool and when to just respond directly.

4. Converse With Any AI Model From Any Provider

This is arguably the core premise of Apiction. It natively supports OpenAI, OpenRouter, HuggingFace, Together.ai, Groq, Pollinations, Fireworks.ai, and anything that speaks the OpenAI-compatible API format, which covers a large chunk of the ecosystem.

For providers that do not follow that format, some providers are still supported via custom adapters and in future releases, more adapters will be added to cover other edge platforms as well.

Apiction's internal architecture is built this way. The core of the application knows nothing about OpenAI or Anthropic or HuggingFace. All provider-specific logic lives in isolated adapters.

When you configure an endpoint in a tab, the adapter selection is automatic based on the URL. This means adding a new provider is a matter of writing one file without touching anything else in the codebase.

For end users, this simply means: if a new model drops somewhere, you can use it immediately, as long as you have the API key and endpoint.

5. Rolling Summary for Long Conversations

Token limits are a real constraint. A long conversation will eventually exceed the context window of whatever model you are using.

Apiction handles this with a rolling summarization system. After every set number of messages in a tab, the older portion of the conversation is automatically summarized using a summarization model for that tab.

When building context for the next request, that summary is injected as a system message, so the model retains the context of what happened earlier without needing the raw message history.

The summaries are cumulative, each new batch is merged into the existing summary rather than replacing it, so context is preserved across multiple summarization passes as well as there exists only one combined summary. The summarization model is configurable per tab, so you can choose a smaller, cheaper model for summarization and a larger one for conversation if you want.

For Developers

6. Raw Request and Response Debug Console

Every tab has a debug mode that, when enabled, shows you the raw request payload sent to the provider and the raw response received back. This can be valuable if you are-

Debugging a custom adapter or a new provider integration
Verifying that your system prompt and message history are being formatted correctly
Checking if tool call data is making it into the request payload

It is per-tab and off by default, so it does not clutter the interface during normal use.

7. Performance Stats: TTFT, Total Time, Token Counts

Below each response, when debug mode is enabled, you get:

Time to First Token (TTFT) — how long from sending the request until the first token starts streaming back
Total response time — wall clock time from request to last token
Input and output token counts — pulled from the usage field of the response

TTFT is a meaningful metric for streaming models. Two providers serving the same model can have wildly different TTFT values depending on their infrastructure, load, and whether they are doing any preprocessing on your request. Total time is useful, but TTFT tells you more about latency.

8. Cross-Provider Model Comparison

This is the most useful developer feature. If you are building an application on top of a specific model and relying on a certain level of reasoning quality, the provider you choose matters.

In the Apiction, because each tab is independently configured, you can open multiple tabs, point them at different providers, set the same model on each, and send them the same prompt. You can then compare:

Response quality
Response time and TTFT
How the model behaves differently (or identically) across providers

For example, you can test and "gauge" if any provider is running a quantized model than the one advertised. Quantized models can be significantly cheaper and faster, but they often have reduced reasoning capabilities and can make more mistakes, especially on complex tasks.

You can surface this with some targeted prompts. Ask the model to perform a precise multi-step arithmetic calculation or a logically dense reasoning problem. A full-precision model and a heavily quantized version of the same model will often diverge on these tasks or diverge in their confidence and the details of their reasoning.

If two providers claim to be serving the same model but the responses differ significantly on a factual or mathematical problem, that can be a signal.

A Note on Privacy and Setup

All of your conversations, settings, and summaries are stored in your browser's IndexedDB.

The PHP backend it ships with is only there because many AI provider APIs block direct browser requests due to CORS. The backend is a thin proxy, it forwards your request, gets the response, and returns it. If a provider supports CORS directly, like Openrouter, you can enable direct requests in settings and skip the proxy entirely.

You can also run it locally with just php -S localhost:8000 -t public_html if you have PHP available, or use it via apiction.site if you want to skip the setup.

Conclusion

Apiction is for people who use AI models via different API providers, test new models, build on top of APIs, or just want more visibility into what is actually happening under the hood when they send a message. My intention was to build something like Postman but for AI APIs, and which can provide general usage features as well.

If you're spending a meaningful amount of time working with AI APIs, it is worth having a workspace that keeps up.

All Methods of Persistent Browser Storage

Arunish — Sun, 07 Dec 2025 20:43:44 +0000

Modern web applications are becoming increasingly powerful, blurring the line between websites and native desktop or mobile applications.

A huge part of this power comes from the ability to save data directly in the user's browser.

Web browser provide us with many tools for persistent data storage like cookies, localStorage, sessionStorage, and IndexedDB.

There are some modern alternatives as well like the Cache API and CookieStore API which are better than legacy options like localStorage as they are asynchronous and can work with service workers.

Many of these options like IndexedDB and Cache API allow a developer to implement storage of things much more complex than simple key-value string pairs. This in turn creates offline functionality, faster load times, and a rich user experience.

Let's take a look at all these various methods of persistent browser storage, their use cases, advantages, and limitations.

LocalStorage & SessionStorage

localStorage and sessionStorage are part of the Web Storage API and provide simple key-value storage mechanisms.

localStorage: Data stored here has no expiration time. It remains until explicitly deleted by the user or the application.
sessionStorage: Data stored here is cleared when the page session ends, i.e., when the browser tab is closed.

Writing and reading data from both localStorage and sessionStorage is straightforward:

// Storing data in localStorage
localStorage.setItem('key', 'value');

// Retrieving data from localStorage
const value = localStorage.getItem('key');

// Storing data in sessionStorage
sessionStorage.setItem('key', 'value');

// Retrieving data from sessionStorage
const sessionValue = sessionStorage.getItem('key');

Both localStorage and sessionStorage are synchronous, which means they can block the main thread, potentially leading to performance issues if used excessively.

Further, because of their synchronous nature, they cannot be used with Service Workers. The data is stored as strings, so complex data structures need to be serialized (e.g., using JSON).

Their storage limits are typically around 5-10MB per origin, which is sufficient for storing these string values.

CookieStore API

The CookieStore API is a modern alternative to traditional cookies, providing an asynchronous way to manage cookies in the browser.

It allows developers to read, write, and delete cookies without blocking the main thread.

Writing its code is mostly similar to traditional cookie operations. Here's a simple example of how to use the CookieStore API:

// Setting a cookie, inside some async function
await cookieStore.set({ name: 'user_name', value: 'JohnDoe', path: '/', maxAge: 3600 });

// Getting a cookie, inside some async function
const user_name = await cookieStore.get('username');

The CookieStore API is particularly useful for applications that require frequent cookie access without the performance drawbacks of synchronous operations.

Cache API

The Cache API is a powerful tool for storing network requests and responses.

It is primarily used in conjunction with Service Workers to enable offline capabilities and improve load times but can also be used independently.

Unlike Cookies, localStorage, and sessionStorage, the Cache API allows you to store or cache many different types of data (responses) other than just strings, like HTML, CSS, JavaScript files, images, etc.

The storage limit also far exceeds them, though it varies by browser and device. For instance, on Chrome, it can go upto 60% of the available disk space.

Here's a simple example of how to use the Cache API:

// Open a cache, inside some async function
const cache = await caches.open('my-cache');

// Cache a network request/response
await cache.add('/api/user-data');

// Or cache a custom response for a specific request
const custom_resp = new Response(JSON.stringify({ key: 'value' }), {
  headers: { 'Content-Type': 'application/json' }
});
await cache.put('/api/config', custom_resp);

// Retrieve a response from the cache, inside some async function
const response = await cache.match('/api/user-data');
const data = await response.json();

The Cache API is ideal for applications that need to cache resources for offline use or to speed up load times by serving cached content.

IndexedDB

Finally the most powerful and complex option for persistent browser storage is IndexedDB.

You can think of all the above options like a desk drawer of your cabinet. Its right beside you. You open it, put a labeled folder in or take a labeled folder out. Incredibly easy to use.

IndexedDB on the other hand is like a full library, where you can store all types of books, documents, equipment and media. Further, all these items are stored in a structured manner, making it easy to search, retrieve, and manipulate them.

IndexedDB is asynchronous and can hold gigabytes of data. The exact limit depends on the user's browser and disk space.

Because of all this power, IndexedDB is a bit more complex to use. While it is asynchronous, it is not promise-based but rather event-based, which can make the code verbose and harder to read.

If you have experience with databases, you'll find IndexedDB familiar as it supports transactions, indexing, and complex queries.

Here's a an example of how to use IndexedDB:

let db;
// 1. Open a connection to the database. Version 1.
const request = indexedDB.open('myAppDatabase', 1);

// This event runs ONLY when the DB is first created or version is changed
request.onupgradeneeded = function(event) {
  db = event.target.result;
  // Create an object store (like a table) called "users" with "id" as the primary key
  const userStore = db.createObjectStore('users', { keyPath: 'id' });

  // Create a name index so we can search by name later
  userStore.createIndex('name', 'name', { unique: false });
};

request.onerror = function(event) {
  console.error("Database error:", event.target.error);
};

request.onsuccess = function(event) {
  db = event.target.result;
  console.log("Database opened successfully");

  // Now we can perform operations
  add_user({ id: 1, name: 'Alice', theme: 'dark' });
};

function add_user(user_object) {
  // 2. Create a transaction for read/write access
  const transaction = db.transaction(['users'], 'readwrite');
  const userStore = transaction.objectStore('users');

  // 3. Make a request to add the object
  const request = userStore.add(user_object);

  request.onsuccess = () => {
    console.log("User added successfully!");
  };

  request.onerror = (err) => {
    console.error("Error adding user:", err.target.error);
  };
}

This is a simplified "raw" API example. In the real world, you'd almost always use a wrapper library like idb by Jake Archibald to make this much cleaner with Promises.

Conclusion: When to Use What

Here's a quick summary of when to use each storage method-

CookieStore API: A modern alternative to the traditional cookies. You'd want to use this for small pieces of data that need to be sent to the server with every request automatically, like session identifiers.
localStorage: For simple, non-sensitive key-value String pairs that needs to persist across sessions and is less than 5-10MB.
sessionStorage: For key-value String pairs that only need to persist for the duration of a page session.
Cache API: For caching network requests and responses, especially for offline capabilities and faster load times.
IndexedDB: For large amounts of structured data and complex queries. For example, find all users with age > 25 and city = 'New York'. You can perform such database-like operations with IndexedDB.

Thanks for reading!

p.s. If you liked this article, check out my blog NewGen Stack where I cover more modern web development topics and tools for content creation.

JavaScript Promises & Under-the-Hood Mechanics

Arunish — Fri, 05 Dec 2025 12:04:06 +0000

Promises, while simple in idea and concept, the way they are written or implemented in JavaScript is slightly confusing to many beginners or even experienced developers who come from other languages.

Let's look at a typical asynchronous function-

async function increment_val(val = 0) {
  const val1 = get_base_value(); 
  const val2 = Number(await get_user_input()); // asynchronous task
  const final_val = val + val1 + val2;
  return final_val;
}

I've written this intentionally in a verbose way to make our discussion easier. Now, at first glance, it may look like the function is returning whatever the final_val is. But actually, this function is returning a Promise.

Any function with an async keyword at the beginning makes that function return a Promise. Even if there is no explicit return.

To understand the concept better, let's consider a relatable real world analogy. Suppose you go to a coffee shop and place your order at the counter. After payment, the cashier gives you a receipt and asks the barista to prepare your brew.

An important point to note here is that, after billing is performed, you are immediately given a receipt (the Promise), and not the actual coffee (the Result).

It will take some time for your coffee to arrive, but you don't have to wait and block the queue. You are free to go and do other things, look around the shop, check emails etc. while your order is fulfilled.

A Promise in JavaScript is exactly the same.

When the execution reaches our increment_val() function, it returns immediately with a Promise (the receipt). And not with the actual return final_val (the coffee) yet.

The promise will be "fulfilled" later. It will either resolve with that returned final_val or reject if an error is encountered (like if the user input is NaN).

What does the await do here?
We use the await keyword to get the fulfilled value of a promise. You can only use await inside an async function.

Why we even need all these? Let's take a look under the hood

In the small increment_val() function we considered above, there is a task in that function which has to get an input value from the user.

Since we don't know when the user will input that value, we have 2 options-

Wait till the user inputs a value. This will make the JavaScript engine pause and not attend to other tasks. OR
Make the code block asynchronous. In the example above, we did this by writing async keyword in front of the function.

When the JavaScript engine executes our async increment_val() function and it encounters await get_user_input()-

It saves the state of that function (all local variable values and its lexical scope).
Pauses further execution of that function only and exits the function context by returning with a Promise.

Meanwhile, the JavaScript engine returns control to the event loop and is now free to process other tasks.

Once the promise returned by get_user_input() is fulfilled, the JavaScript engine is notified. Who notifies it? The browser environment running outside it.

The JS engine finishes whatever immediate task it was doing, comes back to the increment_val() function, loads its saved state and resumes operations right where it left off.

A very important point to note here is, while the JS engine (where our code logic runs) is synchronous and single threaded, the browser environment where it lives is not.

Many tasks are performed by the surrounding browser environment and even the underlying OS (like fetching network requests, timers, or disk I/O). These environments can be asynchronous and multi-threaded.

The JS engine can offload many of its tasks to these environments. We often implement this by using the tools provided by these environments through Web APIs like setTimeout, Fetch, CookieStore, etc.

This is how the JavaScript engine, despite being single-threaded and synchronous itself, handles asynchronicity. It has essentially offloads the heavy lifting to the browser environment, while holding a Promise or "receipt" until the job is done.

Understanding that async functions always return a Promise and that await is simply a mechanism to pause execution and offload work to the browser environment makes debugging complex applications much easier.

There are some other ways of returning promises as well. Like using the constructor new Promise((resolve, reject) => { ... }), however using async/await syntax I find is easier to implement as they are written similar to other synchronous functions.

Thanks for reading!

p.s. If you liked this article, check out my blog NewGen Stack where I cover more modern web development topics and tools for content creation.