Gradio Agents & MCP Hackathon
WinnersGradio Agents & MCP Hackathon
Winners →Getting Started
QuickstartBuilding Interfaces
The Interface ClassMore On ExamplesFlaggingInterface StateReactive InterfacesFour Kinds Of InterfacesBuilding With Blocks
Blocks And Event ListenersControlling LayoutState In BlocksDynamic Apps With Render DecoratorMore Blocks FeaturesCustom CSS And JSUsing Blocks Like FunctionsAdditional Features
QueuingStreaming OutputsStreaming InputsAlertsProgress BarsBatch FunctionsSharing Your AppFile AccessMultipage AppsEnvironment VariablesResource CleanupThemesClient Side FunctionsView Api PageInternationalizationChatbots
Creating A Chatbot FastChatinterface ExamplesAgents And Tool UsageCreating A Custom Chatbot With BlocksChatbot Specific EventsCreating A Discord Bot From A Gradio AppCreating A Slack Bot From A Gradio AppCreating A Website Widget From A Gradio ChatbotData Science And Plots
Creating PlotsTime PlotsFilters Tables And StatsConnecting To A DatabaseStreaming
Streaming Ai Generated AudioObject Detection From Webcam With WebrtcObject Detection From VideoConversational ChatbotReal Time Speech RecognitionAutomatic Voice DetectionCustom Components
Custom Components In Five MinutesKey Component ConceptsConfigurationBackendFrontendFrequently Asked QuestionsPdf Component ExampleMultimodal Chatbot Part1Documenting Custom ComponentsGradio Clients And Lite
Getting Started With The Python ClientGetting Started With The Js ClientQuerying Gradio Apps With CurlGradio And Llm AgentsGradio LiteGradio Lite And Transformers JsFastapi App With The Gradio ClientMcp
Building Mcp Server With GradioFile Upload McpBuilding An Mcp Client With GradioUsing Docs McpOther Tutorials
Using Hugging Face IntegrationsGradio And CometGradio And ONNX On Hugging FaceGradio And Wandb IntegrationCreate Your Own Friends With A GanCreating A Dashboard From Bigquery DataCreating A Dashboard From Supabase DataCreating A Realtime Dashboard From Google SheetsDeploying Gradio With DiscoDeploying Gradio With DockerDeveloping Faster With Reload ModeFrom Openapi SpecHow To Use 3D Model ComponentImage Classification In PytorchImage Classification With Vision TransformersInstalling Gradio In A Virtual EnvironmentNamed Entity RecognitionPlot Component For MapsRunning Background TasksRunning Gradio On Your Web Server With NginxSetting Up A Demo For Maximum PerformanceStyling The Gradio DataframeTheming GuideUnderstanding Gradio Share LinksUsing FlaggingUsing Gradio For Tabular WorkflowsUsing Gradio In Other Programming LanguagesWrapping LayoutsSo far, we've assumed that your demos are stateless: that they do not persist information beyond a single function call. What if you want to modify the behavior of your demo based on previous interactions with the demo? There are two approaches in Gradio: global state and session state.
If the state is something that should be accessible to all function calls and all users, you can create a variable outside the function call and access it inside the function. For example, you may load a large model outside the function and use it inside the function so that every function call does not need to reload the model.
import gradio as gr
scores = []
def track_score(score):
scores.append(score)
top_scores = sorted(scores, reverse=True)[:3]
return top_scores
demo = gr.Interface(
track_score,
gr.Number(label="Score"),
gr.JSON(label="Top Scores")
)
demo.launch()
In the code above, the scores
array is shared between all users. If multiple users are accessing this demo, their scores will all be added to the same list, and the returned top 3 scores will be collected from this shared reference.
Another type of data persistence Gradio supports is session state, where data persists across multiple submits within a page session. However, data is not shared between different users of your model. To store data in a session state, you need to do three things:
'state'
input and 'state'
output components when creating your Interface
Here's a simple app to illustrate session state - this app simply stores users previous submissions and displays them back to the user:
import gradio as gr
def store_message(message: str, history: list[str]):
output = {
"Current messages": message,
"Previous messages": history[::-1]
}
history.append(message)
return output, history
demo = gr.Interface(fn=store_message,
inputs=["textbox", gr.State(value=[])],
outputs=["json", gr.State()])
demo.launch()
Notice how the state persists across submits within each page, but if you load this demo in another tab (or refresh the page), the demos will not share chat history. Here, we could not store the submission history in a global variable, otherwise the submission history would then get jumbled between different users.
The initial value of the State
is None
by default. If you pass a parameter to the value
argument of gr.State()
, it is used as the default value of the state instead.
Note: the Interface
class only supports a single session state variable (though it can be a list with multiple elements). For more complex use cases, you can use Blocks, which supports multiple State
variables. Alternatively, if you are building a chatbot that maintains user state, consider using the ChatInterface
abstraction, which manages state automatically.