Tempr blog

Every MCP tool call, through one place you control

2026-10-07T00:00:00Z

MCP servers are how coding agents get real tools: open a GitHub issue, update a Linear ticket, search Notion, query a database. Connecting one is easy. Connecting one for a whole team raises the questions a security review will ask:

Where do the credentials live? Usually in a config file on every developer's laptop and in every CI runner, often as one shared token.
Who does the call run as? With a shared token, every agent acts as the same bot account, so the tool's own audit trail can't say which person asked.
What goes out, and what comes back? An agent can paste a secret into a tool call. A tool's result goes straight into the model's context, and it can carry text written to steer the model.
What happened? Nobody has a record of which tools were called, by whom, with what.

Tempr's Gateway now answers those in one place. Remote MCP servers are added once, in the Portal, and every call Tempr's IDE extensions and CLI make to a remote server goes through the Gateway's MCP relay on its way to the server. Any other MCP client can use the same relay at /mcp/proxy/{server} with a Gateway key.

Credentials stay on the server

A server's address, its headers and every member's tokens are stored encrypted on Tempr's servers. The relay adds them to each request on the way out, so laptops, CI runners and editors never hold them. There's nothing to copy into a dotfile, nothing to leak from a laptop, and nothing to rotate on fifty machines when someone leaves.

Each call runs as the person asking

For servers that sign people in with OAuth, such as GitHub, Linear or Notion, you can turn on member sign-in. Each person then connects their own account, and the agent acts with that person's permissions. A ticket the agent opens shows who actually asked for it, and someone without access to a private repository can't reach it through the agent either.

Setting that up is usually the hard part of OAuth, so Tempr does it for you. It registers itself with the server's OAuth provider, using a Client ID Metadata Document where the provider supports one and dynamic registration otherwise, or uses an OAuth app you register yourself where a provider requires that, as GitHub does. Members' tokens are stored encrypted and refreshed when they expire, and they're revoked when someone signs out, is removed, or leaves the organization.

A member who hasn't signed in yet still sees the server's tools. Their first tool call asks them to sign in, using MCP's own request for it, and every Tempr client shows that as a link. The CLI prints it and opens it in your browser, and the IDE extensions show a sign-in link on the tool call, so signing in takes one click in the middle of a task.

Tool traffic is checked both ways

The relay reads every tool call and every result, and three checks run on them. You choose how strict each one is, for your account or your whole organization, and a key can override them:

What goes out. Secrets and personal data in a tool call's arguments, such as bearer tokens, JWTs, AWS keys, sk- style API keys, email addresses and card-like numbers, are flagged in the request log by default. Set it to block, and the call is refused and never sent.
What comes back. The same kinds of data in a tool's result are redacted by default, masked before the model ever reads them. Set it to block, and the whole result is withheld.
Planted instructions. Text in a tool's result or description that's shaped like instructions to the model, such as "ignore previous instructions" or a fake system prompt, is flagged by default, or can be withheld. Hidden characters that can carry instructions a person can't see, such as zero-width spaces, Unicode tag characters and direction overrides, are removed.

We're careful about what this is. The checks catch the common shapes of secrets and injected instructions. They aren't a data-loss-prevention product, and no filter makes prompt injection impossible. What they give you is a first line of defence on the path every tool call takes, and a record of what they caught.

Tools can't change quietly

An MCP server describes its tools to the model: a name, a description and the input it expects. Those descriptions are instructions the model follows, and a server can change them at any time, including after your team has started relying on a tool that looked harmless.

So Tempr pins each tool's definition the first time it sees it. When a server changes a tool's name, description or input schema, the change goes to your organization's audit log, with the old and new description, and to your Gateway webhook as mcp.tool_changed. The tool keeps working, because most changes are ordinary updates, but nothing changes without your team being told.

What admins see

