RunLLM

Phoenix does not apply retroactive pricing to past traces when you update or add model pricing; only new traces after the pricing change will have costs calculated using the new configuration. This is by design—costs are calculated and indexed at ingestion, so historical traces retain the pricing that was in effect at the time they were ingested, regardless of any later changes to the model pricing table. There is no built-in feature or documented method to retroactively recalculate costs for existing traces after updating model pricing, as confirmed in community discussions and the official cost tracking documentation [<https://arize.com/docs/phoenix/tracing/how-to-tracing/cost-tracking|cost tracking docs>, <https://github.com/Arize-ai/phoenix/issues/8080|community discussion>]. If you need retroactive cost calculation, you would have to manually reprocess or re-ingest the traces with the updated pricing, as Phoenix does not currently support automatic retroactive cost updates. Would you like more detail on possible workarounds or how to reprocess traces? Sources: - <https://arize.com/docs/phoenix/tracing/how-to-tracing/cost-tracking|Cost Tracking - Phoenix Documentation> - <https://github.com/Arize-ai/phoenix/issues/8080|Community discussion on retroactive pricing>

You are correct: Phoenix supports attaching properties like session ID, user ID, tags, and metadata to spans using context managers or helpers (e.g., `using_session`, `using_user`, `using_metadata`, `using_tags`) as described in the <https://arize.com/docs/phoenix/sdk-api-reference/python/arize-phoenix-otel#manual-instrumentation-helpers|manual instrumentation helpers documentation>. Filtering by session ID is already optimized, but filtering by user ID, tags, and metadata may not be as performant, especially for large datasets, since these are often stored as generic attributes or JSON fields rather than indexed columns, leading to slower queries in the UI or backend. Recent Phoenix releases have improved attribute-based filtering, allowing you to filter spans by attribute values (including user ID, tags, and metadata) using the Python, TypeScript, REST, and CLI interfaces, with type-aware matching and AND semantics (<https://arize.com/docs/phoenix/release-notes/04-2026/04-20-2026-span-attribute-filter-cli-notes-and-opus-4-7|span attribute filtering docs>). However, the underlying database performance for these filters depends on how the attributes are stored and indexed. Session ID is typically indexed for performance, but user ID, tags, and metadata may not be, which can result in slower queries as you observed. Would you like more detail on how to optimize filtering or on the current implementation of attribute storage and querying in Phoenix? Sources: - <https://arize.com/docs/phoenix/release-notes/04-2026/04-20-2026-span-attribute-filter-cli-notes-and-opus-4-7|Span Attribute Filtering, CLI Notes, and Claude Opus 4.7> - <https://arize.com/docs/phoenix/sdk-api-reference/python/arize-phoenix-otel#manual-instrumentation-helpers|manual instrumentation helpers documentation>

Yes, Phoenix supports retention policies for projects. You can configure automatic trace deletion based on time (e.g., delete traces older than X days) or trace count, either globally or per project. When all traces are deleted, the project remains but is empty; Phoenix does not automatically delete the project itself when it becomes empty—manual deletion is required if you want to remove the project entirely. Retention policies are managed via the UI, environment variables, or API, and cleanup runs on a scheduled basis (typically weekly) <https://arize.com/docs/phoenix/settings/data-retention|source>, <https://arize.com/docs/phoenix/self-hosting/misc/frequently-asked-questions|source>, <https://arize.com/docs/phoenix/settings/data-retention#ask-assistant-code-block-button|source>. Would you like more detail on how to configure or manage these retention policies? Sources: - <https://arize.com/docs/phoenix/settings/data-retention|https://arize.com/docs/phoenix/settings/data-retention> - <https://arize.com/docs/phoenix/self-hosting/misc/frequently-asked-questions|https://arize.com/docs/phoenix/self-hosting/misc/frequently-asked-questions> - <https://arize.com/docs/phoenix/settings/data-retention#ask-assistant-code-block-button|https://arize.com/docs/phoenix/settings/data-retention#ask-assistant-code-block-button>

Phoenix does support displaying images in multimodal traces, but images may not appear if the base64-encoded image exceeds the default size limit or if certain masking settings are enabled. To ensure images display, set the environment variable `OPENINFERENCE_BASE64_IMAGE_MAX_LENGTH` to a higher value (e.g., "1000000") and make sure `OPENINFERENCE_HIDE_INPUT_IMAGES` and `OPENINFERENCE_HIDE_INPUTS` are set to "False" before importing Phoenix or OpenInference. This is a known issue and not a documentation gap—see the troubleshooting steps and user confirmations in recent GitHub issues and the official docs for details on configuration and limitations. If images still do not show, check for errors in Phoenix and browser logs, and ensure your instrumentation libraries are up to date and correctly propagating image payloads. According to the documentation, this applies to both base64 and data URL images, and the default limit is 32,000 characters, which often needs to be increased for real images. Would you like more detail on how to set these environment variables or debug further? Sources: - <https://arize.com/docs/phoenix/tracing/how-to-tracing/advanced/multimodal-tracing|Phoenix: Capture Multimodal Traces> - <https://github.com/Arize-ai/phoenix/issues/10868|GitHub Issue: Self-hosted Phoenix does not render images from base64 strings of Langgraph traces> - <https://github.com/Arize-ai/phoenix/issues/5564|GitHub Issue: Prompts containing Images with data URLs are not displayed in the UI>

You can run your dataset questions against your agent (not just an LLM) by defining a custom experiment task that invokes your agent for each input. In Phoenix, you upload your dataset, define your agent as the task function, and then run an experiment using `run_experiment`, passing your dataset, the agent task, and your evaluator(s). This will execute your agent for each example and apply the evaluator(s) to the outputs. You do not need to use a sandbox unless you want to author and run custom code evaluators directly in the Phoenix UI; sandboxes are for running Python/TypeScript evaluators server-side, not for running your agent logic itself. See <https://arize.com/docs/phoenix/cookbook/datasets-and-experiments/experiment-with-a-customer-support-agent#create-and-run-an-experiment|Experiment with a Customer Support Agent> and <https://arize.com/docs/phoenix/datasets-and-experiments/how-to-experiments/how-to-dataset-evaluators|How-to: Dataset Evaluators>. For multi-step evaluation (e.g., evaluating each step of a multi-step agent), Phoenix supports evaluating intermediate steps by capturing traces or by structuring your experiment so that each step's output is available for evaluation. You can log evaluations for each span (step) using `SpanEvaluation`, or design your experiment to return intermediate results for evaluation. However, the UI and built-in experiment runner primarily focus on evaluating the final output; multi-step (span-level) evaluation is possible but may require manual instrumentation or custom code. See <https://arize.com/docs/phoenix/cookbook/evaluation/evaluate-an-agent|Evaluate a Talk-to-Your-Data Agent> and <https://arize-ai.slack.com/archives/C04R3GXC8HK/p1716404752.254739|Slack discussion on span evaluations>. Would you like a step-by-step code example for setting up such an experiment? Sources: - <https://arize.com/docs/phoenix/cookbook/datasets-and-experiments/experiment-with-a-customer-support-agent#create-and-run-an-experiment|https://arize.com/docs/phoenix/cookbook/datasets-and-experiments/experiment-with-a-customer-support-agent#create-and-run-an-experiment> - <https://arize.com/docs/phoenix/datasets-and-experiments/how-to-experiments/how-to-dataset-evaluators|https://arize.com/docs/phoenix/datasets-and-experiments/how-to-experiments/how-to-dataset-evaluators> - <https://arize.com/docs/phoenix/cookbook/evaluation/evaluate-an-agent|https://arize.com/docs/phoenix/cookbook/evaluation/evaluate-an-agent> - <https://arize-ai.slack.com/archives/C04R3GXC8HK/p1716404752.254739|https://arize-ai.slack.com/archives/C04R3GXC8HK/p1716404752.254739>

Correct, both <https://github.com/Arize-ai/phoenix/issues/6868|#6868> and <https://github.com/Arize-ai/phoenix/issues/6201|#6201> are closed. However, the underlying performance issues with the /projects page on large datasets are acknowledged as ongoing challenges, and improvements have been released in newer Phoenix versions. If you are still experiencing problems, the maintainers recommend upgrading to the latest version and opening a new issue with detailed logs if the problem persists. Would you like guidance on what information to include if you open a new issue, or details on recent performance improvements? Sources: - <https://github.com/Arize-ai/phoenix/issues/6868|https://github.com/Arize-ai/phoenix/issues/6868> - <https://github.com/Arize-ai/phoenix/issues/6201|https://github.com/Arize-ai/phoenix/issues/6201>

Yes, there are specific GitHub issues documenting this problem. The most relevant are <https://github.com/Arize-ai/phoenix/issues/6868|#6868> ("Blocking projects page metrics"—/projects page blocks on metric queries and can take up to 30 seconds or more to load with large data) and <https://github.com/Arize-ai/phoenix/issues/6201|#6201> ("Performance degradation when opening a project in Phoenix as the number of traces grows"—project page slows down as data increases, even with pagination). Both discuss root causes and ongoing improvements for large-scale Phoenix deployments. Would you like a summary of the solutions or workarounds discussed in these issues? Sources: - <https://github.com/Arize-ai/phoenix/issues/6868|https://github.com/Arize-ai/phoenix/issues/6868> - <https://github.com/Arize-ai/phoenix/issues/6201|https://github.com/Arize-ai/phoenix/issues/6201>

If your /projects page is slow or errors out with a large Phoenix database (e.g., 4TB), but direct GraphQL queries are fast, the issue is likely due to the UI loading or aggregating too much data at once, or hitting timeouts or memory limits. This is a known issue—Phoenix's /projects page can block on metric queries for each project, causing slow loads or timeouts, especially with large datasets. Improvements have been made (e.g., lazy loading, reducing page size, and optimizing queries), but performance can still degrade with very large data volumes or many projects/traces. Upgrading to the latest Phoenix version is recommended, as recent releases include major speed improvements and better lazy loading for project views. Also, try reducing the number of projects, limiting the time range, or filtering to root spans to improve performance. If you still hit errors, check server logs for timeouts or memory errors, and consider increasing server resources or database tuning (e.g., indexes, partitioning) for large-scale deployments. For persistent issues, you may need to pre-aggregate metrics or further optimize your database setup (<https://github.com/Arize-ai/phoenix/issues/6868|source>, <https://github.com/Arize-ai/phoenix/issues/6201|source>, <https://arize.com/docs/phoenix/production-guide#memory-sizing|source>, <https://arize.com/docs/phoenix/self-hosting/architecture|source>, <https://arize.com/docs/phoenix/release-notes/03-2025/03-06-2025-project-improvements|source>). Would you like more detail on specific optimizations, configuration, or troubleshooting steps? Sources: - <https://github.com/Arize-ai/phoenix/issues/6868|https://github.com/Arize-ai/phoenix/issues/6868> - <https://github.com/Arize-ai/phoenix/issues/6201|https://github.com/Arize-ai/phoenix/issues/6201> - <https://arize.com/docs/phoenix/production-guide#memory-sizing|https://arize.com/docs/phoenix/production-guide#memory-sizing> - <https://arize.com/docs/phoenix/self-hosting/architecture|https://arize.com/docs/phoenix/self-hosting/architecture> - <https://arize.com/docs/phoenix/release-notes/03-2025/03-06-2025-project-improvements|https://arize.com/docs/phoenix/release-notes/03-2025/03-06-2025-project-improvements>

To query the trace-level user_feedback annotations (e.g., those created by the thumbs-up button in the Session view), use the Phoenix client to retrieve trace annotations. The trace annotation for user feedback is stored with the name user_feedback and can be accessed via the API or SDK. You can use the TypeScript or Python SDK to fetch trace annotations, filtering by annotation name if needed. For example, in TypeScript, use `getTraceAnnotations` and specify `includeAnnotationNames: ["user_feedback"]` to retrieve only user feedback annotations for your traces. In Python, use the `get_trace_annotations` method or query the traces DataFrame and filter for the user_feedback annotation column. For more details and code examples, see the documentation on <https://arize.com/docs/phoenix/sdk-api-reference/typescript/packages/phoenix-client/annotations|Annotations> and the <https://arize.com/docs/phoenix/release-notes/05-2026/05-15-2026-session-feedback-and-atif|release notes describing trace-level user_feedback>. Would you like a step-by-step code example for your preferred language? Sources: - <https://arize.com/docs/phoenix/sdk-api-reference/typescript/packages/phoenix-client/annotations|Annotations> - <https://arize.com/docs/phoenix/release-notes/05-2026/05-15-2026-session-feedback-and-atif|05.15.2026: Session Trace Feedback and ATIF v1.7 Support>

Setting `os.environ["OTEL_PYTHON_TRACER_PROVIDER"] = "otel_sdk_tracer_provider"` is not mentioned as a required step in the official Phoenix documentation for Google ADK Agent Engine tracing. Instead, you must ensure that Phoenix uses an isolated (non-global) tracer provider and that instrumentation is initialized inside the remote agent module, not in the main application code. The recommended approach is to use the `register` function from `phoenix.otel` with `set_global_tracer_provider=False` and instrument with `GoogleADKInstrumentor`, as shown in the docs. If traces are not being sent, double-check that you are not using the global tracer provider and that all required environment variables (`PHOENIX_COLLECTOR_ENDPOINT`, `PHOENIX_API_KEY`) are set in the agent module. See the full example and troubleshooting steps in the <https://arize.com/docs/phoenix/integrations/python/google-adk/google-adk-tracing#agent-engine-deployment|Phoenix Google ADK Tracing documentation>. Would you like a step-by-step breakdown of the correct setup? Sources: - <https://arize.com/docs/phoenix/integrations/python/google-adk/google-adk-tracing#agent-engine-deployment|Phoenix Google ADK Tracing documentation>