Docs
Cookbook

Migrating to Tase

Move an existing OpenAI-compatible integration to the Tase API: change the base URL, the key, and the model name — everything else stays.

If your application already speaks the OpenAI chat completions format, migrating to Tase is a configuration change, not a rewrite. Three values change: the base URL becomes https://api.tase.app/v1, the API key becomes your tase_sk_... key, and the model name becomes tase-8b. Your request-building code, response parsing, and streaming handlers keep working as they are.

Before and after

JavaScript

// Before - an existing OpenAI-compatible setup
import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

const completion = await client.chat.completions.create({
  model: 'your-current-model',
  messages: [{ role: 'user', content: 'Summarize my day.' }],
});
// After - the same code pointed at Tase
import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.TASE_API_KEY, // tase_sk_...
  baseURL: 'https://api.tase.app/v1',
});

const completion = await client.chat.completions.create({
  model: 'tase-8b',
  messages: [{ role: 'user', content: 'Summarize my day.' }],
});

Python

# Before - an existing OpenAI-compatible setup
import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

completion = client.chat.completions.create(
    model="your-current-model",
    messages=[{"role": "user", "content": "Summarize my day."}],
)
# After - the same code pointed at Tase
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TASE_API_KEY"],  # tase_sk_...
    base_url="https://api.tase.app/v1",
)

completion = client.chat.completions.create(
    model="tase-8b",
    messages=[{"role": "user", "content": "Summarize my day."}],
)

What stays the same

  • The messages arraysystem, user, assistant, and tool roles behave identically. Existing prompt and history code needs no changes.
  • Tool calling — the tools parameter, tool_calls in responses, and tool_call_id result messages all follow the same wire format.
  • Streaming"stream": true returns the same server-sent event chunks ending in data: [DONE]. SSE parsers and SDK streaming helpers work unchanged.
  • Response shapechoices[0].message.content, finish_reason, and the usage token counts are where they always were.

What to check as you migrate

Tool schemas become optional for built-in tools

The built-in Tase tool schemas are trained directly into the model, so requests that use them do not need a tools payload at all — the model already knows every built-in tool and its exact argument shape. Keep sending schemas for your own custom tools; drop them where you are calling built-in ones and your requests get smaller and faster.

Route deep, long-context reasoning deliberately

tase-8b is compact by design: it excels at tool selection, extraction, and low-latency chat. For jobs that need deep reasoning over very long context — long-document analysis, involved multi-step planning — rely on routing, which detects these requests and escalates them to a larger model automatically. See the Models page for how routing decides.

Migration checklist

  1. 1

    Create a Tase API key

    Generate a key in your Tase dashboard and store it as TASE_API_KEY in your secrets manager or environment.
  2. 2

    Point the client at Tase

    Set baseURL (or base_url) to https://api.tase.app/v1 and swap the key. In most codebases this is one constructor.
  3. 3

    Replace the model name

    Search for hard-coded model strings and replace them with tase-8b. If the model name already comes from configuration, change one config value.
  4. 4

    Run your existing test suite

    Because the wire format is identical, your current integration tests are the migration tests. Pay attention to any test that asserts on exact model output text.
  5. 5

    Verify streaming and tool calls in staging

    Exercise one streamed response and one tool-calling round end to end, and confirm usage numbers are flowing into your cost tracking.
Do I need to rewrite my prompts?+

No rewrite is required — system and user messages carry over as-is. As with any model change, spot-check your most important prompts and tighten wording where behavior differs.

Can I run both providers side by side during the migration?+

Yes. Since only the constructor differs, instantiate two clients and switch per request behind a feature flag. This is the safest way to compare quality and latency on real traffic before cutting over.

Will my temperature and max_tokens settings still apply?+

Yes. Standard sampling and length parameters are part of the compatible wire format and behave the same way. Recalibrate values only if you tuned them tightly to your previous model.

Make your first Tase request

The quickstart takes you from key to completion in about five minutes.

Open the quickstart