Every tool call is in the request log with its server, its tool, and anything that was flagged or redacted. Each Gateway key has its own list of allowed MCP servers and its own limits. For servers with member sign-in, owners and admins see who's signed in, with which account and scopes, and when it was last used, and they can revoke one member or everyone at once.

A few protections apply to every server, whatever its settings. The relay refuses private-network addresses and redirects, so a server entry can't be used to reach your internal network. And when a tool asks to be paid per call, the Gateway refuses it and never pays; the paid MCP tools post covers why.

Getting started

Add a remote server in the Portal under MCP servers, choose its sign-in setting, and set the guardrails under MCP credentials. Once you're signed in, every Tempr client can use it. The Gateway page has the overview, and the reference covers the guardrails and member sign-in in detail. Connecting servers in the IDE is in the MCP docs.

A sandbox for the agent's commands, with nothing to install

2026-10-07T00:00:00Z

A coding agent is most useful when it can run things: build the project, run the tests, try a fix, run the tests again. It's most worrying for the same reason. Every command it runs can do anything you can do on that machine.

Approval prompts are the usual answer, and they work while you're watching. They don't work for a run nobody is watching, in CI or a long task you've left alone. An allow-list helps, but only for the commands you thought of in advance. The agent's next idea, a script it just wrote or a tool it wants to try, stops the run.

The Tempr CLI's sandbox turns that around. Instead of deciding which commands may run, it limits what any command can do, and then lets the agent run whatever it needs.

What the sandbox allows

Inside the sandbox, the agent's commands:

can change files only in the current folder, the temp folders and the package caches builds write to: npm's, pip's, NuGet's, Go's, Cargo's, Gradle's and Maven's. Everything else, your home folder, /etc, other projects, is read-only to them.
can read anything, as a build needs to.
can't open network connections, if you choose. Cutting off the network blocks outgoing TCP connections, while name lookups still work.

Because the damage a command can do is limited, any command runs without asking, in every approval mode, even one with no allow-list entry. A few still ask: commands that delete, publish or force-push, because those can do harm inside the project too. When the sandbox blocks something a command really needed, such as a download, the agent can ask to run that command outside the sandbox, and that always asks you first. A run with nobody to ask refuses it.

You turn it on with --sandbox, or for every run with tempr config set-sandbox on. Since CLI 0.9.8 it's also the default for runs where nobody decides command by command, --yolo and autopilot in CI, with the network left on there. Cutting the network also blocks connections to localhost, and a test suite that starts a local server needs those.

Why not bubblewrap

The usual tool for sandboxing a process on Linux is bubblewrap, which builds an isolated view of the system using the kernel's namespaces. We tried it first, on the systems our users actually run, and it failed on two of them:

Stock Ubuntu 24.04, a very common Linux on developer machines and CI runners, restricts the unprivileged user namespaces bubblewrap needs. As a normal user, it couldn't start.
A default Docker container, which is where many CI jobs and our own container recipe run, doesn't allow creating new namespaces either.

A sandbox that's missing in the two places it matters most isn't much of a sandbox. So we built ours on Landlock, a security feature in the Linux kernel itself. With Landlock, a process restricts itself: it declares which folders it may write to and whether it may connect out, and from then on neither it nor anything it starts can do more. It needs no install, no root and no namespaces. It works on stock Ubuntu 24.04 and inside a default Docker container. Restricting files needs Linux 5.13 or later, and restricting the network needs 6.7 or later. Inside WSL2 on Windows, it works too.

The parts Landlock can't do

Landlock grants access to whole folders. The project folder has to be writable, or nothing could build. But a few files inside it can do harm later, outside the sandbox: git hooks run on your next commit, git's config can point at a program to run, and .agentcommands.json is the agent's own allow-list. A command inside the sandbox could change any of them, and the change would take effect after the sandbox was gone.

So Tempr takes a copy of .git/hooks, .git/config and .agentcommands.json before each sandboxed command, and puts back anything the command changed. The agent is told when that happens, so it doesn't build on a change that's been undone.

