caesura-io-core
Framework-agnostic core for CaesuraO — shared analyze, inject, and credit-metering logic used by all SDK integrations.
This package is not meant to be used directly. It is the shared engine consumed by:
caesura-io-openai— OpenAI Python SDK wrapper
What's inside
| Module | Purpose |
|---|---|
CaesuraClient / AsyncCaesuraClient |
HTTP clients for analysis and conversation creation |
MemoryCaesuraStore |
In-memory conversation state with LRU + idle-time eviction |
CaesuraEngine / AsyncCaesuraEngine |
Orchestrator: cadence checks, observe/analyze cycle, buffering, event emission |
create_credit_meter |
Accumulates and queries credit-usage metrics |
create_debug_logger |
Structured on_event logger for debugging |
| Helpers | hash_message, select_active, render_analysis, render_block, build_analyze_messages |
| Types | CaesuraConfig, CaesuraEvent, InjectConfig, SendConfig, etc. |
Install
pip install caesura-io-core
Usage
Most consumers should use the framework-specific wrappers. If you're building your own integration:
import time
from caesura_core import AnalyzeMessage, CaesuraConfig, create_caesura_engine, select_active, render_block
engine = create_caesura_engine(
CaesuraConfig(
mode="sync", # Wait for analysis before retrieving recommendations below
# api_key auto-read from CAESURA_API_KEY if omitted
)
)
# Create once; save this ID and reuse it for subsequent turns.
conversation_id = engine.create_conversation(name="Meeting preparation")
# 1. Observe a conversation turn
engine.observe(
conversation_id,
[
AnalyzeMessage(
speaker_role="user",
speaker_name="Customer",
text="I need help preparing for the next meeting",
),
],
)
# 2. Retrieve buffered recommendations
state = engine.store.get(conversation_id)
active = select_active(state, engine.config.inject, time.time() * 1000)
blocks = render_block(active, engine.config.inject)
# → blocks contains rendered recommendation text ready for injection
Set CAESURA_API_KEY or pass api_key in CaesuraConfig.
Analyses are saved by default (persist=True), using an existing backend
conversation ID. Both HTTP clients and engines expose create_conversation();
async variants use await. It returns the ID as a string and accepts optional
name, calendar_id, and event_id keyword arguments. Creation errors propagate
to the caller.
Alternatively, set CaesuraConfig(auto_create_conversation=True) and pass a local
session label to observe(). The engine creates a conversation before the first
analysis and reuses its ID while the session remains in the store. Clearing,
eviction, or a process restart loses this mapping with the default in-memory
store; use explicit creation and save the ID for longer-lived conversations.
Automatic creation errors go through on_error and skip that analysis.
Use CaesuraConfig(persist=False) to disable saving and automatic creation.
The default mode="async" runs analysis in the background;
use mode="sync" as above when you need the result before continuing.
Analysis responses are returned as JSON values or plain text, with no fixed field
schema. result.analysis contains the response data; credit usage is available
separately as result.credit_usage. Injection templates can use {analysis} for
the full response or {analysis.field} to select a field from an object.
When calling the engine, use source role "user" for the customer and
"assistant" for the agent. Both become the backend's speakerRole="user",
with distinct names and indices (customer 1, agent 0). Explicit
AnalyzeMessage.speaker_index values, including 0, take precedence.
The configured speaker_names.agent is sent as currentUser on every request.
On the backend, speakerRole="assistant" and index -1 are reserved for
previous CaesuraO analyses. Plain-text analyses remain unquoted. The current
utterance is always the final message, which the backend saves as the transcript
entry. Occurrence anchors use cumulative FNV-1a/64 over normalized participant
identity and text, matching the JS SDK's UTF-16 reference vectors. These anchors
are internal store metadata, not backend fields. Older unmatched SHA anchors use
the latest-context fallback.
Migration
See the breaking-release migration guide.
License
Apache-2.0
Metadata
Release files for caesura-io-core 2.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| caesura_io_core-2.0.0.tar.gz | 37.7 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| caesura_io_core-2.0.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 63.6 kB
Release files / caesura_io_core-2.0.0.tar.gz
| Download URL | caesura_io_core-2.0.0.tar.gz |
|---|---|
| Size | 37.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
d4f335f71679fd6c75508fc2ec9e5b69791f793349c6a3329aa383de1db79b9f
|
|
BLAKE2b-256 checksum How to use checksums |
ab9f86a09c2272a04c41dc9e15dde93c4a40769bf94b26bdc0853e906a34728d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.
Transparency logRelease files / caesura_io_core-2.0.0-py3-none-any.whl
| Download URL | caesura_io_core-2.0.0-py3-none-any.whl |
|---|---|
| Size | 26.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
6ca0c45ce033bc8a7cbcb69da09d519122d6e303f2f8fb11d70842ff73e31d55
|
|
BLAKE2b-256 checksum How to use checksums |
5c444621ac1fa1e029ac97c0f8f0d0f1b869b8c75c24e471912423638df58944
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.
Transparency log