Quickstart¶
This guide walks through the Python API: turning a raw text sample into a TextFSM template, then compiling that template into its AST, canonical TextFSM, readable DSL, and recognizer patterns.
Prerequisites¶
You need an API key for at least one supported provider, set as an environment variable:
| Provider | provider value |
Environment variable |
|---|---|---|
| OpenAI | "openai" |
OPENAI_API_KEY |
| Anthropic | "anthropic" |
ANTHROPIC_API_KEY |
| Gemini | "gemini" |
GEMINI_API_KEY |
| DeepSeek | "deepseek" |
DEEPSEEK_API_KEY |
| Groq | "groq" |
GROQ_API_KEY |
| xAI (Grok) | "xai" |
XAI_API_KEY |
| Together AI | "together" |
TOGETHER_API_KEY |
| Fireworks AI | "fireworks" |
FIREWORKS_API_KEY |
| Cerebras | "cerebras" |
CEREBRAS_API_KEY |
| Perplexity | "perplexity" |
PERPLEXITY_API_KEY |
| OpenRouter | "openrouter" |
OPENROUTER_API_KEY |
| Moonshot AI (Kimi) | "moonshot" |
MOONSHOT_API_KEY |
| Mistral AI | "mistral" |
MISTRAL_API_KEY |
| Amazon Bedrock | "bedrock" |
BEDROCK_REGION (or BEDROCK_DEFAULT_REGION) + AWS credential chain |
| Cohere | "cohere" |
COHERE_API_KEY |
| Google Vertex AI | "vertexai" |
VERTEXAI_PROJECT + VERTEXAI_REGION + GCP ADC credential chain |
| Oracle OCI | "oci" |
OCI_COMPARTMENT_ID + ~/.oci/config credential file (OCI_REGION optional) |
| Azure OpenAI | "azure" |
AZURE_API_KEY, AZURE_ENDPOINT, AZURE_API_VERSION |
pip install textfsm-ai
export OPENAI_API_KEY=sk-...
1. Ask an LLM to generate a template¶
import os
import textfsm_ai
sample = """\
interface GigabitEthernet0/1
description Uplink to core switch
interface GigabitEthernet0/2
description Downlink to access switch
"""
result = textfsm_ai.generate(
sample,
provider="openai",
api_key=os.environ["OPENAI_API_KEY"],
model="gpt-4o-mini",
)
if result.ready:
print(result.template) # the generated TextFSM template
print(result.records) # parsed records the LLM extracted
print(result.variables) # {"iface": "explanation of this variable", ...}
print(result.handling) # notes on how ambiguous lines were handled
else:
print("Generation failed:", result.reason)
generate() never raises for an ordinary LLM/generation failure (rate
limits, retry exhaustion, an unparsable response) — check result.ready
and read result.reason instead of wrapping the call in try/except.
If you only need one piece of the result, use the matching shortcut instead of pulling the whole object apart yourself:
template = textfsm_ai.to_llm_template(sample, provider="openai", api_key=..., model="gpt-4o-mini")
records = textfsm_ai.to_llm_records(sample, provider="openai", api_key=..., model="gpt-4o-mini")
Note: to_llm_template() returns the failure reason (a string) instead of
an empty string if generation didn't succeed — it's a shortcut for the
.template field, not a separate cheaper call, so check to_llm_result()
first if you need to tell "failed" apart from "genuinely returned this
string."
2. Compile a template into its AST, canonical form, and recognizers¶
Once you have a template (from generate(), or one you wrote by hand),
compile it to get the parsed AST, the canonical (regex-expanded) TextFSM
template, a human-readable DSL form, and recognizer patterns:
dsl = textfsm_ai.compile_dsl(result.template, result.records)
if dsl.ready:
print(dsl.canonical) # canonical TextFSM template
print(dsl.readable) # human-readable DSL
print(dsl.recognizers) # regex patterns that detect this block of text
print(dsl.ast) # the parsed TemplateAST
else:
print("Compile failed:", dsl.reason)
Same shortcut pattern applies here: to_canonical(), to_readable(),
to_recognizers(), and to_ast() each take the same (template, records)
parameters as compile_dsl().
3. Or run the whole pipeline in one call¶
run_pipeline() does both steps above end-to-end and packages the result
for you, in one of four verbosity modes:
output = textfsm_ai.run_pipeline(
sample,
provider="openai",
api_key=os.environ["OPENAI_API_KEY"],
model="gpt-4o-mini",
mode="debug", # "quiet" | "default" | "info" | "debug"
)
print(output.output) # formatted text for the chosen mode
print(output.passed) # True/False
Using an Azure deployment¶
Azure uses a deployment name in place of model, plus endpoint and
api_version:
result = textfsm_ai.generate(
sample,
provider="azure",
api_key=os.environ["AZURE_API_KEY"],
model=os.environ["AZURE_DEPLOYMENT"], # deployment name
endpoint=os.environ["AZURE_ENDPOINT"],
api_version=os.environ["AZURE_API_VERSION"],
)
Using Amazon Bedrock¶
Bedrock takes no api_key at all — pass region instead, and AWS
credentials are resolved automatically via boto3's own credential chain
(AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN,
~/.aws/credentials, or an IAM role):
result = textfsm_ai.generate(
sample,
provider="bedrock",
api_key="",
model="anthropic.claude-haiku-4-5-v1:0",
region=os.environ["BEDROCK_REGION"],
)
run_pipeline() accepts the same region keyword.
Using Google Vertex AI¶
Vertex AI also takes no api_key — pass project and region (GCP
"location") instead, and credentials are resolved automatically via
Google Cloud's Application Default Credentials (a service account key
file via GOOGLE_APPLICATION_CREDENTIALS, gcloud auth
application-default login, or workload identity):
result = textfsm_ai.generate(
sample,
provider="vertexai",
api_key="",
model="gemini-2.5-flash",
project=os.environ["VERTEXAI_PROJECT"],
region=os.environ["VERTEXAI_REGION"],
)
run_pipeline() accepts the same project/region keywords. Vertex AI
serves the same Gemini models as the native "gemini" provider under
identical model IDs, so it must always be selected explicitly via
provider="vertexai" — there's no automatic way to tell "call this model
via Vertex" apart from "call it via the Gemini Developer API" from the
model name alone.
Using Oracle OCI¶
OCI also takes no api_key — pass compartment_id instead (an OCID
identifying which OCI compartment to bill and scope the request to), and
credentials are resolved automatically from ~/.oci/config (the DEFAULT
profile, same file the OCI CLI itself uses). region is optional here:
if omitted, whatever region is already set in ~/.oci/config is used.
result = textfsm_ai.generate(
sample,
provider="oci",
api_key="",
model="meta.llama-3.3-70b-instruct",
compartment_id=os.environ["OCI_COMPARTMENT_ID"],
region=os.environ.get("OCI_REGION"),
)
run_pipeline() accepts the same compartment_id/region keywords. OCI's
"vendor.model-name" model IDs (meta.llama-3.3-70b-instruct,
xai.grok-4-fast-reasoning) share vendor prefixes with Amazon Bedrock's
own re-hosted namespace, so OCI must always be selected explicitly via
provider="oci". Only Meta Llama and xAI Grok models are supported —
Cohere models on OCI use a different, incompatible request/response shape
and are reachable through this package's native "cohere" or "bedrock"
providers instead.
Next steps¶
- See Providers for the full list of supported providers, their credentials, and any provider-specific quirks.
- See the API Reference for every function and result type.
- See the CLI Guide for the equivalent
textfsm-aicommand-line workflow.