Making real builds work

A sandbox that blocks a normal build is one people turn off, so we spent most of our time on what builds actually need to write.

Package caches were the obvious part. A restore or install writes to a per-user cache outside the project, so those folders are writable: npm's, Cargo's and Maven's from the first release, NuGet's and Go's module cache from 0.9.8, and pip's and Gradle's too.

.NET took more work. The dotnet tool needs to write small marker files in ~/.dotnet, and fails if it can't. The documented switch to skip that didn't help in our tests on .NET 10. Making ~/.dotnet writable wasn't an option either, because it holds global tools, programs that run outside the sandbox later. So inside the sandbox, dotnet gets its own folder for those files, in ~/.cache/tempr/sandbox-dotnet. Then it turned out NuGet follows that same setting for its packages and configuration, so Tempr points NuGet back at your real ~/.nuget/packages and package sources. The result is that dotnet builds, restores and tests inside the sandbox, even on a machine where it has never run before, while your global tools stay read-only.

Checked on real machines

Both releases that changed the sandbox were checked on fresh cloud machines running stock Ubuntu 24.04, as a normal user, on both Intel and Arm (AWS Graviton) processors. Each check confirmed that writes to the project and the caches work, writes to the home folder and /etc are denied, the network is blocked when it should be and open when it should be, and pipes still work. One lesson from that: an emulated Arm machine reported no Landlock at all, so it couldn't prove anything. Only real hardware could.

Where it runs, and where it doesn't yet

The sandbox runs on Linux. On macOS and Windows it isn't available yet. What happens there depends on whether you asked for it:

If you asked for it with --sandbox and it can't run, nothing runs. The CLI exits with code 7 instead of running your commands unsandboxed.
The default for --yolo and CI wasn't something you asked for, so where the sandbox can't run, those runs go ahead as they did before it existed, and an interactive session tells you so.

tempr doctor tells you what the sandbox can do on your machine. It covers the commands the agent runs, the .NET test tools and the agent's diagnostics. It doesn't cover commands you type yourself with !command, or MCP servers.

The details are in the sandbox section of the CLI reference, and Scripts, pipes and CI shows it in a pipeline. For more on running the CLI unattended, see Pipe it to the agent.

Pipe it to the agent: the Tempr CLI in scripts and CI

2026-10-07T00:00:00Z

The quickest way to give an agent context is often the one you already use for everything else on the command line: a pipe. The output you're looking at, a diff, a build log, a list of commits, goes straight into the agent along with what you want done with it.

bash

git diff | tempr "Review this change for bugs and missing tests"

The Tempr CLI is built to fit into that kind of workflow. It reads stdin, writes to stdout, reports in JSON when you ask it to, and exits with a code a script can act on. Here are the patterns we use most, and what had to be right underneath for them to work.

The prompt says what, the pipe says what with

With a prompt argument, piped text follows the prompt as context. With no prompt, the piped text is the whole prompt, so you can write the instruction into the stream yourself:

bash

# Explain a failure from a build log
cat build.log | tempr "Why did this fail? Cite the relevant lines."
# Put the instruction in the stream
{ echo "Summarize these commits for the release notes:"; git log --oneline v1.2..; } | tempr
# A prompt too long or too quote-heavy for the command line
tempr --prompt-file task.md

A piped run takes one turn and exits, so it works in a script. For a single file, you don't need a pipe at all: @path in the prompt attaches it, as in tempr "add doc comments to @src/Payment/PaymentRequest.cs".

What we fixed in 0.9.11

Two things got in the way of this until CLI 0.9.11, released on October 5.

