Sinas 0.4.0 adds pipelines (multi-step flows that connect APIs, functions, agents and databases), a batch execution mode that runs bulk agent work at roughly half the model cost, and per-agent control over provider behaviour like prompt caching. This post explains what each one is for, how they fit together, and the trade-offs worth knowing before you switch anything on.
Why agents need pipelines
A pipeline is a multi-step flow you declare once, attach a trigger to, and let Sinas run, record and replay.
Most useful agent work runs as a flow rather than a conversation: pull records from an API, reshape them, have an agent enrich or classify each one, write the results somewhere a human or another system can use them.
Before 0.4.0 you could build that in Sinas, but you built it as glue: a scheduled function calling an agent calling another function, with the flow logic living in code only its author understood. Pipelines make the flow itself a first-class object. You declare the steps (connector call, transform, function, agent, query, database load), pick a trigger (a schedule, a webhook, a database change, or another agent using the pipeline as a tool), and Sinas runs it, records every run, and lets you replay one when a step needs a second chance.
The console gets a visual steps editor for building and reading these flows. The value there is maintenance: the person who picks up the flow six months from now can see what it does without reading the source.
How batch mode halves the bill for bulk agent work
For agent workloads that do not need an answer in seconds, 0.4.0 can submit the whole batch to the LLM provider’s own batch API, where Anthropic and OpenAI both price tokens at roughly 50% of the interactive rate. Classify ten thousand documents, extract entities from a month of tickets, summarise a case archive: same transcripts, same usage tracking, same callbacks, half the token cost, and results within a day rather than within seconds.
You opt in per submission:
POST /agents/legal/case-summariser/chats/batch
{
"execution_mode": "provider",
"inputs": [ ... ]
}
| Dimension | Queue mode (default) | Provider batch mode |
| Latency | seconds to minutes | minutes to 24 hours |
| Token cost | standard rate | ~50% of standard rate |
| Agent capabilities | full, including tools | agents without tools |
| Transcripts and usage tracking | yes | yes |
| Best for | interactive and time-sensitive work | classification, extraction, summarisation at volume |
The limitation is real and structural: a provider batch is one model call per item, so there is no runtime to serve tool calls mid-flight. Tool-using agents stay on the queue path.
Why prompt caching is now a per-agent setting
Prompt caching saves money when an agent reuses a large system prompt across many calls, and can cost money when it does not, because cache writes carry a premium. Whether it pays off is a property of the agent, not of the provider.
Until now the setting lived on the provider, so tuning it per workload meant registering the same provider twice with a copied API key. 0.4.0 adds provider overrides on the agent itself: inherit the provider default, or force caching on or off for that one agent, from the agent editor. Only behaviour settings can be overridden this way. Connection settings such as keys and endpoints stay on the provider, deliberately.
Why Gemini became a proper provider type
Gemini is a first-class provider type in 0.4.0 because batch execution needs Google’s native file APIs.
Gemini already worked in Sinas through its OpenAI-compatible endpoint, and for chat that was enough. Batch mode is what changed the calculus: Google’s batch flow requires uploading input files through the Gemini API itself, which the compatibility layer does not expose. So 0.4.0 gives Gemini a provider type of its own, using the native file APIs where needed and fixing multi-step tool calling along the way. If you had a Gemini provider configured, switching its type over gets you batch support and better tool reliability.
How your own services can verify Sinas tokens
If you run services next to Sinas, they can now verify Sinas access tokens without calling Sinas. Switch token signing to RS256 and Sinas publishes its keys in standard JWKS form, adds standard issuer and audience claims, and serves an OIDC-style userinfo endpoint that exposes a user’s roles and custom fields as plain claims. Any JWT middleware in any language can then authenticate Sinas users offline. The default signing mode is unchanged; this is opt-in.
What else is in 0.4.0
Light mode for the console, toggleable from the login screen and remembered per browser. Connector OAuth now handles providers that bend the rules, like Slack nesting its user tokens or reporting errors on successful HTTP responses, as configuration rather than workarounds. And bulk ingestion got sturdier: if thousands of uploads each trigger a post-processing function, the work now queues and drains at the available capacity instead of failing when the pool is momentarily full.
Worth knowing
Batch mode trades latency for cost, and the ceiling is the provider’s: up to 24 hours, usually much less, but not guaranteed. Turning caching off for an agent that reuses big prompts will raise its cost; the override cuts both ways. Switching token signing to RS256 invalidates in-flight access tokens once, which users experience as one transparent refresh. And existing deployments keep working as-is: everything above is opt-in, and the release notes list the few defaults that changed.
Key takeaways
- Sinas 0.4.0 pipelines turn multi-step agent workflows into declared, triggerable, replayable objects instead of glue code.
- Provider batch mode runs tool-less agent workloads at roughly half the model cost by using the providers’ native batch APIs.
- Prompt caching is now tunable per agent, because whether caching saves money depends on the workload, not the provider.
- Gemini is a first-class provider type because batch execution requires Google’s native file APIs, which the OpenAI-compatible layer does not expose.
- With RS256 signing enabled, any external service can verify Sinas tokens offline using standard JWKS, with no SDK or shared secret.
Documentation: docs.sinas.co · Source: github.com/sinas-platform/sinas
