Budgets, rate limits, logs and observability

Every Tensic project has the same controls, whatever its type: a monthly cost budget, a requests-per-minute rate limit, and detailed logs with token usage and cost per request. Platform admins also get an instance-wide Observability section and can export telemetry to their own tools.

Set a monthly budget for a project

Each project has a Budget & Limits tab. A project's usage always counts against its team, and by default a project inherits the budget of the level above it.

1. Open the project and go to the Budget & Limits tab.
2. Under Limits, open Monthly cost budget (€/mo) and choose:
   • Inherit (…from the level above): the project uses the budget set above it. The option shows the inherited amount, for example "Inherit (€100 / mo from the instance default)".
   • Set an amount: give the project its own monthly cap, for example 100 (€).
   • No limit — ignore the level above: the project has no cap of its own. A budget set at a higher level still applies to it.
3. Click Save.

When a project reaches its cap, Tensic refuses further requests for that month. Without a cap, the Spend panel says Uncapped — nothing limits this, and requests are never refused because of cost.

The project's Overview tab also shows a Budget card with a Set cap shortcut.

To get notified before or when a budget runs out, use the budget warning and budget exceeded webhooks in the project's integrations.

Set a per-minute rate limit for a project

The rate limit caps how many requests a project accepts per minute. Use it to protect your budget from runaway loops or misbehaving clients.

1. Open the project and go to the Budget & Limits tab.
2. In Rate limit (requests/min), enter the maximum number of requests per minute. Leave it empty for no limit.
3. Click Save.

The limit counts every call on the project. Chat, embeddings, image and transcription requests all share the same limit.

Track a project's spend

The Spend panel at the bottom of the Budget & Limits tab shows:

• Spent: a progress bar showing spend against the cap, for example €0.80 / €100.00 (1%). It also notes whether the cap is inherited.
• Month to date: spend in the current month.
• All-time cost: total spend since the project was created.

The project header also shows all-time Tokens, Requests and Cost, plus the number of API keys and the time of the last call. The Overview tab shows traffic over time and recent activity, with a link to the full logs.

Read a project's logs: messages, tool calls, tokens and cost

Every project has a Logs view (the Logs button at the top of the project). Use it to debug your app, check what the model received and returned, and understand exactly what each request cost.

1. Open the project and click Logs.
2. The Health strip at the top summarises the selected window (for example 14 days): runs, error rate, guard blocks, P50 and P95 latency, cost, and small charts of runs, latency and cost per day.
3. Switch between Turns (one line per turn) and Conversations. Filter by search text, status, error msg or date range (Today, 7d, 14d, 30d or custom dates).
4. Select a turn to open Turn detail:
   • Answer: what the model returned.
   • Tool trace: each tool the model called, with its arguments, result and duration.
   • Token counts: billed input and output tokens, including how many input tokens were cached.
   • Cost: how the cost was calculated, for example 2,373 × €1.40 / 1M tokens for input plus the output line and the total. Cached tokens are billed at the model's cached-token price.
   • Model calls, Request trace and Raw JSON for deeper debugging.
5. Use Conversation details to see the whole conversation, or Replay conversation to run it again.

For inference projects, logs are listed per model call. Expand a call to see the request (system and user messages), the last user message and the response. This makes an inference project useful for seeing how an existing app or coding agent talks to its model.

Control logging, redaction and log retention for a project

Logging is on by default for every project. Configure it on the project's Logging tab, under Log hygiene.

1. Open the project and go to the Logging tab.
2. Inference logging: records every request and response for analytics and debugging. Turn it off to stop new logs for this project, for example when it handles data you must not store.
3. Redact in logs: strips API keys, tokens and credentials from the question, answer and system prompt before anything is stored. It only works while inference logging is on. Redaction catches a lot, but it isn't 100% reliable. Don't depend on it as your only protection for highly sensitive data.
4. Log retention (days): how long this project's inference logs, guard events and retrieval telemetry are kept. Leave it empty to follow the instance's retention window. If both are set, the shorter one wins.
5. Click Save.

Below the form, Instance log retention shows how long the whole instance keeps inference logs before cleanup deletes them. Platform admins set this platform-wide in Settings, not per project.

On high-traffic projects logs grow quickly, so choose a retention period that fits your needs.

Monitor the instance in Observability (platform admins)

Platform admins have an Observability section in the main menu, covering the whole instance. It has these tabs: Health, Logs, Spend, Audit Log, Cron Logs, Routines and Exporter.

Cron Logs shows every run of the platform's background jobs. These are Tensic system jobs, not operating-system cron jobs. Examples include budget alerts, routines, memory bank indexing, re-embedding and ingestion. Each run shows:

• the job name and status (success or error),
• a message (for example "budget warnings emitted: 0"),
• items processed, duration and date.

You can filter by job, status or date, and click Run Now to trigger a run immediately. Use this to check that background work, such as agent memory indexing or scheduled routines, is actually running.

Routines lists every routine configured on the instance. Admins can enable or disable any of them from here, which gives one central place to stop a routine that is misused or running too often.

Everything that passes through the platform, including router decisions and SQL queries issued by agents, is visible in logs and observability.

Export telemetry with OpenTelemetry or LangSmith

To analyse Tensic traffic in your own observability stack, send traces and metrics (tokens, cost, latency, tool calls) over OpenTelemetry (OTLP).

1. Go to Observability and open the Exporter tab.
2. Under OpenTelemetry export, choose a Vendor:
   • Generic OTLP: works with any OpenTelemetry collector.
   • LangSmith: switches to LangSmith's trace format, using dedicated fields. Traces only, over HTTP/protobuf.
3. Enter the OTLP endpoint, for example http://otel-collector:4317. Leave it empty to turn export off.
4. Choose the Protocol: gRPC (usually port 4317) or HTTP/protobuf (usually port 4318). Some vendors only accept HTTP/protobuf.
5. Add any Headers your vendor needs, as k=v,k2=v2, for example an API key. Headers are encrypted at rest and shown masked. Leave the mask unchanged to keep the saved value.
6. Optionally change the Service name (default tensic). It is reported as service.name on every span and metric.
7. Optionally turn on Export prompts and completions. Prompts, completions and tool arguments then leave the instance for your collector. Projects with logging turned off stay excluded, and redaction rules still apply.
8. Save, then use Send a test span to check that the collector accepts data.

Changes are picked up by every worker within about 15 seconds of saving. While no endpoint is set, the tab shows Export is off and no telemetry leaves the instance.

Common questions