Piped input was ignored whenever there was a prompt. git diff | tempr "Review this" sent the prompt and dropped the diff, so the model reviewed nothing. Now the prompt goes first and the piped input after it, as it does in Claude Code and Codex. The CLI waits up to 3 seconds for piped input to start, so a slow git diff on a large repository still makes it. If nothing arrives, which happens when a parent process leaves stdin open without writing to it, the prompt runs on its own and the CLI notes that on stderr. Redirect stdin from /dev/null (NUL on Windows) to skip the wait.

Whitespace was being collapsed. Blank lines, indentation, and lines holding only spaces were squeezed into single spaces before the prompt reached the model. For prose that hardly matters. For a diff it matters a lot: lines ran together, and a review could report formatting problems that weren't in the code. Prompts now reach the model exactly as written, blank lines and indentation included, and that fix applies to tempr acp in editors too.

Asking it to act, not just answer

Piping is for context. When the agent should change something, give it the goal and let it work:

bash

tempr -y "fix the failing test in CartServiceTests and run the suite"

-y lets file edits and allow-listed commands run without stopping to ask. Commands that aren't on the allow-list, and anything that deletes, publishes or force-pushes, still need approval. When there's no terminal to approve them on, because input is piped, output is JSON, or the run is in CI, they're refused, and the model is told why so it can find another way or stop. You add the commands a job needs with tempr config allow-command <prefix>, or an .agentcommands.json file at the workspace root.

On Linux, -y also runs the agent's commands in a sandbox by default, built on the kernel's Landlock, with no install and no special privileges. Commands can change the checkout, temporary folders and package caches, and nothing else. --sandbox cuts off the network as well. If you ask for the sandbox and the machine can't provide it, nothing runs.

Output a script can read

--json turns the run into newline-delimited JSON: a first line describing the session, one line per event as the agent works, and a final result line.

bash

tempr --json -y "list the public types in this project" \
  | tail -n 1 \
  | jq '{status, summary, files: .filesChanged}'

The result line carries the final answer as summary, the files the agent changed, token usage, and a status. The exit code makes the same distinctions, so a script can branch on it without parsing anything:

0, ok: the turn finished.
1, error: something went wrong: the server, the network, a tool.
2: the command line didn't make sense.
3: not signed in, or the license has no plan.
4, step-limit: the run hit its step limit with work left. --continue picks it up.
5, tool-refused: a tool call was refused, usually because nothing could approve it.
6, cost-limit: the run reached its price ceiling.
7: you asked for the sandbox and it can't run on this machine, so nothing ran.

In CI

Put those together and an agent becomes a pipeline step. A pull-request review in GitHub Actions:

yaml

- env:
    TEMPR_LICENSE_KEY: ${{ secrets.TEMPR_LICENSE_KEY }}
  run: |
    { echo "Review this PR:"; git diff origin/main...; } \
      | tempr --json --max-cost 1.00 -m anthropic/claude-sonnet-4-6

A few habits make this reliable:

Keep the key in a secret. The CLI signs in from TEMPR_LICENSE_KEY, so the key never appears on a command line or in a log.
Name the model. -m keeps the run from depending on a default set on someone's machine.
Cap the spend. --max-cost puts a ceiling on the run, and exit code 6 tells the job it was reached.
Keep tasks read-only unless the workspace is disposable. Review, summarize and triage are safe anywhere; edits belong on a runner you can throw away.

CI systems set the CI variable, and the CLI notices: a tool call that would have asked for approval is refused instead of waiting forever, and there's no logo, update notice or crash report in your logs.

The full guide, with a complete workflow file, is Scripts, pipes and CI in the docs, and every flag is in the CLI reference. If you haven't installed the CLI yet, start on the CLI page.

Paid MCP tools: refused clearly, never paid

2026-10-07T00:00:00Z

MCP servers give an agent tools: search an issue tracker, query a database, read a wiki. Most are free to call, or are paid for by the account you connect with. A newer kind charges for each call. The server answers an unpaid call with a price and payment instructions, and the client is expected to pay, usually a few cents in a stablecoin, and try again. Two protocols for this have appeared, x402 and MPP, and Cloudflare's agents toolkit lets a server make any of its tools a paid one.

