digline-bedrock
An Amazon Bedrock target and judges for
digline, on the Converse API: a prompt file
goes in, a priced Response comes out.
pip install digline-bedrock
Requires Python 3.12+, like digline itself.
Quickstart
No credential argument exists: the AWS chain — environment, profile, IAM role, instance metadata — is boto3's job, and this package never reads it.
from digline_bedrock import BedrockTarget
target = BedrockTarget(
"prompts/answer.md",
model="eu.anthropic.claude-sonnet-4-20250514-v1:0",
max_tokens=1024,
)
model takes a model id or an inference profile id. The region is resolved
when the target is built — from region= if you pass one, otherwise from the
client the chain produced — and the price list follows from it:
from digline_bedrock import BedrockTarget
target = BedrockTarget(
"prompts/answer.md",
model="us.anthropic.claude-haiku-4-5-20251001-v1:0",
max_tokens=1024,
region="us-east-1",
)
target.region is read-only, and that is the point: what was priced is what was
called. A missing region fails there, when the target is built, not on case
thirty-seven with thirty-six paid calls behind it.
The judges run in the same account
A plugin is a target and a judge (ADR 0004), which on Bedrock is usually the whole reason the model is there: what a judge is sent is the model's output, and it stays inside the same account, the same region and the same IAM role.
from digline.core import LlmRubric
from digline_bedrock import BedrockJudge
judge = BedrockJudge(model="eu.anthropic.claude-haiku-4-5-20251001-v1:0")
rubric = LlmRubric(
rubric="The answer is one sentence and cites the passage it came from.",
judge=judge,
threshold=0.8,
tolerance=0.05,
)
from digline.core import Faithfulness
from digline_bedrock import BedrockClaimJudge
faithful = Faithfulness(
judge=BedrockClaimJudge(model="eu.anthropic.claude-haiku-4-5-20251001-v1:0"),
threshold=0.9,
tolerance=0.05,
)
Converse has no structured-output mode, so the reply shape is asked for in the system prompt and read back leniently — a fenced block or a sentence in front of the object both parse. What judging cost is counted on the judge and never reset:
from digline_bedrock import BedrockJudge
judge = BedrockJudge(model="eu.anthropic.claude-haiku-4-5-20251001-v1:0")
print(f"{judge.calls} judgements, {judge.spent_usd:.4f} USD, {judge.latency_ms:.0f} ms")
Prices, and what is not priced
bedrock_pricing(region) is seeded for us-east-1, us-west-2, eu-west-1,
eu-central-1 and eu-west-3, with the Anthropic models. Bedrock prices by model
and by region, and a figure invented for a region nobody checked would be
wrong in the direction nobody notices — so everything else raises at preflight
and is served with one argument:
from digline.targets import ModelPrice
from digline_bedrock import BedrockTarget, bedrock_pricing
target = BedrockTarget(
"prompts/answer.md",
model="amazon.nova-pro-v1:0",
max_tokens=1024,
region="us-east-1",
pricing=bedrock_pricing("us-east-1").override(
"amazon.nova-pro-v1:0", ModelPrice(input_per_mtok=0.80, output_per_mtok=3.20)
),
)
An application inference profile is an ARN and is opaque: it is never in the
list, fails preflight, and is served the same way. That is intended, not a
gap — a run that cannot say what it cost must not run.
A model you brought in through Custom Model Import, or one behind Provisioned Throughput, has no per-token bill at all: it is billed by model-copy-hour and model-unit-hour. Say so out loud rather than leaving it unpriced:
from digline_bedrock import BedrockTarget, free
target = BedrockTarget(
"prompts/answer.md",
model="my-imported-model",
max_tokens=1024,
region="eu-west-1",
pricing=free("my-imported-model"),
)
The details that bite
Your account never leaves the machine. A botocore failure names the assumed
role — arn:aws:sts::<account>:assumed-role/… — and digline quotes a target's
exception into the reason of every verdict of that case, which lands in a
committed run file. So every AWS error is re-raised as BedrockCallFailed with
ARNs and account ids removed; the original stays on __cause__, in memory, for
a debugger.
Cached tokens. Converse counts cached reads beside inputTokens, not
inside them — measured against the API on 2026-08-28, not inferred from the
field names: a warm call reported inputTokens=10, cacheReadInputTokens=12002
and totalTokens=12016. So they are added rather than subtracted, which is the
opposite of OpenAI's convention. It is one constant in digline_bedrock.client,
re-measured by a live test, because getting it wrong is invisible in the
direction of good news.
additional_request_fields reaches Converse's
additionalModelRequestFields and changes what the model does. It is not
part of config_hash — no more than temperature, model or max_tokens are:
the fingerprint covers the rules that judge a run, not the system being judged.
Two runs differing only in these fields will read as "same configuration as the
reference". If you need the difference to show, keep the fields in a file and
declare it in Suite.artifacts, and the report carries the diff.
Apache-2.0. Docs: digline/digline.
Metadata
Release files for digline-bedrock 0.4.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 | Provenance | Actions |
|---|---|---|---|---|
| digline_bedrock-0.4.0.tar.gz | 27.5 kB | With provenance | Details for digline_bedrock-0.4.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| digline_bedrock-0.4.0-py3-none-any.whl | Python 3 | none | any | Details for digline_bedrock-0.4.0-py3-none-any.whl |
Total release size: 45.5 kB
Release files / digline_bedrock-0.4.0.tar.gz
| Download URL | digline_bedrock-0.4.0.tar.gz |
|---|---|
| Size | 27.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
02f5ee27d7bc4a3c5d5d289ca72db8cd6948ee4e80e31997a4a43e4a5ec333f0
|
|
BLAKE2b-256 checksum How to use checksums |
4df3bc64a444d2581159131a638b2f1200eeaec29f5daaf5cc8193bd1c159dcf
|
| 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 Sep 10, 2026.
Transparency logRelease files / digline_bedrock-0.4.0-py3-none-any.whl
| Download URL | digline_bedrock-0.4.0-py3-none-any.whl |
|---|---|
| Size | 18.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
1e1cc7ec51d1e0620bd0ee60af3ec724d695bcafca044c3e545d17bc9b89885b
|
|
BLAKE2b-256 checksum How to use checksums |
6198f2ba3ec1218d36ffe1dff24b8bb8d102310ad500558b118f3cab21bcb4e3
|
| 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 Sep 10, 2026.
Transparency logSecurity for digline-bedrock 0.4.0
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.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for digline_bedrock-0.4.0.tar.gz
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 Sep 10, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.