Tempr doesn't pay for tools. This post is about what happens instead, because before this release that was a confusing error.

What used to happen

An agent calls a tool. The tool says "pay first". Each of Tempr's four MCP clients, in the CLI, VS Code, JetBrains and Visual Studio, turned that into some kind of failure, and none of them said what it was:

The model saw an unexplained error, so it often tried the same call again, and again.
You saw a failed tool call with no reason.
In some clients it didn't even look like an error. The payment instructions came back as if they were the tool's answer, or as an empty result.

Part of the reason is that there's no single way for a tool to refuse. We found four. The x402 MCP spec puts the payment terms in an error result. Cloudflare's toolkit puts them in the result's metadata. MPP uses a JSON-RPC error code. And a payment gateway in front of a server can answer with a plain HTTP 402, the status code the web reserved for "payment required" decades ago and barely used since. Our clients, and the MCP libraries under them, handled each of these differently.

What happens now

When a tool asks to be paid, in any of the four forms, every Tempr client does the same thing:

The agent is told plainly. The tool's result says it requires payment, at what price when the server gives one, that Tempr doesn't pay for tools so it wasn't run, and not to call it again, but to tell you if the task needs it.
You see it in the chat. The tool call shows "Paid tool, not run", with the price per call.
It's asked once. Later calls to the same tool are answered straight away, without contacting the server again, until the MCP servers restart.
Paid tools can be marked in advance. Where a server lists a tool as paid, as Cloudflare's toolkit does, the agent sees that before its first call, so it can plan around the tool instead of discovering the price by trying it.
A server that charges just to connect says so. Its startup error explains that it requires payment, instead of looking like a broken server.

The price is shown when the terms give it in USDC, a dollar stablecoin, or when a server lists a tool's price in dollars. When there are several options, the cheapest is shown. Anything else is shown as "a fee".

Why only the price gets through

A payment request carries text the seller wrote: a description of the resource, an error message, an address to pay. To the agent, that text would look like instructions from a tool it's using, and a seller could write anything there, including instructions meant for the agent. So nothing from a payment request reaches the model or your screen except the price, parsed as a number. The agent gets a message Tempr wrote, with that number in it.

All four clients, and the Gateway, are tested against the same set of refusals in every form, including one with an injection attempt in its description, and the clients must produce exactly the same messages.

Through the Gateway

MCP traffic that goes through Tempr's Gateway gets the same treatment on the server side. When a remote MCP server answers with HTTP 402, the headers that carry its terms now reach your client unchanged, and the request log records the call as mcp_payment_required, with the price when the terms give one in USDC. The Gateway doesn't pay either.

Why not just pay?

For a few cents, paying might seem easy. But an agent that can pay is an agent that can spend your money on its own judgement, many times over in one run. Paying means holding a wallet and funding it, deciding who approves which purchases, and handling the support cases that follow when an agent buys something nobody meant it to. No customer has asked us for that from their coding agent.

If that changes, the work done here still counts. A client that pays has to know a call is a purchase, must never retry one blindly, and should count it against the run's budget, the same price ceiling that limits model spend. Until then, a paid tool is a tool your agent knows it can't use, and says so.

The MCP servers page lists servers you can connect, and the MCP docs show how to set one up.

OpenAI's newest models, on the API everything else speaks

2026-10-07T00:00:00Z

OpenAI has two APIs for talking to its models. Chat completions is the older one, and nearly every tool speaks it: IDE extensions, agent frameworks, scripts, and most gateways, Tempr's included. The Responses API is newer. OpenAI builds its new features there first, and more and more of its models can do some things only there.

For a tool that speaks chat completions, that shows up as errors that are hard to explain. A model is in the model list, but every request fails. A request works until you turn reasoning up, then fails. An agent works until it tries to call a tool. We hit all three, so the Tempr Gateway now sends exactly those requests through the Responses API and translates the answer back.

Three ways a request can fail

We checked each model live, with real requests. There are three kinds of gap:

The whole model is Responses-only. OpenAI's pro and codex models, such as gpt-5-pro, o3-pro and gpt-5.3-codex, answer every chat completions request with a 404.
The deepest reasoning level is Responses-only. gpt-5.6 with its luna, sol and terra variants, and gpt-6-astra, gpt-6-luna, gpt-6-sol and gpt-6.1-sol, reject reasoning effort max on chat completions. Every other level works on both APIs.
Function tools with reasoning are Responses-only. On those same models, chat completions rejects any request with function tools unless reasoning is set to none, and that includes requests that don't set reasoning at all. gpt-6-astra has no none level, so on chat completions it can't call a function tool at all.

The third one matters most. Calling tools is what an agent does: read a file, run a command, edit code. A model that can't call tools on chat completions is no use to a coding agent that speaks chat completions.

A bridge for each request

Tempr decides which API to use for each request, not for each model. A gpt-6-sol request with tools and reasoning goes to the Responses API. The same model's plain requests stay on chat completions, where parameters like stop and seed still apply. The Responses API has no equivalent of those, so a bridged request goes without them.

On the way there, the chat request becomes a Responses request. Messages become input items in the same order. Assistant tool calls and their results become function-call items. Your reasoning setting becomes the Responses API's own. Two details took some care:

Tool schemas keep chat's behaviour. Chat completions doesn't enforce a function's schema strictly unless you ask it to, and the Responses API does by default. A loose tool schema, as many IDE tools have, would be held to stricter rules than it was written for, so Tempr keeps chat's default.
Reasoning survives a tool loop. Tempr doesn't store responses, so it asks OpenAI for the model's reasoning in encrypted form, the only way to get it back without storage. It comes back as reasoning_details on the assistant message, which Tempr's clients already return on the next request, and goes back to OpenAI from there. A model reasoning through a sequence of tool calls keeps its earlier reasoning.

On the way back, the Responses answer becomes a chat completions answer, streaming included, with text, tool calls, finish reasons and usage where chat clients expect them. Tempr doesn't ask for reasoning summaries, though: OpenAI rejects the whole request when the API key's organization hasn't been verified, and we didn't want a request to fail over an extra.

All this applies to every path into Tempr: the Gateway's /v1/chat/completions and /v1/messages, the IDE extensions, the CLI and agent runs.

Knowing which requests to send

OpenAI's model list doesn't say which API a model needs, so Tempr works it out in three ways:

By name. An OpenAI model with -pro at the end or codex in its name goes straight to Responses, which saves a rejected request.
From the error. When chat completions answers that a model or a request only works on the Responses API, Tempr sends that request there instead, and remembers.
From a list. For the models whose gaps we've checked, the reasoning levels and tool requests chat completions rejects are listed, so those requests go to Responses the first time.

The second step needed a fix. Chat completions rejects a function-tool request on these models with an error that also says to use the Responses API. The first version of the bridge read that as "this model is Responses-only" and sent all of the model's requests there, so its plain requests lost stop and seed for no reason. Tempr now remembers what it learns separately for each model and kind of request: a model that only needs Responses for tools keeps using chat completions for everything else.

New models

New OpenAI models arrive often. Tempr picks up their reasoning levels on its own, from a catalog it refreshes every 12 hours, but not which requests they reject on chat completions. Checking that is quick and doesn't cost anything. Chat completions checks the model before the parameters, so a request with a reasoning level that doesn't exist, such as "banana", is rejected without generating any tokens, and the error says whether chat completions serves the model. A level the model doesn't have, such as max, gets an error listing the levels it does have. That's how we found the same gaps on gpt-6-luna, gpt-6-sol and gpt-6.1-sol as on gpt-6-astra, and they joined the list on October 5.

You don't need to do anything to use any of this: send your chat completions request as usual. If you'd rather use the Responses API yourself, Tempr's /v1/responses passes OpenAI requests straight through. See the Responses API section of the docs, and the Codex CLI guide for a client that speaks it.

One reasoning setting for every provider, and what it took

2026-10-07T00:00:00Z

Most models worth using for code can think before they answer, and you can usually choose how much. More thinking costs more tokens and takes longer, and it often gets you a better answer on hard problems. What you can't choose is how you ask for it, because no two labs ask the same way.

OpenAI, xAI and Mistral take reasoning_effort. Claude takes adaptive thinking with an effort level (or a token budget, before Claude 4.6). Gemini takes thinkingConfig. DeepSeek, Z.AI, Moonshot, MiniMax, Xiaomi and Cohere each take a thinking field of their own, and Qwen takes enable_thinking. The levels don't line up either: one model offers low, medium and high, another adds minimal or xhigh or max, and some can only be switched on or off.

If you use one model, that's a detail. If you switch models, or send a request to whichever model fits it, the detail becomes a lot of code.

One setting in, the right format out

The Tempr Gateway takes one shape for every model: OpenRouter's reasoning object, or OpenAI's reasoning_effort if you only want to set the level.

json

{
  "model": "anthropic/claude-sonnet-4-6",
  "messages": [{ "role": "user", "content": "Plan the migration." }],
  "reasoning": { "effort": "high" }
}

Tempr sends that on in the format the model's provider reads. The same goes for /v1/messages (Claude's thinking and output_config.effort) and /v1/responses (reasoning.effort), so a tool built for one of those APIs can run on any model. We made four decisions along the way:

Ask for nothing, get the model's default. Leave reasoning out and each model thinks as much as its lab intends. Tempr doesn't switch thinking off behind your back to save tokens.
A level the model doesn't have becomes the nearest one it does, rounding up on a tie. Asking for xhigh on a model that stops at high gets you high, not an error.
The response says what was applied. The x-tempr-reasoning-effort header gives the level that was sent, so you can see when your request was adjusted.
none on a model that can't stop thinking gets its lowest level. Claude Opus 5 gets low as well, because Anthropic recommends a low effort over switching its thinking off.

In the IDE extensions this is a reasoning picker next to the model picker, showing only the levels the selected model has, and your choice is remembered per model. In the CLI it's /reasoning, also saved per model, or --reasoning for a single run.

The same model, on three hosts

Labs were the easy part. Open-weight models are served by many inference hosts, and each host decides for itself which reasoning fields it reads. We tested each host with real keys in September 2026, and the documentation didn't always match what the APIs did. The clearest case was GLM-5.3, one model on three hosts:

On DeepInfra, the levels worked as expected. Thinking couldn't be switched off, and trying to made the model's reasoning show up in its visible answer.
On Together AI, the levels behaved the opposite way: low and high produced no thinking, while max and none did. A picker there would switch thinking off for anyone who chose "high".
On Fireworks AI, the levels formed a proper ladder, and none was rejected with a clear error.

So Tempr reads reasoning levels from each host's own catalog entry, not from the model's lab, and the same model can offer different levels, or none, depending on where it runs. GLM on Together AI offers no levels at all, because the host can't steer it reliably. Hugging Face offers none either: it's a router that picks a host for each request, and of the 20 reasoning models we checked there, none had only one host behind it.

The hosts differ in other ways too. Fireworks rejects any field it doesn't recognise, including the reasoning object, so Tempr sends it only reasoning_effort. AWS Bedrock's OpenAI-compatible endpoint ignores the object and reads only reasoning_effort, while Claude and Amazon Nova on Bedrock's Converse API each take their own fields and reject each other's.

Testing it without paying for it

Checking every model on every host would be expensive if every check generated tokens. Most don't need to. A host checks your parameters only after it has accepted the model, and a rejected request costs nothing. Send a deliberately invalid level, such as "reasoning_effort": "banana", and the error says whether your key can reach the model and, often, which levels it accepts. Our whole Together AI investigation cost less than a tenth of a cent.

Keeping it right

Model catalogs change. Tempr takes reasoning levels from models.dev's open catalog, refreshed every 12 hours, and corrects it where a provider's API behaves differently. That correction has already mattered. On October 1 the catalog started listing Kimi K3 as a model that always reasons, and for a few days none ran it at its lowest level. Moonshot's API still switches it off, so Tempr does again, and behaviour we've checked live now overrides the catalog.

The full reference, including every field and how each provider maps it, is in the Reasoning section of the docs. Each model's levels are in GET /v1/models under reasoning_options, and in the model catalog.

Putting a price ceiling on an agent run

2026-10-07T00:00:00Z

A chat reply is one model call, and you can roughly guess what it costs. An agent run isn't. You give it a task, and it reads files, runs commands, calls the model again with what it found, maybe hands part of the work to a sub-agent, and keeps going until it's done. One prompt can turn into a few calls or a few dozen, each carrying a longer conversation than the one before.

Monthly budgets are a good backstop, but they catch a runaway run only after it has spent the money. What you want is a limit for each run: stop this task once it has cost this much.

A limit for one run

In the CLI, it's a flag:

bash

tempr --max-cost 0.50 "migrate the payment tests to the new fixtures"

The run keeps a total of what its model calls have cost, sub-agents included, from the cost each call reports. Once the total reaches the limit, the run stops before its next model call, the same way Ctrl+C stops a turn. The CLI exits with code 6 and status cost-limit, so a script or CI job can tell this apart from an error. With --json, the final result line also carries spentUsd.

The IDE extensions have the same limit as a setting: "Stop an agent turn after (US dollars)" in VS Code, JetBrains and Visual Studio. It's blank by default.

Enforced on the server too

A limit that only the client checks has gaps. The client doesn't see every call billed as it happens, and a run that's stopped on your machine can still have work going on the server. So Tempr's server enforces the limit as well. Each run is sent what is left of its limit, and the server stops the run before any model call that would start once the limit is reached.

Two things to know about the edges:

The limit is checked between calls, so a run can finish a little above it, by the cost of the call that was already running when it crossed the line. Set the limit with that call in mind.
A model with no known price can't be counted. Tempr prices a call from what the provider reports or from the model's listed price. When it has neither, as with a custom model you haven't priced, the call counts as $0, and the CLI warns you rather than pretending the limit still holds.

A limit for your whole organization

On a team, the person setting the limit often isn't the one running the agent. An organization's owners and admins can set the most one agent run may cost on the Portal's Budget page, and it applies to every member, in the CLI and in the IDE extensions. Members can set a lower limit for themselves, but not a higher one, and --max-cost can only lower it. Changes to the limit appear in the organization's audit log.

When a run hits the organization's limit, only that turn stops. The session carries on, and the next run starts with a fresh limit, so a developer can look at what happened and decide whether to continue.

Seeing where the money went

A limit stops a run. It doesn't tell you which runs are worth a closer look. The Portal's Usage page now lists this month's most expensive agent runs, with when each started, who ran it, which model it used, how many model calls it made and what it cost, sub-agents included. On a team, the same list appears on the Budget page for owners and admins. Each run links to its trace, so you can see which step took the most.

One more budget tool shipped alongside this. Monthly budgets on virtual keys, on members and on an organization's hard cap now have a Strict option. Without it, several requests running at the same moment can each see room left in a budget and, together, go past it. With it, they can't. Strict mode adds about 5 milliseconds per request, and up to about 30 when many requests share a budget at once, so it's off unless you turn it on.

The details are in the docs: capping what a run spends in the CLI guide, and the CLI reference for every flag.